tags:

views:

288

answers:

3

Hi,

we're attempting to update our application in order to submit it for Vista certification. Part of the requirements are to handle only known exceptions and have Windows Error Reporting deal with all unhandled exceptions. We have a global exception handler in our application (subscribed to the Application.ThreadException event) and in there we perform certain processing for known exceptions, but if an exception is unknown we wish to throw it out for the app to terminate and WER to handle.

We cannot see a way of doing this and maintaining the call stack -if we rethrow then the call stack is recreated. We've looked at terminating via Environment.FailFast() but we don't believe that that gives the exception information we'd require.

Are we missing something obvious?

Thanks in advance,

Graham

A: 

Yea, as Marc states, just use THROW and the original exception will be re-thrown with the stack trace information preserved.

A THROW E will start the whole exception stack over again with the original stack information lost. Typically this is not what you want.

Alternative you can throw a new exception and add the original exception as an inner exception. Then your new exception could add additional bits of information.

John Dyer
A: 

Yes but we're within the Application.ThreadException global handler, not a catch block so we can't just call throw, we'd have to throw e.Exception.

Graham
+1  A: 

Why not just throw a new exception and set the InnerException property to be the unhandled one? The default StackTrace property will concatenate both traces together.

Bear in mind that if you're debugging from a memory dump that you've retrieved from WinQual then it'll be a native exception that's trapped anyway. It's almost always possible to walk back up the native stack and retrieve the managed exception and if you have symbols available it's usually easy to find out what went wrong. The stack trace of the managed exception will be redundant in this situation anyway.

Stu Mackellar
Yeah thats actually the route we've started down. We were concerned that WinQual would see all these exceptions as the same type (the new outer exception) and would classify them all as the same problem, but we need to investigate this a bit further.
Graham
To be honest the bucketing system in WinQual doesn't seem to work terribly well with managed exceptions at all at the moment. At least that's been my experience. Apparently Microsoft are considering updating it to improve categorisation.
Stu Mackellar