A process serving application pool terminated unexpectedly

This error message appears on a third party ASP.NET application that we have installed and each time it happens the application seems to be restarting.
What’s more, we have inserted a custom HttpModule into the application that serves as a global event handler… yet this does not catch this particular error.

What is going on?

There are actually two errors we see in the System event log:

A process serving application pool ‘xxxx’ terminated unexpectedly. The process id was ‘yyyy’. The process exit code was ‘0×0′.

A process serving application pool ‘xxxx’ suffered a fatal communication error with the World Wide Web Publishing Service. The process id was ‘yyyy’. The data field contains the error number.

Both these errors refer to unhandled exceptions in .NET 2.0 where an error is generated outside of the asp.net request such as a worker thread.
However, this never used to happen in previous frameworks…

In 1.0 and 1.1 any exception that occurred outside the context of a request would cause that thread to die… and that was it. The global error handler would not catch it, it simply died away.
In some applications this was a very bad thing – any open resources in this thread would cause memory leaks and all manner of other unintended consequences.

As such, in 2.0 the default behaviour is for the application to quit – hence these messages in the event log.

Now this is where we can now understand why our HttpModule doesn’t report the error…

Because the exception is outside the context of an asp.request and therefore not part of a HttpApplication/HttpModule process any custom error handlers running from application events do not catch the error.

So how can we catch this error and log it so we can identify the real issue behind the event log error?

I’ve been experimenting with the AppDomain events and in my next post will discuss how I’ve used it to trap these errors and identify where to start to resolve the problem.