Article ID: 105675 - View products that this article applies to.
This article was previously published under Q105675
This article explains how to deal with structured exception handling (SEH) and raised exceptions when you run an application under a debugger.
It is a common practice to use SEH as a signaling mechanism. Some application programming interfaces (APIs) register an exception handler in anticipation of a failure condition that is expected to occur in a lower layer.
When an exception is raised, the handler may correct or ignore the condition rather than allow a failure to propagate up through intervening layers. This is very useful in complex environments such as networks where partial failures are expected and it is not desirable to fail an entire operation just because one of several optional parts failed. In this case, the exception can be handled so that the application does not recognize that an exception has occurred.
However, if the application is being debugged, the debugger sees all exceptions before the program does. This is the distinction between the first and second chance exception: the debugger gets the first chance to see the exception (hence the name). If the debugger allows the program execution to continue and does not handle the exception, the program will see the exception as usual. If the program does not handle the exception, the debugger gets a second chance to see the exception. In this latter case, the program normally would crash if the debugger were not present.
If you do not want to see the first chance exception in the debugger, you should disable first chance exception handling for the specific exception code. Otherwise, when the first chance exception occurs, you may need to instruct the debugger to pass on the exception to the program to be handled as usual.
For information on how to suppress (or ignore) first chance exceptions, refer to the debugger's documentation.
Article ID: 105675 - Last Review: November 21, 2006 - Revision: 2.1