views:

48

answers:

5

At runtime, when myApp.exe crashes i receive "Unhandled Win32 exception" but how would i know which exception was occurred? where did something went wrong?

A: 

If it's a .Net app you could try to put in a handledr for the UnhandledException event. You can find more information about it and some sample code here.

In general it's a good sign that your exception handling is broken though, so might be worth going through your code and finding places that could throw but where you don't handle exceptions.

ho1
A: 

Use the debugger. You can run the program and see what exception is been thrown that kills your application. It might be able to pinpoint the location of the throw. I have not used the VS debugger for this, but in gdb you can use catch throw to force a breakpoint when an exception is thrown, there should be something similar.

David Rodríguez - dribeas
A: 

For a Native C++ app see my earlier answer here: http://stackoverflow.com/questions/2911097/detect-redirect-core-dumps-when-a-software-crashes-on-windows/2911451#2911451 for catching the unhandled exception (that also gives code for creating a crash dump that you can use to analyse the crash later. If the crash is happening on a development system then in Visual Studio (I'm assuming you're using that, if not other IDEs will have something similar), in Debug/Exceptions tick the 'Thrown' box for 'Win32 Exceptions'.

the_mandrill
A: 

As explained here, you can catch nearly all exceptions at run time using an ellipsis in your catch..

try {
   // as much code as possible here
} catch(...) {

}

You can narrow down the type of error by catching broad classes of exceptions in multiple catch blocks:

try {
    //...
}  catch (const std::bad_alloc& e) {
    // ...
} catch (...) {
   // ...
}
sje397
`catch(...)` doesn't catch Win32 exceptions (anymore)
MSalters
@MSlaters - since when?
sje397
A: 

Typically, Windows will give you several hexadecimal numbers as well. Chances are that the exception code will be 0xC0000005. This is the code of an Access Violation. When that happens, you also will have three additional bits of information: the violating address, the violated address, and the type of violation (read, write or execute).

Windows won't narrow it down any further than that, and often it couldn't anyway. For instance, if you walk past the end of an array in your program, Windows likely won't realize that you were even iterating over an array. It just sees "read:OK, read:OK, read:out of bounds => page fault => ACCESS VIOLATION". You will have to figure that out from the violating address (your array iteration code) and the violated address (the out-of-bounds address behind your array).

MSalters