IIS Request-Based Tracing

Applies To: Windows Server 2003, Windows Server 2003 with SP1

Use IIS request-based tracing to track requests in IIS components like ASP, SSL filters, and ISAPI extensions. Request-based tracing also allows you to trace a request to a specific URL or a group of URLs, which can further refine your troubleshooting efforts.

When an HTTP request is picked up by an IIS user mode worker process (meaning the request was not served by the HTTP.sys response cache), the request passes through multiple components before a response is generated and IIS sends the response back to the client computer. Depending on the request type, the request is processed by the static file request handler, the CGI request handler, or an ISAPI extension handler. Requests that enter an ISAPI extension handler are processed further by Active Server Pages (ASP) or ASP.NET pages. If a request fails or becomes unresponsive as it makes its way through these components, error-reporting channels like the Windows NT Event Log and the HTTP Error log might not provide enough detail to help you locate the source of the problem. Requested-based tracing will provide the details you need to help locate the source of the problem.

In the context of Event Tracing for Windows (ETW), IIS components are called providers because they provide trace data or events to ETW.

From a high level, request-based tracing works as shown here:

1. The administrator enables a tracing session on the IIS server from a command prompt.

2. ETW notifies IIS providers to begin reporting trace events.

   

3. A request enters the IIS worker process. As the request moves through IIS, the providers report events to the ETW infrastructure. In this example, the worker process reports a request start event, ASP_Start_Request, and then each of the IIS components report Start and End events. Finally, the worker process reports a request end event, ASP_End_Request. ETW writes these events to the trace log. If a request experienced a change while processing, for example the client computer disconnected while the request was on the ASP queue, ASP would report the ASP_CLIENT_DISCONNECTED event. If a request experienced an error, ASP would report an event that described the source of the problem, for example, ASP_FILE_NOT_FOUND or ASP_FILE_ACCESS_DENIED.

   

4. The administrator stops the trace session and reviews the trace log to locate the source of the problem. Problems are typically identified by error events or a START event that does not contain a corresponding END event.

   

You can specify which providers report events to ETW during a specific trace session. You can also customize how much trace data providers report to ETW. For example, you can configure a trace session so IIS providers report error events only, or you can configure the trace session so providers report informational events and error events. You can also determine which URLs to trace, thereby focusing your troubleshooting efforts on a specific application.