Article ID: 173652 - View products that this article applies to.
This article was previously published under Q173652
Win32 processes can install an unhandled exception filter function to catch exceptions that are not handled in a __try/__except block on a process-wide basis. When debugging such a process, you find that the unhandled exception filter is never executed, even when you put a breakpoint inside it. However, when the process is not being debugged, its unhandled exception filter is called as expected.
When called from a process being debugged, the UnhandledExceptionFilter() Win32 API function does not call the application-installed unhandled exception filter.
Note The UnhandledExceptionFilter() API determines whether the process is being debugged. If the process is being debugged, the UnhandledExceptionFilter API passes the exception to the debugger. Then, the UnhandledExceptionFilter API calls the unhandled exception filter for the process.
UnhandledExceptionFilter should call the application-installed unhandled exception filter for processes that are being debugged in addition to those not being debugged.
One way to debug an unhandled exception filter function is to put a __try/__except block around all of the code inside the main() or WinMain() function as follows:
This work around behaves slightly differently from an unhandled exception filter in that it will only be called for the thread executing the main() or WinMain() function. If you are debugging a multithreaded application, then you will need to add a similar __try/__except block inside of each thread function.
If you don't want to add new __try/__except blocks to debug an unhandled exception filter, you should use other methods such as assert, trace outputs, and debugging code to validate the behavior of the exception handler.
Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. We are researching this bug and will post new information here in the Microsoft Knowledge Base as it becomes available.
The purpose of an unhandled exception filter function is to give a process the opportunity to respond to exceptions that occur outside any __try/__except block. Unhandled exception filters are process-wide; if any thread causes an exception, but does not handle it, the unhandled exception filter will get called. Once called, the filter function can fix the cause of the exception and continue execution, or it can pass the error to the default unhandled exception handler, which terminates the process.
Win32 applications can install a process-wide unhandled exception filter with the SetUnhandledExceptionFilter() API function. The Microsoft Visual C++ C Runtime (CRT) library startup code implements a __try/__except block around the main() function. When an exception is caught by this block, its exception filter function, named _XcptFilter, is called. _XcptFilter does two things: it maps the Win32 exceptions to signals used by the signal() CRT function, and dispatches signals to their appropriate handlers. If a signal's handler is set to SIG_DFL (as is the case by default), _XcptFilter calls the UnhandledExceptionFilter() API.
The UnhandledExceptionFilter() API determines whether the process is being debugged. If it is, then UnhandledExceptionFilter passes the exception first to the debugger, and then is supposed to call the process's unhandled exception filter.
If the process isn't being debugged, then UnhandledExceptionFilter calls the process's unhandled exception filter. Depending on the filter function's return, UnhandledExceptionFilter either continues execution at the point of the exception, or displays a system-modal dialog box informing the user that the application is to be terminated due to an unhandled exception.
Steps to Reproduce BehaviorCompile the following sample code, and then set a breakpoint inside MyUnFilter. Observe that the breakpoint never gets hit.
Article ID: 173652 - Last Review: November 21, 2006 - Revision: 4.4