However, after debugging a little more, I think the debugger is causing the problem as it doesn’t occur when it’s not attached. Basically, if I set a breakpoint in a software interrupt handler, then on the next instruction in user mode, some registers (notably the fs register) are not correct.
For example, I saw the same problem debugging Windows 2000 KiSystemService as the system calls are int 2e calls. If I set a breakpoint on KiSystemService, clear it, set a breakpoint on the ret call in ntdll, and then go, when the breakpoint in ntdll is hit, the fs register will be 0 instead of whatever it used to be (3b, 38, or something like that). Whatever process is running will then crash when it tries to use it.
What is causing this behavior? Without a debugger this doesn’t occur.
However, after debugging a little more, I think the debugger is causing the problem as it doesn’t occur when it’s not attached. Basically, if I set a breakpoint in a software interrupt handler, then on the next instruction in user mode, some registers (notably the fs register) are not correct.
For example, I saw the same problem debugging Windows 2000 KiSystemService as the system calls are int 2e calls. If I set a breakpoint on KiSystemService, clear it, set a breakpoint on the ret call in ntdll, and then go, when the breakpoint in ntdll is hit, the fs register will be 0 instead of whatever it used to be (3b, 38, or something like that). Whatever process is running will then crash when it tries to use it.
What is causing this behavior? Without a debugger this doesn’t occur.
I tried both and it gives the same result. I don’t know if I should post this as a bug, or if it is “expected” behavior when debugging the handler. At any rate it’s terribly annoying, and I’ve generally liked WinDBG for the most part over the last 3 years I’ve been using it.
Alas. I didn’t think that would solve it, and I don’t have any other
ideas at the moment at least, but I thought it might be worth a try as
it’s easy. Hoperfully someone else will be able to help you out better
than I have.
Debugging interrupt handlers and kernel/user transitions are two of the
three reasons that I used to use SoftICE every now and then, when that
was still an option. I think that you said you are student? If so,
does your school happen to have a JTAG emulator that you can use, like
an Arium ECM-50/ECM-XDP, to perhaps figure out what the Kd part of
WinDbg is doing?
I tried both and it gives the same result. I don’t know if I should post this as a bug, or if it is “expected” behavior when debugging the handler. At any rate it’s terribly annoying, and
I’ve generally liked WinDBG for the most part over the last 3 years I’ve
been using it.
I’m taking grad classes while working full time, and while we do have an emulator at work, I don’t have the time to debug windbg. I don’t have a version of SoftICE at home, so I’ll probably resort to DbgPrints if needed. I can walk through the handler once before the app crashes, I was just wondering if anyone had a workaround or had the same problem.