Any single unhandled exception (not an exception thrown in code) - an exception at the CLR/Framework level that occurs during service execution, will not be caught and wrapped as a fault by IIS. Instead the w3wp.exe process will be torn down and any app domains inside will be lost, the app pool will keep running under default settings - the default behaviour of IIS is to re-spawn a new worker process (which is expensive). In this case the client would see ---- not much, a socket error or timeout.
This behaviour was new for .net version 2 and deliberate, it prevents unhandled exceptions of this type getting lost (or “swallowed”), the OS will also attempt 11th hour logging – to the event log – so that you have information to help you debug
For more Info
See here
And here
I didn’t know about the setting: IIS, App pool, Advanced Settings, Rapid-fail protection.
This exists in IIS6 and 7 and it’s designed to protect your server, in the possible event that any “unhandled exception” isn’t a one off, or glitch, after a set number IIS stops the app pool based on those user settings.
The process of recycling is very expensive which means this behaviour is obviously useful on a number of levels. The caller gets “HTTP Error 503. The service is unavailable” once the app pool stops.
It’s actually quite difficult to test this, after all just throwing an exception won’t work, don’t want a fault, and forcing CLR/.net to throw an exception is contrived, but you can test this behaviour in a deployed service by adding the following line into your service
Environment.FailFast("My message: Killing host");
Note: You can add a catch for AppDomain UnhandledException but (again from .net 2) this won’t stop the app domain crashing.
Notes:
Info on “Watson bucket” problem signatures
