This KB article will discuss how to configure and use failed request tracing rules to troubleshoot and debug Application Request Routing, or ARR.
IIS7 must be installed (which it should be) and the Failed Request Tracing snap-in needs to be installed as well.
Step 1: Installing the tracing role service:
Log on to your server and open Server Manager from Start > Administrative Tools > Server Manager.
In Server Manager, expand Roles and click on Web Servers (IIS)
Scroll down to the Role Services section and click on Add Role Services
Under Health and Diagnostics, check the option for Tracing and click Next and Install
Close Server Manager and open IIS. You will notice a Failed Request Tracing Rules icon under IIS
Step 2: Enabling Failed Request Tracing for the site
In the Connections pane in IIS, click on the site for which you want to enable Failed Request Tracing
In the Actions pane under Configure, click on Failed Request Tracing
Click Enable and keep the defaults for the other settings
Step 3: Creating a Tracing Rule for Failed Requests
With IIS open, double-click on the Failed Request Tracing Rules icon and click Add in the Actions pane.
In the Add Failed Request Tracing Rule window, we will specify the content to trace using the following guidelines:
All Content (*)
tracks all files in a directory
tracks all .aspx files in a directory
tracks all .asp files in a directory
allows you to define failure parameters for a custom set of content.
Once the rule has been specified, click Next.
We will now Define Trace Condition for the rule using the following guidelines:
defines the specific status codes you want to trace. You can enter multiple status codes using a comma to separate each code or refine your status codes using sub status codes, such as "404.2, 500"
defines the maximum amount of time, in seconds, that a request should take
defines the severity level you want to trace from the Event Severity drop-down list. Your options are Error, Critical Error or Warning
Be aware that if all conditions are specified, the first condition that is met will generate the failed request trace log file.
After you click Next, you will be able to Select Trace Providers based on the content you specified to trace in the first window:
lets you trace the start and completion of the execution of an ASP request
lets you see transitions into and out of managed code including *.aspx requests
lets you trace the transition of a request into and out of the ISAPI extension process
lets you trace requests through the IIS worker process
In the Provider Properties section of the Add Failed Request Tracing Rule, you can select one or more of the following Verbosity levels:
provides information that gives context for the request activity
provides information about actions that can cause a process to exit or that are about to cause a process to exit
provides information about components that experience an error and cannot continue to process requests (these errors usually indicate a server-side problem)
provides information about components that experience an error but can continue to process the request
provides general information about the requests.
provides detailed information about requests. This is the default selection
If you selected the ASP.NET trace, under Areas select one or more of the following functional areas for the provider to trace:
- when you want to trace events that are primarily related to entering and leaving parts of the ASP.NET infrastructure
when you want to trace events that are logged as a request enters and leaves various HTTP pipeline modules
- when you want to generate trace events that correspond to the execution of specific ASP.NET page-related events
- when you want to trace events that are logged as part of the new application services functionality
If you selected the WWW Server trace, under Areas select one or more of the following functional areas for the provider trace:
- when you want to trace authentication attempts
- when you want to generate trace events when requests are rejected by the IIS server for security reasons
- when you want to determine how long it takes an ISAPI filter to process the requests
- when you want to trace how long it takes requests for static files to be completed
- when you want to generate trace events when a request is for a CGI file
- when you want to generate trace events for cache operations associated with the requests
- When you want to capture all request notifications, both on entrance and on exit
- when you want to trace events that are logged when a request enters and leaves various HTTP pipeline modules, or to capture trace events for managed modules
Click Finish, and that's it!
Article ID: 873, Created On: 11/9/2012, Modified: 11/30/2012