An application pool on one of our servers periodically stops accepting requests, and the pool state shows as disabled. The timing suggests Rapid-Fail Protection may be involved, but I’m not sure how to connect the shutdown to the original worker process failure.
Which events or logs are most useful for finding the first crash rather than just seeing that IIS disabled the pool? I’m also trying to distinguish an application startup exception from a native crash or a dependency that fails intermittently.
For anyone who has investigated this: do you usually leave the protection threshold alone while diagnosing, or temporarily adjust it in a controlled environment?
IIS treats a run of worker-process crashes as a sign that the pool may be unable to start reliably. Rather than keep launching processes that fail in the same way, it stops the pool after the configured crash limit is reached. This behavior is called Rapid-Fail Protection.
The setting is a threshold, not a diagnosis. IIS can detect that a worker process exited unexpectedly, but it cannot tell from that fact alone whether the cause was an unhandled application exception, memory pressure, a permissions problem, or a faulty native module. A shared issue in startup configuration can also make each new process fail immediately.
To find the underlying cause, compare the timestamps of the failures with entries in the Windows event logs, especially events from WAS and the application runtime. Check recent changes to startup configuration, the application pool identity, and any native components loaded by the site. If the events do not identify the fault, a crash dump can show what the worker was doing just before it exited.
In short, the pool is disabled because repeated failures look like a persistent fault, not a one-off restart. Treat the disablement as a useful signal to investigate the crash pattern before simply raising the limit.
IIS disables an application pool when Rapid-Fail Protection detects repeated worker process crashes. It is a safeguard: if a worker keeps failing, IIS stops restarting it in a loop and returns errors—often HTTP 503—instead of letting the problem continue unchecked.
By default, Rapid-Fail Protection is enabled and the pool is stopped after five failures within a five-minute period. An administrator can change that threshold and time interval in the application pool’s Advanced Settings, but raising the limit or turning the feature off can hide the underlying fault.
What to check
Look in Windows Event Viewer, especially the System and Application logs, for messages from WAS or the application around the time the pool stopped. Then investigate the application or a native module, startup errors, recent deployments, and the pool’s identity or configuration. If the event details do not identify the crash, capture and inspect an application crash dump.
After addressing the cause, start the pool again and watch for another failure. If it stops repeatedly, focus on the crash evidence rather than repeatedly restarting it.