The first-chance exception can be ignored because it is safely handled by the operating system.
INFO: First and Second Chance Exception Handling (Q105675)
Structured exception handling (SEH) takes a little getting used to, particularly when debugging. It is 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 the
exception occurs, the handler may correct or ignore the condition rather than allowing a failure to propagate
up through intervening layers. This is very handy in complex environments such as networks where partial
failures are expected and it is not desirable to fail an entire operation simply because one of several optional
parts failed. In this case, the exception can be handled so that the application is not aware that an exception has
occurred.
However, if the application is being debugged, it is important to realize that the debugger will see all exceptions
before the program does. This is the distinction between the first and second chance exception. The debugger
gets the "first chance," hence the name. If the debugger continues the exception unhandled, the program will
see the exception as usual. If the program does not handle the exception, the debugger will see it again
(the "second chance"). In this latter case, the program normally would have crashed had the debugger not
been present.
If you do not want to see the first chance exception in the debugger, then disable the feature. Otherwise, during
execution, when the debugger gets the first chance, continue the exception unhandled and allow the program
to handle the exception as usual. Check the documentation for the debugger that you are using for descriptions
of the commands to be used.
INFO: First and Second Chance Exception Handling (Q105675)
Structured exception handling (SEH) takes a little getting used to, particularly when debugging. It is 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 the
exception occurs, the handler may correct or ignore the condition rather than allowing a failure to propagate
up through intervening layers. This is very handy in complex environments such as networks where partial
failures are expected and it is not desirable to fail an entire operation simply because one of several optional
parts failed. In this case, the exception can be handled so that the application is not aware that an exception has
occurred.
However, if the application is being debugged, it is important to realize that the debugger will see all exceptions
before the program does. This is the distinction between the first and second chance exception. The debugger
gets the "first chance," hence the name. If the debugger continues the exception unhandled, the program will
see the exception as usual. If the program does not handle the exception, the debugger will see it again
(the "second chance"). In this latter case, the program normally would have crashed had the debugger not
been present.
If you do not want to see the first chance exception in the debugger, then disable the feature. Otherwise, during
execution, when the debugger gets the first chance, continue the exception unhandled and allow the program
to handle the exception as usual. Check the documentation for the debugger that you are using for descriptions
of the commands to be used.