In .n1.1 a mixed mode MFC 7 application could register for the System::AppDomain::CurrentDomain::UnhandledException event and receive notice of an unhandled exception. This worked well for logging exceptions ( except a few rare cases were the frame work was dead). However in .net 2.0 this has changed, according to the new documentation
In the .NET Framework versions 1.0 and 1.1, an unhandled exception that occurred in a thread other than the main application thread was caught by the runtime and therefore did not cause the application to terminate. Thus, it was possible for the UnhandledException event to be raised without the application terminating. In the .NET Framework version 2.0, this backstop for unhandled exceptions in child threads was removed, because the cumulative effect of such silent failures included performance degradation, corrupted data, and lockups, all of which were difficult to debug. For more information, see Exceptions in Managed Threads.
To register an event handler for this event, you must have the required permissions, or a SecurityException is thrown.
Pasted from <http://msdn2.microsoft.com/en-us/library/system.appdomain.unhandledexception(VS.80).aspx>
So rather then being able to log errors with a detailed stack trace we are left with a GPF error message.
We can overload the WinAPP::Run function and insert a try catch block, but exception we catch will always be the same System.Runtime.InteropServices.SEHException. Optimistically I opened a Ticket with Microsoft for a recommend way to intercept the real exception details or find a work around to enable the UnhandledException event. Microsoft's response was use a try catch block. This is not a realistic answer. There are cases were nullreferance exceptions are raised from unmanaged code. And as much as I would like to wrap every method in a try catch statement, some how this doesn't sound like a good idea.
My best alternative is to is to register for the win32 SetUnhandledExceptionFilter and allow for the creation of a minidump. For this I found a nice little library clrdump.
As an aside I find it interesting that the best articles for structured exception handling are from an August 1998 Bugslayer article and January 1997
A Crash Course on the Depths of Win32™ Structured Exception Handling both from the The Microsoft Systems Journal.