View Full Version : Exception Handling and Debuggers

October 16th, 2009, 09:17
Sup all,

Ive been poking around with SEH as of late and i came across an interesting question pertaining to SEH and debuggers.
Is there a way to successfully grab an exception before a debugger gets the notification of the exception? Meaning if your program is under a debugger can you in fact be able to get your handler to be called when an exception occurs before the debugger gets it? Im not too knowledgable on the inner workings on how a debugger handles exceptions( I do know that they have a very advanced exception handler to capture all ex ceptions) But what inner layer causes a debugger to be able to handle an exception before your application, i wanted to try and find a way to bypass this but had no direction.
Even if you place your exception handler as the first handler, still the debugger gets it, surely theres a way around this?

October 16th, 2009, 10:51
Well i guess a little googleing wouldnt have hurt, although i just wasnt sure what to search for, i got my answer right here on RCE!.


good to go.

October 16th, 2009, 13:14
That is why we have the BIG RED LETTERS at the top of the Forums.

Of course not everything can be found easily by searching, but it should always be a first step in trying to find what one needs.

Glad you solved your problem.


October 16th, 2009, 16:13
Umm.. I thought even with a top level exception handler, the debugger still gets notified before the exception handler ("first chance" exception). Only if the debugger chooses to not handle the exception does it go to the exception handler, and if the exception handler chooses not to handle the exception, it goes back to the debugger again ("second chance" exception).

October 16th, 2009, 20:44
Yes, disavowed this is how it works afaik..the techniques mentioned in the links from what i can see go into the SetUnhandledExceptionFilter function because its what notifies that there is an exception that will need handling, and this is when some internal working set the debugport to true and pass it to the debugger. Im still working on it though.

Just a correction from what i said from wtbw, SetUnhandleExceptionFilter happens *after* all the good stuff happens, it notifies after there has been no previous handler to handle the exception, at which point debugport has already been set, and cannot be modified in runtime( thx j00ru)...

So this has to go deeper unfortunately into kernel space to try and stop the debugger from capturing your programs exceptions

November 8th, 2009, 05:23
There are only 7 events in which the user debugger delivered a message(DBGKM_APIMSG):
- Exceptions
- Creating threads
- Creating processes
- Terminating threads
- Terminating processes
- Map vief of sections
- Unmap view of sections
There are two ways around this.
1. There service NtRemoveProcessDebug, which remove the debug port and, most importantly, this service can be called debugging process.
- DebugObject = NtQueryInformationProcess(ProcessDebugObjectHandle)
- NtRemoveProcessDebug(DebugObject)
2. ThreadHiddenFromDebugger, (ERHREAD.CrossThreadFlags -> PS_CROSS_THREAD_FLAGS_HIDEFROMDBG).
- NtSetInformationThread(NtCurrentThread, ThreadHideFromDebugger)
3. For outside of tracer can be through services(reset trap flag TF):
- NtContinue
- NtSetContextThread
For kernel debug exception delivered in KiDispatchException(), by calling the callback could KiDebugRoutine, it is impossible to circumvent of usermode.

November 8th, 2009, 08:11
debugport has already been set, and cannot be modified in runtime( thx j00ru)...

We wrote a small code: http://paste.org.ru/?k4olqo ("http://paste.org.ru/?k4olqo")

November 9th, 2009, 03:18
Whats the dump for?

November 9th, 2009, 09:14
To solve your problem:
; o Outside of debugger and tracer.

Few corrected for W7: http://paste.org.ru/?k9lpcz
Is no other way to exist for usermode(remote code execution is not counted).