IIS 8.5 Tracing: Expertly Troubleshoot Failed Requests & Enhance Web App Performance

Table of Contents

Introduction to Failed Request Tracing in IIS 8.5¶

Effectively diagnosing issues within web applications can often be a complex and time-consuming task. Internet Information Services (IIS) 8.5 offers a robust solution for this challenge: Failed Request Tracing (FRT). This powerful feature allows administrators and developers to gain deep insights into how IIS processes requests, making it an invaluable tool for identifying the root cause of various web application problems.

FRT is particularly useful for troubleshooting issues such as inconsistent performance, authentication failures, or generic HTTP 500 server errors that might be difficult to reproduce or diagnose through standard logging. It operates on a unique “buffer and flush” mechanism, where trace events for a request are buffered in memory and only written to disk if specific failure conditions are met. This intelligent approach minimizes disk I/O, ensuring that only relevant diagnostic data is captured.

This sophisticated tracing mechanism empowers you to pinpoint exactly what went wrong during a request’s lifecycle within IIS. Whether your web application is returning a specific HTTP status code like 401 (Unauthorized) or 404 (Not Found), or if requests are simply taking too long to process, FRT can provide the detailed event sequence necessary for effective troubleshooting. This article will guide you through enabling, configuring, and utilizing Failed Request Tracing on an IIS 8.5 server to enhance your web application’s stability and performance.

The subsequent sections will cover the essential steps to master FRT: enabling the tracing module, configuring log file semantics, defining specific URLs and failure conditions for tracing, and finally, generating and analyzing the resulting trace logs.

Prerequisites for Implementing Failed Request Tracing¶

Before diving into the configuration of Failed Request Tracing, ensure your IIS 8.5 environment is properly set up with the necessary components and safeguards. Adhering to these prerequisites will provide a stable foundation for your tracing efforts and prevent potential issues during the process.

Installing IIS 8.5 with Essential Features¶

Your first step is to ensure that IIS 8.5 is correctly installed on your Windows Server 2012 R2 machine. After installation, you can verify its functionality by navigating to http://localhost/ in your web browser, which should display the default IIS splash screen. If IIS is not yet installed, refer to the official documentation for detailed installation instructions.

Crucially, specific IIS features must be installed to support Failed Request Tracing and the associated functionalities. The tracing module itself is a distinct component, and for web applications, the ASP.NET features are often required for comprehensive request processing. Ensure the following features are selected during or after your IIS installation:

Feature Category	Specific Feature	Description
Web Server (IIS) / Web Server		Core IIS functionality
Application Development Features	ASP.NET 3.5	Supports applications built on .NET Framework 3.5 and earlier, providing necessary runtime components.
	ASP.NET 4.5	Supports applications built on .NET Framework 4.5 and later, crucial for modern web applications.
Health and Diagnostics	Tracing	The fundamental module that enables request-based tracing, including Failed Request Tracing.

These features provide the necessary runtime environments and diagnostic tools for IIS to effectively monitor and log web requests. Without the ‘Tracing’ feature, the Failed Request Tracing module will not be available in IIS Manager.

Administrator Privileges¶

To perform the tasks outlined in this guide, including modifying IIS configurations and file system permissions, you must be logged in with an administrator account. This ensures you have the necessary permissions to enable tracing, create and modify configuration files, and access log directories. Always exercise caution when operating with administrative privileges and follow your organization’s security best practices.

Backing Up IIS Configuration¶

Before making any significant changes to your IIS configuration, it is highly recommended to create a backup. This precautionary measure allows you to easily revert to a known working state if any issues arise during the configuration process. IIS provides a convenient command-line tool, appcmd.exe, for managing backups.

To create a backup, open an elevated Command Prompt (Run as administrator). Simultaneously press the Windows logo key and the X key, then select Command Prompt (Admin) and confirm with Yes. In the command prompt window, execute the following command:

%windir%\system32\inetsrv\appcmd add backup cleanInstall

This command will create a new backup folder named cleanInstall within %windir%\system32\inetsrv\backup. This folder will contain copies of your IIS configuration files, ensuring you have a restore point.

Creating Sample Content for Testing¶

For the purpose of this demonstration, we will create a simple ASP page that will serve as our test target for generating a failed request. This helps in understanding how Failed Request Tracing captures events for specific file types.

Follow these steps to create your sample content:

1. Navigate to the default web root directory: %systemdrive%\inetpub\wwwroot.
2. If there’s existing content, move it to a safe location or delete it to avoid conflicts.
3. Create a new blank file in this directory and name it test.asp.

4. Open test.asp with a text editor (e.g., Notepad) and paste the following content:

   <h2>Failed Request Tracing Lab</h2><br>
   <br>Today's date is <% response.write(Date()) %>
   

This basic ASP page will display a header and the current date when processed correctly. Our goal is to intentionally cause this page to fail, triggering a trace log.

Disabling ASP for Demonstration¶

To effectively demonstrate Failed Request Tracing, we will intentionally disable the Classic ASP feature for the Default Web Site. This action will cause requests for .asp files to fail with a specific HTTP status code, 404.2, which we will then configure FRT to capture. It’s important to note that this is done purely for the purpose of this example and should be re-enabled for any production ASP applications.

To disable ASP, follow these steps:

1. Open IIS Manager. You can do this by typing inetmgr in the Run dialog (Windows Key + R).
2. In the Connections pane, select your server (the top-level node).
3. In the main content pane, double-click on ISAPI and CGI Restrictions.
4. Locate Active Server Pages in the list.
5. In the Actions pane on the right, click Deny. The status for Active Server Pages will change to Not Allowed.

This action prevents IIS from processing .asp files, creating the desired failure condition for our tracing exercise.

Configuring Failed Request Tracing in IIS 8.5¶

Once the prerequisites are met, we can proceed to enable and configure Failed Request Tracing for your website. This involves activating the module for a specific site and then defining the precise conditions under which a request should be considered “failed” and subsequently logged.

Step 1: Enabling FRT for Your Website and Setting Log Directory¶

The first step in leveraging Failed Request Tracing is to enable it for the target website and ensure the log file directory is correctly configured. This sets up the foundational mechanism for capturing trace data.

1. Open an elevated Command Prompt and navigate to %systemdrive%\windows\system32\inetsrv.
2. Type inetmgr and press Enter to launch IIS Manager.
3. In the Connections pane on the left, expand your machine name, then expand Sites, and select Default Web Site.
4. In the Actions pane on the right, under the Configure section, click Failed Request Tracing….

5. In the Edit Website Failed Request Tracing Settings dialog box that appears:

   • Select the Enable checkbox.
   • For the purpose of this exercise, you can leave the default settings for the log directory and maximum log file size. The default log directory is typically %systemdrive%\inetpub\logs\FailedReqLogFiles.

6. Click OK.

With these steps, Failed Request Tracing is now globally enabled for the Default Web Site. You can verify this configuration change by examining the applicationHost.config file, located at %windir%\system32\inetsrv\config. Within this file, you will find an entry similar to the following under the <sites> section for your Default Web Site:

<system.applicationHost>
   <!-- other system configuration --> 
   <sites> 
      <site name="Default Web Site" id="1"> 
         <!-- other site configuration --> 
         <traceFailedRequestsLogging  enabled="true" /> 
      </site> 
      <!-- site & app defaults --> 
      <!-- other sites configuration --> 
   </sites> 
   <!-- other system configuration --> 
</system.applicationHost>

This XML snippet confirms that the traceFailedRequestsLogging attribute has been set to enabled="true", signifying that the FRT module is now active for the Default Web Site.

Step 2: Defining Failure Conditions and Trace Areas¶

Once Failed Request Tracing is enabled for a site, the next critical step is to define what constitutes a “failure” and which areas of IIS should be traced when such a failure occurs. This precise configuration ensures that only relevant diagnostic information is captured, preventing an overload of unnecessary log data. For our scenario, we aim to troubleshoot a 404.2 status code, which IIS returns when an extension (like Classic ASP) has not been enabled.

Here’s a conceptual overview of how FRT intercepts and processes requests:
mermaid graph TD A[Client Request] --> B{IIS Web Server}; B -- Intercepts Request --> C{Failed Request Tracing Module}; C -- Buffers Events --> D[Event Buffer]; B -- Processes Request --> E{Application Logic / Modules}; E -- Generates Response --> F{HTTP Response}; F -- Checks Failure Conditions (e.g., Status Code 404.2) --> C; C -- If Failure Detected --> G[Flush Buffer to Log File]; C -- If No Failure --> H[Discard Buffer]; G --> I[Failed Request Log (.xml)]; F --> J[Client Receives Response];

Now, let’s configure the failure definitions in IIS Manager:

1. From the IIS Manager, ensure Default Web Site is still selected in the Connections pane.
2. In the central content pane, double-click on Failed Request Tracing Rules.
3. In the Actions pane on the right, click Add…. This launches the Add Failed Request Tracing Rule wizard.
4. On the Specify Content to Trace page, select All content (*). This rule will apply to all requests within the Default Web Site. Click Next.

5. On the Define Trace Conditions page:

   • Select the Status code(s) checkbox.
   • Enter 404.2 in the provided text box. This tells FRT to log a trace only when a request results in this specific HTTP status code.

6. Click Next.
   

7. On the Select Trace Providers page, you define which components of IIS should generate events for the trace.

   • Under Providers, select the WWW Server checkbox. Clear all other provider checkboxes. The WWW Server provider is responsible for core IIS operations, including security and request handling.
   • Under Areas, select the Security checkbox. Clear all other area checkboxes. Since we are intentionally triggering a security-related restriction (404.2 for an unallowed extension), focusing on the Security area will yield the most relevant information.
   • Under Verbosity, select Verbose. This ensures the maximum level of detail is captured in the trace log, which is ideal for in-depth troubleshooting.

   While focusing on WWW Server and Security is efficient for this specific 404.2 scenario, the freb.xsl stylesheet can effectively highlight errors even with default settings (logging all events). Other trace providers like ASP, ISAPI Extension, ASPNET, and ARR (Application Request Routing) are also available, each focusing on different layers of the request pipeline. For instance, ASPNET would be crucial for diagnosing issues within .NET applications, while ARR tracks URL Rewrite and caching behavior.

   Table: Common Trace Providers and Their Focus
   | Provider | Primary Focus |
   | :-------------- | :---------------------------------------------------------------------------- |
   | WWW Server | Core IIS operations, authentication, authorization, caching, security |
   | ASP | Classic ASP processing and execution |
   | ISAPI Extension| ISAPI filters and extensions invoked by IIS |
   | ASPNET | ASP.NET request processing, application lifecycle events, handler execution |
   | ARR | Application Request Routing, URL Rewrite module, External Cache |

8. Click Finish.
   

You will now see the newly created rule for the Default Web Site in the Failed Request Tracing Rules pane. IIS Manager writes this configuration directly into the web.config file within the inetpub\wwwroot directory of your website. The configuration will resemble the following:

<configuration> 
    <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> 
</configuration>

This web.config entry precisely defines that for all content (path="*"), any request returning a 404.2 status code will trigger a trace. The trace will gather Verbose events specifically from the Security area of the WWW Server provider, ensuring a focused and detailed diagnostic log.

Testing and Analyzing Failed Request Log Files¶

With Failed Request Tracing meticulously configured, the next phase involves generating a failed request and subsequently examining the generated trace log. This practical test will confirm that your FRT settings are working as intended and demonstrate how to interpret the diagnostic data.

Step 1: Generating a Failed Request¶

You have configured IIS to capture trace logs specifically for http://localhost/*.asp requests that result in an HTTP response code of 404.2. Now, let’s intentionally trigger this condition.

1. Open a new Internet Explorer window (or any web browser).
2. In the address bar, type http://localhost/test.asp and press ENTER.

As expected, you should see an “HTTP Error 404.2 - Not Found” error message displayed in your browser. This indicates that IIS successfully intercepted the request for test.asp and, due to the previously disabled ASP feature, returned the specific 404.2 status code. This failure should now have triggered the Failed Request Tracing module to log a detailed trace.

Step 2: Viewing the Failed Request Log File¶

Now that a failed request has been generated, it’s time to locate and analyze the trace log. These logs contain a wealth of information that can pinpoint the exact cause of the failure.

1. Open Windows Explorer and navigate to the default Failed Request Log directory: %systemdrive%\inetpub\logs\FailedReqLogFiles\W3SVC1. The W3SVC1 subfolder corresponds to the Default Web Site.

   Within this directory, you will find several files. IIS generates one .xml log file for each failed request that matches your configured rules (e.g., fr000001.xml, fr000002.xml). Crucially, IIS also generates a freb.xsl stylesheet in each log directory. This stylesheet transforms the raw XML log into a human-readable, formatted HTML page, making analysis significantly easier.
   

2. Locate the .xml log file corresponding to the 404.2 error you just generated (it will likely be the most recent one). Right-click on this XML file, select Open With, and then choose Internet Explorer.

   • Important Note for Internet Explorer Users: If this is your first time opening a Failed Request Tracing file in Internet Explorer, you might encounter a security warning related to “Enhanced Security Configuration.” This often prevents local content from running scripts or stylesheets. If this occurs, you will need to add about:internet to your list of trusted sites to allow the freb.xsl stylesheet to function correctly.
     

3. To add about:internet to trusted sites:

   • In Internet Explorer, click the Tools menu (or the gear icon).
   • Select Internet Options.
   • Go to the Security tab.
   • Select Trusted sites and then click the Sites button.
   • In the Add this website to the zone: field, type about:internet and click Add.
   • Click Close, then OK to exit the Internet Options. You may need to refresh or reopen the XML file.

Interpreting the Request Summary Page¶

After successfully opening the XML file with Internet Explorer and allowing the freb.xsl stylesheet to render, you will be presented with a comprehensive Request Summary page. This page provides an organized and intuitive overview of the failed request.

At the top of the page, a summary of the failed request details is logged, including the URL, the HTTP status code, and the time taken. Crucially, the Errors & Warnings table on this page highlights any events with a WARNING, ERROR, or CRITICAL ERROR severity level.

In our example, you will likely find an entry with a WARNING severity level, clearly identifying “ISAPI RESTRICTION” as the cause. The log will explicitly state that the image (in this context, “image” refers to the handler for the file type) that you tried to load was %windir%\system32\inetsrv\asp.dll. This precise detail immediately confirms that the Classic ASP ISAPI extension, responsible for processing .asp files, was explicitly denied or not allowed to execute, leading to the 404.2 error. This clear diagnosis demonstrates the power of FRT in quickly pinpointing the root cause of seemingly ambiguous errors.

For an even deeper dive, you can open the raw XML file directly using a text editor (like Notepad or Visual Studio Code). This will display all the raw event data captured by the tracing module, providing every detail in its original, unstructured format. While less readable than the XSL-rendered page, the raw XML is invaluable for advanced debugging and for understanding the granular sequence of events within IIS.

Summary of Failed Request Tracing Capabilities¶

Through this practical exercise, you have successfully configured IIS 8.5 to capture detailed traces for requests failing with a specific 404.2 HTTP status code. You’ve also validated that IIS correctly generated and logged the trace for your test.asp request. By analyzing the freb.xml log file, you quickly identified that the failure was due to an ISAPI restriction, specifically the disabling of the ASP extension.

This demonstration merely scratches the surface of Failed Request Tracing’s capabilities. Its flexibility allows for a wide array of troubleshooting scenarios. For instance, you can easily modify your failure definitions to trace other HTTP status codes like 404 (general Not Found), 500 (Internal Server Error), or even ranges of status codes. Beyond HTTP status codes, FRT can also be configured to capture requests that exceed a specific processing time by setting the timeTaken field in your failureDefinitions. This is incredibly useful for diagnosing performance bottlenecks in your web applications.

Failed Request Tracing is an indispensable diagnostic tool for IIS administrators and web developers. It provides clear, event-level insights into the IIS request pipeline, transforming complex troubleshooting tasks into more manageable, data-driven investigations. By leveraging FRT, you can significantly reduce the time spent on problem diagnosis and improve the overall reliability and performance of your web applications.

Restoring Your IIS Configuration¶

Having completed the tasks outlined in this article, it’s a good practice to restore your IIS configuration to its original state, especially if you performed these steps on a production or shared development server. This ensures that any temporary changes made for tracing purposes are reverted.

To restore your backup, open an elevated Command Prompt (Run as administrator) and execute the following command:

%windir%\system32\inetsrv\appcmd restore backup cleanInstall

This command will revert your IIS configuration to the state captured by the cleanInstall backup, effectively undoing the changes made during this tracing exercise.

Conclusion and Call to Action¶

Failed Request Tracing in IIS 8.5 is a powerful and precise tool for diagnosing web application issues, moving beyond guesswork to data-driven solutions. By systematically configuring trace rules and analyzing the detailed logs, you can quickly identify the root causes of failures, from authentication problems to slow performance.

We encourage you to experiment further with different failure definitions, trace providers, and verbosity levels to explore the full potential of FRT in your own environments. Understanding and utilizing this feature will undoubtedly elevate your web application troubleshooting skills.

Do you have specific challenges you’ve faced with IIS applications? Share your experiences or questions in the comments below! We’d love to hear how Failed Request Tracing has helped you, or what other diagnostic tools you find indispensable.