> >Ok. first the application calls a sub:
> >(...)(lots of stuff and then:)
> >0615:1a42 E84203 call 1D87
> >General Protection Fault, AX=0002 BX=0005 CX=0000 DX=8a86 SI=3246
>
> And in such a case normal method is to restart it, and trace
> into the sub, then execute every sub in it until one causes
> the error, then trace into the one, and so on...
I am using a slightly different method at first, just to get a bit deeper into
the code, I use the 'tc' command to see the last int or call before the crash. I
then set a break point at the start of that sub or int so that the next trace
step will not be over the instruction, but inside. I did this until I found the
final call within which the crash occured.
> >(...)
> >Trap 1, AX=1100 BX=0000 CX=000e DX=2f21 SI=00c5 DI=0000 SP=7f42
> >BP=7f48
> >DS=2a5f ES=2932 FS=0000 GS=0000 FL=3302
> >CS:IP=0615:19ea SS:SP=2a5f:7f42
> >0615:19ea CD16 int 16
> >General Protection Fault, AX=0002 BX=0005 CX=0000 DX=8a86 SI=3246
> >DI=ffff SP=087c BP=0001
> >DS=0669 ES=081d FS=0000 GS=0000 FL=3206
> >CS:IP=ffff:cd1a SS:SP=0669:087c
>
> >right, so it crashes inside int 16... I look at 0:58, which I believe
> >to be the interrupt table entry for int 16 and use the address there
> >for my next break point:
> >bp 615:1a42
> >bp 70:42d
>
> I guess the 70:42d is address where INT 16 points to, ok?
Yes, that was the address found at 0:58, i.e. 0d 42 70 00
> >tc
> >...
> >Trap 1, AX=4b00 BX=0082 CX=0000 DX=00bc SI=5861 DI=05f9 SP=028a
> >BP=7dce
> >DS=0605 ES=0605 FS=0000 GS=0000 FL=3312
> >CS:IP=0605:046b SS:SP=0605:028a
> >
> >0605:046b CD21 int 21
> >General Protection Fault, AX=0002 BX=0005 CX=0000 DX=8a86 SI=3246
> >DI=ffff SP=087c BP=0001
> >DS=0669 ES=081d FS=0000 GS=0000 FL=3206
> >CS:IP=ffff:cd1a SS:SP=0669:087c
> ...
> >Facinating! This program is trying to load & excute another program.
>
> I suppose it is attempt to execute just the program you
> are debugging - can you check the name at DS:DX?
I haven't been able to get to that one. It is quite difficult, as the program
crashes. See my problem? You have seen the stack trace, it is of not much use.
The segment address (0605:) is familiar though. When I load the program and set
bpload, that is the segment address that shows up. This program in turn runs
other programs. The first program that this program loads works without problem.
Many of the menu choices work, the program does what it is supposed to do. But
some of the menu choices link to another program, which the main program tries
to load. And this is when it crashes. It crashes during the 'exec' call to int
21. From the stack segment address shown in subsequent calls to int 21 and 2f,
it looks like the program is successfully loaded and is making various calls to
int 2f, during one of which dos reads an argument from somewhere in it's memory
with a jmp far cs:[xxx]. I noticed these calls on the screen, but have not been
able to capture the moment. There is a point where there is no more interrupt
calls or subroutine calls, but only jmp far cs:[xx] and retf's. I think this is
where it goes wild.
>
> Breakpoints works improperly if more than one set?
I hope so, the documentation does not tell me otherwise.
> You did not set bp at 0605:046b - why it occured?
because I used 'tc' instead of 'g'. This allows me to see the instruction before
the crash. It is a bit slow, but I can do other things while it is tracing
through. Sometimes the t flag is lost by a popf or iret and I have to set an
extra breakpoint there, but otherwise works great.
> And seems these breakpoints you set were ignored...
No, those were not ignored. 'tc' steps over them until I hit a key, which I
don't, I just wait for it to crash and look at the last instruction executed
before crash.
> Seems like the breakpoint you set did something strange,
> maybe you need set one breakpoint at the call, execute
> program until the call, then set breakpoint on INT 16?
Yes. That is what I have already done. That is what the 70:42d break point was.
simply breaking at int 16 didn't work because it crashes before it returns. I
therefore had to get inside int 16.
This is great fun. We'll get to the bottom of this, eventually. I appologise for
not expressing myself clearly, but one may take in consideration I don't know
what I am talking about.
-Marcel Landman
