IIS 7 and Rapid Fail Protection
Anyway – IIS 6 and 7 both use separate worker processes to handle all request processing and there’s monitoring built into the IISADMIN service that detects the crash and automatically restarts the application after a hard crash...
Uh, that’s the way it’s supposed to work <s>. IIS 7 introduces a new feature called Rapid Failure Protection which is on by default. What it does, it checks for a specified number of hard failures like the ones I was testing in a given time period. The default is 5 failures in 5 minutes after which the Application Pool will crash and not restart automatically.

After a failure of this sort you end up with a stopped application pool which I talked about a couple of weeks back and which looks like this:

When this is the case the server returns a 503.2 – Service unavailable error.
Anyway, I suppose this is a useful feature, just a little unexpected in its default configuration. The idea is that if you have a service that continues to crash you probably don’t want to have it going up and down forever and consuming resources and potentially corrupting data as it keeps failing. However, I think the timeout interval and failure mode is maybe a little too long. 5 failures in ONE minute would maybe be better as it would likely rule out debugging scenarios.
Ntoice that you can also specify an EXE to run when the Application Pool is shut down. This might allow you to send an email notification or some other sort of reminder to let you know right now that something's wrong. It might also allow you to take the machine out of a load balancing cluster if that's possible externally. Very cool. It's nice to see some of the new features have been thought through well to provide some very useful functionality.
IIS 7 features many new administration features like this and while useful it's going to take some time to get a handle on the subtle ways that things have changed in the default configuration.
The Voices of Reason
# re: IIS 7 and Rapid Fail Protection
The real issue I had was that I need to manually restart the pool and in the meantime my visitors would get an 503 error.
I used the shutdown executable option and parameters to have it automatically restart.
Shutdown executable: c:\Windows\System32\inetsrv\Appcmd.exe
Shutdown parameters: start APPPOOL <your website>
Alternatively you can choose to do an iisreset and if that fails a server reboot:
Shutdown executable: c:\Windows\System32\iisreset.exe
Shutdown parameters: /rebootonerror
# re: IIS 7 and Rapid Fail Protection
We had the same issue. However, the real problem we have is restarting the App Pool in IIS because upon Rapid Fail Protection triggered the disable. The App Pool does not seem that it stopped as it still showing as Started. When we try to restart it, it was notifying that it cannot be restarted and took an hour for it to restart upon keeping on trying to restart. Anyone know why this happens, the App pool not starting?
# re: IIS 7 and Rapid Fail Protection
# re: IIS 7 and Rapid Fail Protection
our app pool is crashing, but it looks like it is being caused by an APP! running on the 2.0 app pool. No file permission errors in the log, just a shutdown message.
we are using IIS6, so this might not be the right place to put this..but it is causing major havoc on our production system (a lot of manual creating of orders, since our app isnt working..big headaches)
Do you know of a good way through c# to purposely crash the app pool, so we can at least have something to test with (I am almost certain it has to do with our threading..)??
thanks!
# re: IIS 7 and Rapid Fail Protection
# re: IIS 7 and Rapid Fail Protection
Interesting too - I think this may be the reason for my occasional problems with IIS not restarting properly some time back. I notice on IIS 6 all my Application Pools except the default one had this option off. So I suspect at some point Rapid Fail Protection kicked in and disabled the default App Pool and only a reboot allowed it to restart.
# re: IIS 7 and Rapid Fail Protection