How to catch the "Uncaught Win32 Exception"

[Thomas W. Brown]

I have an application that is, occasionally, being terminated without any
apparent error. I have a try/catch around the entire main routine and no
exception is being caught. But, when I look into the system event log, there
is a report of an uncaught Win32 exception. The exception is apparently
coming out of some Socket class activity (for which we also have exception
handling around).

I thought that these would have been, at the very least, turned into
SEHExceptions and I would still catch them?

Can anyone shed any light on this? How can I guarantee that I can catch any
type of exception that may be thrown.

 

[Jeroen Mostert]

I have an application that is, occasionally, being terminated without any
apparent error. I have a try/catch around the entire main routine and no
exception is being caught.

First of all, wrapping the main routine will only take care of a single
thread, so it's pretty much pointless -- other threads will be created even
if you don't do it explicitly.

To see all unhandled (managed) exceptions, attach an event handler to
AppDomain.UnhandledException. This is *not* an exception handler (your
process will still die) but it gives you an opportunity to log the unhandled
exception, which is very useful.

But, when I look into the system event log, there is a report of an
uncaught Win32 exception. The exception is apparently coming out of some
Socket class activity (for which we also have exception handling around).

More details would be good. Lay the dirty bits on us, man. Stack traces?
Registers? The HRESULT of the exception? Do you get a minidump? What's the
exact message in the event log?

I thought that these would have been, at the very least, turned into
SEHExceptions and I would still catch them?

This only happens when there's a clean transition from managed to unmanaged
code -- the framework will wrap such calls in SEH and convert these into
managed exceptions. It's possible for unmanaged code (including the CLR
itself) to hit an exception which is not inside any handler, for example,
code running in a separate thread. When that happens, your process dies.

Can anyone shed any light on this? How can I guarantee that I can catch any
type of exception that may be thrown.

You can't (*), and you don't want to. There's no point to catching unhandled
unmanaged exceptions in managed code, because the process is probably in an
inconsistent state and there's no point in continuing. This is the same
reason why unhandled *managed* exceptions terminate the process, only even
more so.

Your best bet is to find out what's causing the unexpected exceptions (could
be anything from a badly behaved Winsock provider extension to an internal
error in the CLR) and getting it fixed or working around it. Without more
details, it's hard to tell what could be going wrong.

 

[Thomas W. Brown]

First of all, wrapping the main routine will only take care of a single
thread, so it's pretty much pointless -- other threads will be created even
if you don't do it explicitly.

To see all unhandled (managed) exceptions, attach an event handler to
AppDomain.UnhandledException. This is *not* an exception handler (your
process will still die) but it gives you an opportunity to log the unhandled
exception, which is very useful.

Good point and thanks for the AppDomain tip -- that's pretty much what I was
looking for. While I would like to keep my app from dying, as you point out
later, that's not always possible.

-- Tom

 

[Mike Blake-Knox]

 How can I guarantee that I can catch any 
type of exception that may be thrown.

You need to be sure that you have try/catch blocks around any code
that's called directly by the operating system. This includes code run
by a threadpool thread and by asynchronous completion handlers. It's
easy to miss in something like handling the completion of a socket
receive.

You should also have a handler for unhandled exceptions. That's done
like:

AppDomain.CurrentDomain.UnhandledException += new
UnhandledExceptionEventHandler(OnUnhandledException);

Hope this helps

Mike