OutOfMemoryException and UnhandledExceptionEventHandler

[Ryan Seghers]

I've got a program that has no user interface (like a service but not
actually a Windows Service yet) in which I'd like to handle
OutOfMemoryExceptions. I'd at least like to log the failure before exiting,
if possible. I understand that it probably takes some memory to continue
operating, even just to write a message to an open file, but if the
allocation that triggered the OutOfMemoryException was large then there
probably really is a little memory left. I am causing/throwing the
OutOfMemoryException from a Thread other than the main one, so this is a
case where UnhandledExceptionEventHandler works for other types of
exceptions.

Unfortunately, unless I'm missing something it looks like my
UnhandledExceptionEventHandler doesn't get called for OutOfMemoryExceptions,
even if there is plenty of memory and I just threw the OutOfMemoryException
explicitly myself.

Doing a try/catch at the top of every thread (there are many) is
undesirable, plus any particular worker thread doesn't have any idea what
should be done for the whole service when this happens - so I'd have to
convert to my own ApplicationException subclass and recognize that in the
UnhandledExceptionEventHandler. I'd prefer to handle it in one place for
the entire service AppDomain.

Any ideas on good ways to handle this?

Ryan Seghers

 

[Dave]

If your handler getting called for other exceptions? I have no idea how
stable the clr is when an OutOfMemoryException occurs - you may be very
constrained on what you can do. At the very least I would pre-allocate any
objects you need to log the exception.

I would expect that so long as your handler is subscribing to the unhandled
exception from the context of the default appdomain you should be able to
get all exceptions (except probably the ExecutionEngineException, which is
completely fatal, possibly a StackOverflowException).

 

[Ryan Seghers]

If your handler getting called for other exceptions? I have no idea how

stable the clr is when an OutOfMemoryException occurs - you may be very
constrained on what you can do. At the very least I would pre-allocate any
objects you need to log the exception.

Yes, my handler gets called for other exceptions. I explicitly threw an
ApplicationException to test that.

As far as stability after an OutOfMemoryException I agree. However, I
suppose statistically speaking that on average when an allocation fails
there will still be half the amount of memory I requested left. Sure would
be nice if the CLR reserved an additional small block of memory for the
out-of-memory case. Then it could free that block and then let my exception
handler run.

I would expect that so long as your handler is subscribing to the unhandled
exception from the context of the default appdomain you should be able to
get all exceptions (except probably the ExecutionEngineException, which is
completely fatal, possibly a StackOverflowException).

Apparently not. Evidently OutOfMemoryException is considered as fatal as
the other two you mentioned. When I explicitly throw an
OutOfMemoryException it doesn't get to the exception handler. When I throw
an ApplicationException in the same place and under the same circumstances
it does get to the handler.

 

[Tian Min Huang]

Hello Ryan,

Thanks for your post.

Based on my experience and research, you are correct that the
OutOfMemoryException will not go to UnhandledExceptionEventHandler. I am
afraid that there is not a good method to handle this.

In addition, if the CLR throws OutOfMemoryException, all of your code will
be blown out of the water, and the CLR will terminate your process
directly. While we can catch it if the GC or your own code throws this
exception.

Also, I'd like to recommend you the following MSDN article:

Best Practices for Handling Exceptions
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconbestpracticesforhandlingexceptions.asp

Please feel free to let me know if you have any problems or concerns.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Dave]

inline

Yes, my handler gets called for other exceptions. I explicitly threw an
ApplicationException to test that.

As far as stability after an OutOfMemoryException I agree. However, I
suppose statistically speaking that on average when an allocation fails
there will still be half the amount of memory I requested left. Sure would
be nice if the CLR reserved an additional small block of memory for the
out-of-memory case. Then it could free that block and then let my exception
handler run.

It preallocates an exception object for those types so they can ensure that
an exception of those types are always available for use. I would not
therefore assume that the runtime will call your catch handler - it may nust
use that type for logging and diagnostic purposes.

Apparently not. Evidently OutOfMemoryException is considered as fatal as
the other two you mentioned. When I explicitly throw an
OutOfMemoryException it doesn't get to the exception handler. When I throw
an ApplicationException in the same place and under the same circumstances
it does get to the handler.

There must be code in the clr's exception handler looking for specific
exception types and giving them special handling (i.e. initiating an
abnormal termination) when encountered. There's supposed to be a single SEH
frame in the CLR around the entire .net application that all exceptions get
funneled through and it is likely there where the code forces the
application to terminate.

This means that there are some types that you cannot throw. At the very
least MSDN should document this because there are some exceptions defined in
modules in the CLR that are there for applications to use (e.g.
ArgumentException) and obviously there are others that are not. For these
types I am surprised that MSFT allowed user applications to even create
exceptions of this type; they could have made the constructor private so
that you could not new one of these and then provide an internal factory
method for their own use.

MSFT should document which exceptions are handled like this so that
application writers would know which exceptions they should never throw. It
would be even better if applications could not even create those exceptions.
I currently know of 3 like this; OutOfmemory, StackOverlow, ExecutionEngine.
I would like to know if there are others.

I would treat those 3 exceptions as fatal and just rethrow them if I ever
catch one (not likely), but never throw one myself.