다음을 통해 공유

Debugging your unhandled exception filters

  • 아티클

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.

Comments

  • Anonymous
    August 27, 2004
    Thank you for the tip, greggm.

    But when I made example code and tested it, I can't get the result that you said. I set the WinDBG as default debugger and my code caused Exception. When the exception occured, I debugged with WinDBG, but interestingly WinDBG already indicate the code that caused the exception. So I don't need to use your tip to find the code that caused the exception. Could you please show me any example?

    Thanks in advance.
  • Anonymous
    September 02, 2004
    > WinDBG already indicate the code that
    > caused the exception

    Sometimes when you do a stack trace from an exception filter it actually shows you both stacks - the one that raised the exception, and then the exception dispatching stack on top of it.

    However it doesn't always work (I'm not sure why), and this is where .cxr comes in handy.

    By the way, if you don't have Whidbey and you don't wan't to use WinDbg for some reason, you can simulate .cxr simply by setting EIP, ESP and EBP registers to their respective values stored in the exception's context record. I tried this a couple of times in VC6 and it seemed to work.
  • Anonymous
    January 26, 2007