Introduction
Request-based tracing provides a good way to figure out what exactly is happening with your requests and why, provided you can reproduce the problem you are experiencing. Problems like poor performance on some requests, or authentication related failures on other requests, or even the server 500 error from ASP or ASP.net can often be very difficult to troubleshoot--unless you have captured the trace of the problem when it occurs.
That is where failed-request tracing comes in. It 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's or request start hanging, use failed-request tracing.
Tasks illustrated in this walkthrough include:
- Enabling the failed-request tracing module
- Configuring failed-request tracing log-file semantics
- Defining URL to keep failed request traces for, including failure definitions & areas to trace
- Generating the failure condition and viewing the resulting trace
Prerequisites
Installing IIS 7.0
IIS 7.0 must be installed first before performing the tasks in this article. Check to see if IIS is installed by browsing to http://localhost/. If IIS 7.0 is not installed, refer to Installing IIS 7.0 on Windows Server 2008 for installation instructions. When installing IIS 7.0, make sure you also install the following:
- ASP.NET (under World Wide Web Services - Application Development Features - ASP.NET)
- Tracing (under World Wide Web Services - Health and Diagnostics - Tracing)
Log In as Administrator
Make sure the account you login as is the administrator account or is in the Administrators group.
Note: Being in the Administrators group does not grant you complete administrator privileges by default. You must run many applications as Administrator, which you can do by right-clicking on the application icon and choosing "Run as Administrator".
Make a Backup
You will need to make a backup of the configuration before executing the following tasks. To do this, run the following:
Click the Start button -> All Programs -> Accessories -> (r-click)Command Prompt -> Run as Administrator
Execute the following command in that command prompt:
%windir%\system32\inetsrv\appcmd add backup cleanInstall
Create Sample Content
Delete everything in the %systemdrive%\inetpub\wwwroot folder
From the Administrator command prompt you started above, paste the attached code into a file in inetpub\wwwroot called
test.asp:
<h2>Failed Request Tracing Lab</h2><br>
<br>Today's date is <% response.write(Date()) %>
Disabling ASP
ASP must be disabled for this task. We disable ASP as an example and only for the purposes of the tasks in this article.
To disable ASP, open the inetmgr.exe (from your Administrator command prompt, run start inetmgr.exe)
In the center pane, double-click on ISAPI and CGI Restrictions.
Disable ASP by selecting Active Server Pages then click Deny under the Actions pane:
Enabling Failed Request Tracing
After enabling failed-request tracing, you need to configure where the log files will reside. In this task, you will enable Failed Request Tracing for the Default Web Site & tell Failed Request Tracing where to put the log files. You will then configure the failure we want to generate failure logs for.
Step 1 : Enabling Failure Request Tracing for the Site & Configure the Log File Directory
From your Administrator command prompt, type start inetmgr.
In the Connections panel, expand the machine name, then Sites folder, then click Default Web Site.
To the right under the Actions pane under Configure, click the Failed Request Tracing… link:
In the next dialog box, configure the following:
- Check the Enable check box.
- Keep the defaults for the other settings.
- Click OK to continue.
Now Failed Request Tracing Logging is enabled for the Default Web Site. Check the %windir%\system32\inetsrv\config\applicationHost.config file to confirm what the configuration looks like. It should look like:
<system.applicationHost>
<sites>
<!-- site & app defaults -->
<site name="Default Web Site" id="1">
<!-- other site configuration -->
<traceFailedRequestsLogging enabled="true" />
</site>
</sites>
</system.applicationHost>
Step 2 : Configuring Your Failure Definitions
In this step, you configure the failure definitions for your URL, including what areas to trace. For this scenario, we troubleshoot a 404.2 returned by IIS 7.0 for any requests to extensions that have not yet been enabled. This helps us figure out which particular extensions we need to enable, and not "enable all unknown extensions".
From your Administrator command prompt, type start inetmgr.
In the Connections panel, expand the machine name, then Sites folder, then click on the Default Web Site.
In the center pane under IIS, double-click Failed Request Tracing Rules
Click Finish.
In the Actions pane, click Add…. This launches the Add Failed Request Tracing Rule wizard.
On the Specify Content to Trace page, click on the All Content (*) option for what to trace & click Next.
In the Define Trace Conditions screen, check the Status Codes check box and enter "404.2" as the status code to trace.
Click Next. The Select Trace Providers page appears.
Select the WWW Server check box and the Security check box under "Areas" (uncheck all other areas that are checked except Security). The problem we 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 using the WWW Server – Security area configuration for tracing. However, as the FREB.xsl style sheet helps highlight errors and warnings, you can still use the default configuration to log all events in all areas & providers.
Under Verbosity, select Verbose.
Click Finish. You should see the following definition for the Default Web Site:
The IIS Manager UI in this step wrote out the configuration to the %windir%\system32\inetsrv\config\applicationHost.config file using a <location> tag. The configuration looks like:
<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>
Testing and Viewing the Failure Request Log File
In this task, we generate the failed request and view the resulting trace log. Remember, we configured IIS 7.0 to capture trace logs for http://localhost/*.asp requests that fail with an HTTP Response code of 404.2. Now verify that it worked.
Step 1 : Generating the Error & the Failure Request Log File
Open a new Internet Explorer window.
Type in the address http://localhost/test.asp
You see the following:
Next, go find the log file.
Step 2 : Viewing the Failure Request Log File
Now that we have generated the failure, use your Administrator command window & navigate over to %systemdrive%\inetpub\logs\FailedReqLogFiles\W3SVC1 & run start . to start an explorer window from that directory:
Notice a few things here. One is that when IIS 7.0 writes out the failed request log file, it writes 1 file out per failed request. The other is that a freb.xsl style sheet is also written out – one per directory. This greatly helps in viewing the resulting failure request log files (such as fr000001.xml above).
Right-click the log file for the 404.2 error and select Open With -> Internet Explorer, which opens it in IE. If this is the first time you are opening a Failed Request Tracing file, you must add the "about:internet" to the list of trusted sites, since Internet Explorer's Enhanced Security Configuration is enabled by default. If this is the case, you see the following:
Click Add… to add the about:internet mark of the web to the list of trusted sites. This allows the XSL to work. You see the following after adding "about:internet" to the list of trusted sites:
Notice that the summary of the failed request is logged at the top, with the Errors & Warnings table calling out any events that are WARNING, ERROR, or CRITICAL ERROR in severity. In this case, we were denied due to ISAPI RESTRICTION. The image we tried to load was %windir%\system32\inetsrv\asp.dll.
Open the raw XML directly using a text editor and look into the contents of each event.
Summary
You have completed two tasks: configuring Failed Request Tracing to capture traces for * if IIS 7.0 returns it with a 404.2 status code; and verified that IIS 7.0 captured the trace for your request. You also verified that the freb*.xml log file did not contain any other requests for the requests we made because they did not have a 404.2 return code. In consulting the failure log file, you determined the cause of the failure as the extension not being enabled for that request. You can also try other non-HTML pages (like gifs or jpgs) and note that the log file does NOT add these traces. You can also easily change this to be 404, or capture the failure if the request takes longer than 30sec by setting the timeTaken field in your failureDefinitions.
Restoring Your Backup
Now that you have completed the tasks in this article, restore the backup. Do the following from an administrator-elevated command prompt:
%windir%\system32\inetsrv\appcmd restore backup cleanInstall
Related Content
Comments