Windows Exception Call Order

(i) the order in which the system was processed when the exception occurred (by Jeremy Gordon, Hume):

1. The system first determines whether the exception should be sent to the target program's exception-handling routines, if the decision should send, and the target program is being debugged, the system
Suspends the program and sends a exception_debug_event message to the debugger.

2. If your program is not debugged or the debugger fails to handle the exception, the system will continue to find out if you have thread-related exception handling routines installed, if
When you install a thread-related exception handling routine, the system sends the exception to your program's SEH-processing routines, which it handles.

3. Each thread-related exception-handling routine can handle or not handle this exception if he does not process and installs multiple thread-related exception handling routines.
Can be handled by other routines chained together.

4. If these examples threads choose not to handle the exception, if the program is in the debug state, the operating system will still suspend the program notification debugger again.

5. If the program is not in the debug state or debugger is not able to process, and you call SetUnhandledExceptionFilter installs the last different
Routine, the system turns to its invocation.

6. If you do not install the last exception handling routine or if he does not handle the exception, the system invokes the default system handler, which usually displays a dialog box,
You can choose to close or finally attach it to the Debug button on the debugger. If no debugger can be attached to it or the debugger can't handle it, the system
The ExitProcess finalizer is called.

7. However, until the end, the system continues to expand on the thread exception handling handle that has an exception, which is the opportunity to finally clean up the thread exception handling routines.

Windows Exception Call Order