views:

344

answers:

3

currently I used SetUnhandledExceptionFilter() to provide callback to get information when an unhandled exception was occurred, that callback will provides me with EXCEPTION_RECORD which provides ExceptionAddress.

[1]what is actually ExceptionAddress is? does it the address of function / code that gives exception, or the memory address that some function tried to access?

[2]is there any better mechanism that could give me better information when unhandled exception occured? (I can't use debug mode or add any code that affect runtime performance, since crash is rare and only on release build when code run as fast as possible)

[3]is there any way for me to get several callstack address when unhandled exception occured.

[4]suppose ExceptionAddress has address A, and I have DLL X loaded and executed at base address A-x, and some other DLL Y at A+y, is it good to assume that crash was PROBABLY caused by code on DLL X?

A: 

Not direct answer to your question, but possibly this is what you need: http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx

Post-mortem debugging is the way to find exception place when the program runs in Release build on a client computer.

Alex Farber
yeah, I used that too, but it is time consuming to read the minidump on dev side, I need for quick guess how / where does the exception occurred.
uray
+3  A: 

(1) The ExceptionAddress is the address of the code that caused the exception. In case of an access violation error (0xC0000005) one of the additional arguments of the exception record holds the address from which a read or a write was attempted and another argument tells if it was a read or a write. This is documented in the link you provide in the question.

(2) no. additionally, adding debug information to a release build doesn't affect performance. You can verify this and see for yourself.

(3) dbghelp.dll provides a complete library to investigate crashes. among athers there is StackWalk64 which allows you to get the complete stack of the crash.

(4) calling GetModuleHandleEx with the ExceptionAddress as an argument will get you the handle of the dll where the offending code resides. As to the question of which DLL CAUSED the crash, this depends on your definition of "CAUSED". A crash which occur in one dll can be the result of a bug in a completely different and unrelated dll.

shoosh
(1)OK(2)well in my case if I debug information on release build, crash never occurred.(3)thanks, care to give some examples how to use that?(4)I will try this. thanks
uray
Here's a basic tutorial which seems to show how to use it, courtesy of google: http://jpassing.com/2008/03/12/walking-the-stack-of-the-current-thread/
shoosh
A: 

Also, not a direct answer to your question, but I think it could help you:

http://www.codeproject.com/KB/applications/blackbox.aspx

It will produce a readable output to screen or file, which will give you a stack output to find the place where the exception occured along with other useful information.

It worked good for me.

There is also an improved version named "Blackbox revised". Can't find the website right now, though.

nabulke