Troubleshooting Failed Requests Using Tracing in IIS

Request-based tracing is available both in stand-alone IIS Servers and on Windows Azure Web Sites (WAWS) and provides a way to determine what exactly is happening with your requests and why, provided that you can reproduce the problem that you are experiencing. Problems like poor performance on some requests, or authentication-related failures on other requests, or the server 500 error from ASP or ASP.NET can often be difficult to troubleshoot--unless you have captured the trace of the problem when it occurs.

Failed-request tracing is designed to buffer the trace events for a request and only flush them to disk if the request "fails," where you provide the definition of "failure". If you want to know why you're getting 404.2 error messages or request start hanging, use failed-request tracing.

Install the failed-request tracing module

When installing IIS, make sure that you also install the following:

• Tracing (under World Wide Web Services - Health and Diagnostics - Tracing)

Configure Your Failure Definitions

In this step, you will configure the failure definitions for your URL, including what areas to trace. You will troubleshoot a 404.2 that is returned by IIS for any requests to extensions that have not yet been enabled. This will help you determine which particular extensions you will need to enable.

1. Open a command prompt with administrator user rights.
2. Launch inetmgr.
3. In the Connections pane, expand the machine name, expand Sites, and then click Default Web Site.
4. Double-click Failed Request Tracing Rules.

5. Click Finish.

6. In the Actions pane, click Add....

7. In the Add Failed Request Tracing Rule wizard, on the Specify Content to Trace page, select All content (*). Click Next.

8. On the Define Trace Conditions page, select the Status code(s) check box and enter 404.2 as the status code to trace.

9. Click Next.

10. On the Select Trace Providers page, under Providers, select the WWW Server check box. Under Areas, select the Security check box and clear all other check boxes. The problem that you are generating causes a security error trace event to be thrown. In general, authentication and authorization (including ISAPI restriction list issues) problems can be diagnosed by using the WWW Server – Security area configuration for tracing. However, because the FREB.xsl style sheet helps highlight errors and warnings, you can still use the default configuration to log all events in all areas and providers.

Under Verbosity, select Verbose.

11. Click Finish. You should see the following definition for the Default Web Site:

IIS Manager writes the configuration to the %windir%\system32\inetsrv\config\applicationHost.config file by using a <location> tag. The configuration should look as follows:

<location path="Default Web Site">
<system.webServer>
<tracing>
<traceFailedRequests>
<add path="*">
<traceAreas>
<add provider="WWW Server" areas="Security" verbosity="Verbose" />
</traceAreas>
<failureDefinitions statusCodes="404.2" />
</add>
</traceFailedRequests>
</tracing>
</system.webServer>
</location>