What is the lifecycle of a ASP.Net requests?

The logic behind the processing of each ASP.NET request is given in the following steps:
1. When the request first arrives, IIS examines the resource type and calls into the ASP.NET ISAPI extension. If the default process model is enabled, aspnet_isapi queues the request and assigns it to the worker process. Any request data is sent through asynchronous I/O. If the IIS 6 process model is enabled, the request is automatically queued to the worker process (w3wp.exe) handling the IIS application pool to which the application belongs. The IIS 6 worker process doesn't know anything about ASP.NET and managed code. It is limited to processing the *.aspx extension and loading the aspnet_isapi module. When the ASP.NET ISAPI works under the IIS 6 process model, it behaves differently and just loads the CLR in the context of the w3wp.exe worker process.
2. On receiving the request, the ASP.NET worker process notifies the ASP.NET ISAPI that it is going to serve it. The notification takes place through synchronous I/O. The synchronous model is used because for consistency the worker process can't start processing a request that is not yet marked as "executing" in the ISAPI's internal requests table. A request that is being serviced by a particular worker process cannot be reassigned to a different process unless the original one dies.
3.The request then executes in the context of the worker process. There might be circumstances in which the worker process needs to call the ISAPI back in order to complete the request. In that case, the worker process uses synchronous pipes because this would preserve the sequence of the request-processing logic.
4.When finished, the response is sent to aspnet_isapi opening an asynchronous pipe. The state of the request now changes to "Done"; later on the request will be removed from the table. If the worker process crashes, all the requests it was handling remain in the "executing" state for a while. When aspnet_isapi detects that the worker process is dead, it automatically aborts the request and frees any associated IIS resources.