Better ASP.NET Debugging with Failed Request Tracing

I cover this topic and more great debugging topics in my course IIS Administration Fundamentals. Check it out!

Failed Request Tracing is one of the greatest hidden gems of IIS when you're getting weird errors with your ASP.NET application. Many times the problem is right in the beginning, at the request stage.

Are you:

• Getting a 500 error with messages suppressed?
• Getting a permission denied and don't know where it's being denied?
• Getting an error that doesn't show up in the logs?

Each of these are good candidates for using the failed request tracing tool. This captures data right when the server gets hit. These are activities that happen right at the front, even before they can be logged.

In your IIS Manager, select your website. In the Actions panel under Manage Web Site click "Failed Request Tracing.."

In the next screen, you'll enable it, and click OK.

Next, find the "Failed Request Tracing Rules" icon, and click it:

In the next screen, we'll add a rule. Right click in the open area and select "Add"

Select the content you'd like to trace (I usually select all):

On this screen, type in 400-999 to capture the full range of errors

Select your trace providers (I usually select all of them)

Then, make a request to your web site (either through browser, ajax, etc)

Next in your inetpub folder under logs, you'll see a new FailedReqLogFiles folder. In there will be generated folders. Select the latest one.

In here you'll see a set of xml files for each individual request.

Double click to open it up, and you'll see very detailed information. In this case it shows I have a certificate error, that is not explained on the error page or the error log, but I've found it here and can move on.

And that's it! Make sure to turn it off once you've solved your problem.

This tool is indispensable when you get those weird errors that don't show up anywhere else.

While IIS admins have probably been using this for years, it's a helpful tool for developers as well, especially ones who work on implementation as well as development.

Let me know in the comments what you think.

I cover this topic and more great debugging topics in my course IIS Administration Fundamentals at Pluralsight. Check it out!