IIS – Failed Request Tracing Setup

In Learn
Feb 16th, 2016

IIS creates log files by default of all the requests made of it and its response to those requests. The log will normally include the date and time of the request, the HTTP verb being used, the actual resource URL being requested, the browser type and then the HTTP status code returned. This is the W3C format and is the default. The standard IIS logs are stored in the default folder “%SystemDrive%\inetpub\logs\LogFiles” but you may choose to store them wherever you’d like by changing the value in the “directory” textbox within the “Logging” section of your site or application. Within the “Logging” section you can configure various settings and even disable logging all together (though why would you do that).

Sometimes you just need to know a little more information than what the IIS log is giving you. For these instances, you can turn on “Failed Request Tracing Rules”. To use tracing, you need to enable it on your site (this is required whether you’re want tracing on the site level or on an application level within your site).


iis-tracing-alert-2So you’ll want to double-click on the “Failed Request Tracing Rules” icon in the IIS section of the IIS Manager. If tracing hasn’t been enabled for your site, you’ll see this message in your “Alerts” section of the IIS Manager. You can either click on the alert or click on the “Edit Site Tracing…” link in the “Actions” section of the IIS Manager.

This will popup the window shown below.


You are going to want to check the checkbox labeled “Enable” and you can also override the default settings for where the trace file will be written and how many it will keep.

Next you need to create some rules. I’m just going to show you a simple rule I created for an unexplained HTTP 500 error I was getting. Of course you can configure your rules any way you’d like. First, click on the “Add…” link in the “Actions” section. This will bring up the window below.


I’ve selected “All content (*)” because I’m more concerned with the status code which I can filter on in the next step. But you have the option here for selecting what you want to trace.


Here is where I tell the tracer that I only care about HTTP 500 status codes. So I check the “Status code(s)” checkbox and enter “500” into the textbox (like I said I only care about a 500 error I was getting). But you could enter a range of status codes or a bunch of codes comma separated. Or you can just check the “Event severity” checkbox and select what level of event you want to trace: error, critical error, or warning. A cool feature if the middle option “Time taken (in seconds)”. I you are having a specific resource take to long to be served to the client, you could check this box and set a time threshold for request that take too long. It says that this is in seconds so you might need to use decimal values if something is less than a second. I don’t know because I haven’t tested this feature. When you’re happy with your conditions, click on the “Next” button.


The last step allows you to select the trace providers, set how verbose each provider will be, and select which areas you want that provider to capture. I’ve just left it with the defaults and then clicked “Finish”. You should now be returned to the IIS Manager and you should see your rule within the window. You can add additional rules if need be.

If you only want to trace on a specific application within the site, you can click on that application in the left hand pane and then double-click on its “Failed Request Tracing Rules” icon.


iis-tracing-alertAfter clicking on that if you see the message at the right in your “Alerts” section of the IIS Manager, then you’ve missed the step above when you need to enable tracing for the whole website (I missed this alert and was wondering why traces were not being generated). Otherwise, the setup of the rules for the application is the same as creating rules on the site level. Just follow the steps from above and you should be good to go. Now go recreate your error and then check the trace files to see what new information regarding the error has been recorded. XML files get created and they have a lot of information within them. I just searched within the file for the word “error” and it got me within a few clicks right to the culprit.

That’s it, happy troubleshooting.