Demystifying first-chance exceptions (Part 1)
Thursday, May 22nd, 2008There is a bit of confusion around the division of exceptions between the first- and second-chance. For example, I am often asked whether saving crash dumps on first-chance exceptions should be disabled or enabled. So I decided to clarify this issue.
First, let me say that the concept of first-chance exceptions is purely a debugger-related. There is only one exception that happens when we access an invalid address, for example. However, that exception may be handled or may not be handled by exception handlers. Or it might be handled in peculiar way and terminate the thread that caused the exception, for example. And if it was not handled then an unhandled exception filter might be called. The default one might launch a postmortem debugger (or any process that can read process memory) to save a postmortem memory dump. Any thread can replace the default filter with a custom exception filter that might also do peculiar things and quietly terminate or exit. Even the properly configured postmortem debugger can fail to save a dump file. Therefore we have this question: how can we catch the exception and examine the process state as earlier as possible, before the execution flow goes through the exception handling mechanism?
Here we have the concept of the first chance exception dispatched to the attached user-mode debugger. if it wasn’t handled we have the same exception but called the second chance that is dispatched to the same debugger again. We see that it has nothing to do with the postmortem debugger although the attached live debugger can save crash dump files too, which what ADPlus does, for example.
- Dmitry Vostokov @ DumpAnalysis.org -
