Why does my IIS7 application pool shutdown after an exception in a DLL called from an ASP.NET page?

Question

I\'ve read the posts ASP.NET application pool shutdown problem and IIS 7.5: problem with Application pool but they didn\'t answer my question.

I\'ve got a C# ASP.NET pag

Answer 1

It happened to me once. The real error(in my case) was a stack-overflow that was shutting down the pool.

It seem like IIS was protecting itself from consuming too much resources.

I found the problem using DebugDiag.

Here is where I started: http://www.webdebug.net/index.php/2012/12/collect-iis-crash-dump-with-debugdiag/

I'd like to understand why an exception in an external DLL can cause the IIS application pool to shutdown, even if the exception is being caught inside the DLL and also when calling the DLL's method from within the code behind of the ASP.NET page.

The external dll also run in your application pool. A major crash in this dll will also crash your application pool. Some exceptions can't be handle and the stackoverflow exception is one of them. Subject is discused here. Maybe it is what happen in your case.

Answer 2

Most likely your application pool is being shut down automatically by IIS's Rapid Fail Protection feature, as you note in the linked questions. If you check your event log, there may be multiple unhandled exceptions being thrown in rapid succession.

Simply put, enough unhandled exceptions in a configurable timespan (the default is 5 in 5 minutes) will shut down the AppPool, causing the 503 Service Unavailable response.

The reasoning behind this feature is that if you have a faulty application, you probably don't want it to be automatically restarted on every subsequent request, consuming resources and possibly corrupting data.

I have to admit that this isn't the "default" behavior I would have expected either.

Check out Rick Stahls explanation, it's a bit more in depth.

To really fix this, you need to catch the exception, or prevent the exception from being thrown (like @leppie suggests). Unhandled exceptions are supposed to tear down the entire executing process (meaning that single request/worker process, not IIS) - it makes .Net code much easier to debug, because it doesn't hide the errors or simply hang the application.

Note that this was changed in .Net 2.0:
http://msdn.microsoft.com/en-us/library/ms228965.aspx
http://support.microsoft.com/kb/911816

Update
Based on your update above, I don't think your exception is actually caught, if it is thrown from CreateReport(). That method is executing on a separate thread:

You need a try-catch in the body of CreateReport() if there isn't one already:

public static void CreateReport() {
    try {
        throw new Exception("reducto");
    } catch {
        Console.WriteLine("done did.");
    }
}