OutOfMemoryExce ption and UnhandledExcept ionEventHandler

[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
OutOfMemoryExce ptions. 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 OutOfMemoryExce ption was large then there
probably really is a little memory left. I am causing/throwing the
OutOfMemoryExce ption from a Thread other than the main one, so this is a
case where UnhandledExcept ionEventHandler works for other types of
exceptions.

Unfortunately, unless I'm missing something it looks like my
UnhandledExcept ionEventHandler doesn't get called for OutOfMemoryExce ptions,
even if there is plenty of memory and I just threw the OutOfMemoryExce ption
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 ApplicationExce ption subclass and recognize that in the
UnhandledExcept ionEventHandler . 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 OutOfMemoryExce ption 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 ExecutionEngine Exception, which is
completely fatal, possibly a StackOverflowEx ception).

"Ryan Seghers" <no*****@nowher e.com> wrote in message
news:T1******** *********@news. uswest.net...

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
OutOfMemoryExce ptions. 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 OutOfMemoryExce ption was large then there
probably really is a little memory left. I am causing/throwing the
OutOfMemoryExce ption from a Thread other than the main one, so this is a
case where UnhandledExcept ionEventHandler works for other types of
exceptions.

Unfortunately, unless I'm missing something it looks like my
UnhandledExcept ionEventHandler doesn't get called for OutOfMemoryExce ptions, even if there is plenty of memory and I just threw the OutOfMemoryExce ption 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 ApplicationExce ption subclass and recognize that in the
UnhandledExcept ionEventHandler . I'd prefer to handle it in one place for
the entire service AppDomain.

Any ideas on good ways to handle this?

Ryan Seghers

[Ryan Seghers]

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

stable the clr is when an OutOfMemoryExce ption 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
ApplicationExce ption to test that.

As far as stability after an OutOfMemoryExce ption 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 ExecutionEngine Exception, which is
completely fatal, possibly a StackOverflowEx ception).

Apparently not. Evidently OutOfMemoryExce ption is considered as fatal as
the other two you mentioned. When I explicitly throw an
OutOfMemoryExce ption it doesn't get to the exception handler. When I throw
an ApplicationExce ption 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
OutOfMemoryExce ption will not go to UnhandledExcept ionEventHandler . I am
afraid that there is not a good method to handle this.

In addition, if the CLR throws OutOfMemoryExce ption, 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/de...us/cpguide/htm
l/cpconbestpracti cesforhandlinge xceptions.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
"Ryan Seghers" <no*****@nowher e.com> wrote in message
news:cN******** *********@news. uswest.net...

If your handler getting called for other exceptions? I have no idea how
stable the clr is when an OutOfMemoryExce ption 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
ApplicationExce ption to test that.

As far as stability after an OutOfMemoryExce ption 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.

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 ExecutionEngine Exception, which is completely fatal, possibly a StackOverflowEx ception).

Apparently not. Evidently OutOfMemoryExce ption is considered as fatal as
the other two you mentioned. When I explicitly throw an
OutOfMemoryExce ption it doesn't get to the exception handler. When I

throw an ApplicationExce ption 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.
ArgumentExcepti on) 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.