Diagnosing IIS 500 Internal Server Errors

Diagnosing IIS 500 Internal Server Errors

Recently I was tasked with deploying a new version of my company’s website onto a clean Windows Server 2012 host and encountered a rather frustrating issue with the dreaded “500 Internal Server Error” page. Despite there being many articles attempting to cover this error online, none of them addressed my specific case which turned out to be a Web.config issue due to a missing IIS feature.

Unfortunately IIS isn’t very informative when it comes to configuration errors, and tends to just cry that it doesn’t understand the entire configuration instead of pointing you towards the specific cause. Firstly though I want to share how I pinpointed the “500 internal server error” as being related to the configuration:

After adding the necessary Web Server and Application Server roles to the box, I deployed our MVC web application and configured a new website in IIS, pointing to the deployed folder location. Before disabling the default website, I browsed to the localhost URL to verify that IIS was correctly installed and serving pages. I then disabled the default website so I could test our MVC application via the localhost URL, which is when I hit a brick wall in the form of the HTTP 500 issue.

First port of call was the Windows Event Viewer, but there were no logs at all relating to IIS and so no help to be found there. I then checked the IIS Logs for the MVC application web site and noticed the sub-status error code at the end of each line, shown bold red below:

2014-11-13 14:13:15 GET / – 80 – Mozilla/5.0+(Windows+NT+6.1;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/38.0.2125.111+Safari/537.36 – 500 19 13 235

According to this Microsoft KB article, the sub-status code 19 for an HTTP 500 error refers to “Configuration data is invalid.” which obviously points to some aspect of IIS configuration not being correct. Since we have already verified that IIS itself is functioning, and the only change is the switch to our MVC application, the invalid data must be located in our application’s configuration file.

On closer inspection I noticed the Web.config contained several URL rewrite entries like this:

        <rule name="RemoveTrailingSlash" stopProcessing="true">
          <match url="(.*)/$" />
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
          <action type="Redirect" redirectType="Permanent" url="{R:1}" />

Luckily¬†I remember that IIS doesn’t come with built in support for URL rewriting and requires an extension module to be installed – the URL Rewrite¬†extension – which can be found here. Once installed, I refreshed the browser and sure enough, the website loaded successfully and the problem was solved.

It’s frustrating that Microsoft doesn’t provide a better feedback mechanism for these type of errors as it should be fairly trivial to highlight the section of configuration that it doesn’t understand, or simply ignore it and flag it as an error in the logs.

Leave a Reply

Your e-mail address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.