# bug in Olly, Windows behavior and Peter Ferrie

PeterFerrie strongly disagreed with me, pointed out, that this is not only the Olly bug.

The not a problem in OllyDbg, it’s a Windows behavior. Try it without any debuggers and you will see the same thing. I found the same while researching my new paper.

If you set the trap flag then cause an access exception, you’ll get a trap exception before the access exception. That’s the Windows behavior, even without a debugger. Interestingly, it doesn’t happen in a VM. OllyDbg is setting the trap flag before the exception occurs. That’s why you see the behavior. If something else set the flag, you’d still see the behavior.

ok, my bad, he won! I admit it.
to make long story short:
in general, TF-bit is zeroed automatically every time single step exception is generated, so to continue tracing you have to set it again. however, if CPU generates access violation exception, illegal instruction exception or any other fault like this, kernel doesn’t clean TF-bit and keeps it in registry context. after that, kernel cleans TF-bit and calls ntdll!KiUserExceptionDispatcher, KiUserExceptionDispatcher finds and calls SEH-handler(s), gets control back and calls ntdll!NtRaiseException, passing registry context (where TF bit is set!!) as an argument. NtRaiseException asks kernel for passing control to the current process. kernel begins to restore registry context, restoring TF-bit _before_ control is passed. as result – kernel generates single step exception and calls KiUserExceptionDispatcher again, keeping TF-bit unchanged (setting), so, CPU executes the first machine command of KiUserExceptionDispatcher and generates single step exception, passing it to kernel. wow! kernel catches single step exception, cleans TF-bit (wow!!! TF-bit finally is cleaned!) and calls KiUserExceptionDispatcher, passes exception record with context.Eip = (ntdll!KiUserExceptionDispatcher + 1). why plus one? due to single step exception is a trap, not a fault.

how KiUserExceptionDispatcher is supposed to handle this?! well, it just try to find SEH-handler(s), ready to accept this exception and passes control to them. since, expectations are reenterable, everything works fine (of course, if SEH handler is able to handle the unexpected exception of ntdll!KiUserExceptionDispatcher, the best strategy – just ignore it)

but Olly is unable to do this!!! try to trace the program we’re talking about with Olly, trace it until ntdll!KiUserExceptionDispatcher –} ntdll!NtRaiseException and… ops!!! Olly tells you that “debugged program was unable to process exception“.

I recalled that I discovered this windows bug years ago, when I was working on my debugger, but… I just cleaned up TF-bit in the EXCEPTION_DEBUG_EVENT handler and totally forgot about it. and besides, any other debugger does the same – take Soft-Ice for example! (btw, right now I’m porting soft-ice to Vista and Server 2008, making a special bit-hacking patch)

P.S. in few day I’m going to publish more detailed post.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: