Debugging your unhandled exception filters

  • Article

Sometimes an application will decide that they would like to do something interesting with unhandled exceptions. To do this, you would use SetUnhandledExceptionFilter. Maybe you want to report the exception to some web service (example: Windows Error reporting), or maybe they want to save some state before the process dies, or maybe you want to put up your own error dialog.  Whatever the reason, you will have two problems when debugging.
 
First, from your UnhandledExceptionFilter, it is hard to figure out where the exception is coming from. Windbg has had a solution to this problem for a while, and with Whidbey, VS has the same solution.

  1. If you are not already in the stack frame which is your unhandled exception filter, go to the unhandled exception filter frame.
  2. Your function took a parameter of type EXCEPTION_POINTERS, go to the watch Window, and look at the value of pExceptionPointers->ContextRecord. This is a pointer to a context record.
  3. Go to the immediate window. Type '.cxr 0x00123fc0' where 0x00123fc0 should be replaced with the address of the context record that you got from step #2.

You will now see where the exception was coming from.
NOTE: For Whidbey Beta1, there was a bug where the UI doesn't reset itself after the '.cxr' command. The workaround is to evaluate anything in the watch window.

The second problem is that while a debugger is attached, your unhandled exception filter will not be called. This is because kernel32's unhandled exception dispatch code checks to see if a debugger is attached before it calls any unhandled exception filter. For this problem, I suggest that you put in a message box.