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.
When installing IIS, make sure that you also install the following:
5. In the Edit Web Site Failed Request Tracing Settings dialog box, configure the following:
6. Click OK.
Failed-request tracing logging is now enabled for the Default Web Site. Check the %windir%\system32\inetsrv\config\applicationHost.config file to confirm that the configuration looks as follows:
<!-- site & app defaults -->
<site name="Default Web Site" id="1">
<!-- other site configuration -->
<traceFailedRequestsLogging enabled="true" />
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.
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">
<add provider="WWW Server" areas="Security" verbosity="Verbose" />
<failureDefinitions statusCodes="404.2" />
© 2020 Digcode.com. All rights reserved.