5

When debugging the following com file in MS-DOS, I can successfully run the program with -g and it terminates normally, but when I trace it -t 1000, the program throws an illegal operation exception and terminates after +/- 800 instructions. I traced the file manually, but I cannot see why it aborts (it does write to some data to the lower memory regions, but that shouldn't affect the debugger).

The COM file can be found here.

Both MS Debug and the Freedos DEBUG.exe give the same results (albeit that they crash at a different point in the execution). Both the WinXP virtual x86 environment and dosbox give the same results.

Any thoughts on why this is happining?

EDIT: A trace can be found in this pastebin.

This trace was made with Dosbox running the FreeDOS debugger using these software.

I looked into the MASM code from the debugger: normally no INT3 should be used for a single-step trace. Also note the fact that all the registers and flags are messed up.

Improve this question
2
  • 1
    Paste a trace log.
    – Igor Skochinsky ♦
    Nov 30, 2013 at 19:33
  • Seeing that the error with which the debugger crashes depends on the debugger (crashes at different points during the execution), the most probable explanation would be that some part of the debugger got overwritten. But how exactly can I test that hypothesis? I can't put any page protection or anything in real mode.
    – user3271
    Nov 30, 2013 at 20:49

1 Answer 1

Reset to default
4

These instructions:

6401.AX=0000 BX=0811 CX=0004 DX=0000 SP=FFF8 BP=0000 SI=8020 DI=8000
6402.DS=F800 ES=F800 SS=06F1 CS=0811 IP=051F NV UP EI PL ZR NA PE NC
6403.0811:051F F3AB              REP     STOSW
6404.AX=0000 BX=0811 CX=0003 DX=0000 SP=FFF8 BP=0000 SI=8020 DI=8002
6405.DS=F800 ES=F800 SS=06F1 CS=0811 IP=051F NV UP EI PL ZR NA PE NC
6406.0811:051F F3AB              REP     STOSW
6407.AX=0000 BX=0811 CX=0002 DX=0000 SP=FFF8 BP=0000 SI=8020 DI=8004
6408.DS=F800 ES=F800 SS=06F1 CS=0811 IP=051F NV UP EI PL ZR NA PE NC
6409.0811:051F F3AB              REP     STOSW

are overwriting the interrupt table - specifically interrupt 0 and intending to write interrupt 1. The Trace uses interrupt 1, so it is interrupting that write. The next trace instruction that occurs after that last REP completes will trigger an interrupt using the partially overwritten new address instead of the debugger's one. The effects are entirely unpredictable at that point. You can't trace through this one automatically. It will require some interaction from you.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.