IIS 500 errors leave clues in the log

Yesterday I was playing around with the validateIntegratedModeConfiguration="true" setting on IIS 7.5. To my surprise I got an empty response back, with no indication of what went wrong.

Looking at the response with Fiddler yields:

HTTP/1.1 500 Internal Server Error
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 05 Mar 2012 15:59:52 GMT
Content-Length: 0

There's not much to work with here! I checked the event log, there was nothing there. So I started looking around for an error log of some sort (I used to play with Apache back in the days) turns out there's no such thing in IIS.

Some googling led me to an in-depth article: Troubleshoot IIS7 errors like a pro. I enabled detailed error messages for my website, still no luck.

Finally, I figured out that the easiest way to get an indication of what's going on is to check the IIS log. In the default setup, IIS keeps the logs for each website in: C:\inetpub\logs\LogFiles. Here's a log entry from my logfile (shortened for readability):

2012-03-05 15:59:52 ::1 GET /Somesite/ - 443 - ::1 Mozilla/5.0 500 22 50 1

Notice the "500 22" in the log? That's the 500 error, along with its substatus. The substatus is the key here, as you can look that up in Microsoft's document on The HTTP status codes in IIS 7.0 and in IIS 7.5. Voila, my error was actually:

500.22 - An ASP.NET httpModules configuration does not apply in Managed Pipeline mode.

I can work with that.

Of course, you could also enable failed request tracing in IIS if you're a pro, here's a walkthrough by the IIS team: Troubleshooting Failed Requests Using Tracing in IIS 7. I tried it, and it also revealed the substatus of the response. Still, checking the IIS log was a much faster way of getting an indication of what the problem was, and sometimes that's all you need. So check your logs first, then start troubleshooting like a pro!