[This is preliminary documentation and subject to change]
When a worker process fails, the communication channel with WAS is dropped. WAS detects this failure and initiates appropriate actions, typically sending an error or warning to the event log and restarting the process. IIS can be configured so that if a particular application pool experiences consecutive multiple failures, the application can be automatically disabled, allowing for rapid fail protection. The application pool is taken out of service and placed in a mode where the kernel-mode driver immediately returns a 503 Service Unavailable out-of-service message to any requests to that application pool. In addition, and administrator can place any application pool into a out-of-service mode, if, for example, a serious application problem exists.
During the restart process after a worker process failure, any requests that the worker process was in the midst of handling are lost and Http.sys returns an error. If the process was running within a Web garden, any subsequent requests that arrive while the worker process is restarting are routed to other equivalent processes in the same pool. If the process was not pooled but not associated with a Web Garden (because only that worker process was serving the application pool), requests are queued until the replacement process comes online.
For example, you have an application pool setup for new applications. Because this is running on a production system, you would naturally want to protect your system. Enabling rapid fail protection prevents the system from thrashing, that is spending more time starting processes up than actually processing requests.