HTTP 500.19 and 500.21: IIS refuses to read your web.config at all

Fix it now

IIS could not build the configuration for that URL, so it refused the request before any code ran. Microsoft publishes nine different HRESULTs under 500.19, and the one on the error page tells you which of them you have. Read that hex value first; everything else follows from it.

%windir%\system32\inetsrv\appcmd list config "Default Web Site/" /section:?
%windir%\system32\inetsrv\appcmd search config "Default Web Site/"
%windir%\system32\inetsrv\appcmd list config "Default Web Site/"

1. Read the HRESULT off the 500.19 page. 0x80070021 is a section locked at a higher level, 0x800700b7 a duplicate entry, 0x8007007e a reference to a module or DLL that is not there, 0x800700c1 a module whose bitness does not match the pool, and 0x8007010b a content directory that cannot be accessed.
2. For 0x80070021, unlock the section the error names: %windir%\system32\inetsrv\appcmd unlock config /section:<sectionName>. That is machine-wide, so consider deleting the entry from web.config instead.
3. For 0x8007010b, check the physical path on the site or application in IIS Manager under Basic Settings: that it exists, is spelled correctly, sits on a valid file system, and carries file-level permissions the site can use.
4. For an access-denied HRESULT, grant Read to the IIS_IUSRS group on the folder through Properties, Security, Edit, Add.
5. For 500.21, install the role service or module that provides the handler the mapping names, then run iisreset.

If you would rather not unlock a section for the whole machine, the documented alternative is a <location path="." overrideMode="Allow"> element in applicationHost.config scoped to the path that needs it.

If the page loads, you are done. If it does not, the next section explains what IIS is doing before it gives up and which layer of the merge failed.

Why it happens

Every request is served against a merged configuration. IIS starts with applicationHost.config at machine level, applies each web.config on the path down to the application, then the one in the requested folder. That merge has to succeed completely before a line of your code is reached. 500.19 is published as “Configuration data is invalid”, and it means the merge stopped.

The useful part is not the 500.19 itself but the HRESULT printed with it. Microsoft publishes nine of them and they point at genuinely different faults: malformed or unrecognised XML, a section locked at a higher level, a UNC or permission problem reaching the file, a duplicate entry inherited from above, a reference to a module or DLL that does not exist, a module whose bitness does not match the application pool, a content directory that cannot be accessed, an identity that cannot open web.config on a remote share, and a physical path that does not match the virtual directory. Diagnosing 500.19 without reading that value is guessing between nine answers.

500.21 is a different failure with a similar feel. It is published as “Module not recognized”: the configuration parsed correctly, and then named a handler whose module is not registered on this server. Classically that is a site mapping requests to the managed pipeline handler on a server where ASP.NET was never added as a role service. The 500.5x codes belong to the URL Rewrite module and mean a rewrite rule failed rather than the configuration as a whole.

Full reference

The nine HRESULTs, and what each one is actually telling you

Reading the configuration instead of guessing at it

All of these live in %windir%\system32\inetsrv, which is not on the path by default, so call appcmd by its full path or change into that directory first.

Locking, and the narrower way to open it

Locking is expressed in configuration rather than only through appcmd. A section is unlocked for a path by wrapping it in a <location> element with overrideMode="Allow", and locked with overrideMode="Deny", which is the default for most IIS sections. Individual attributes and elements can be pinned inside an unlocked section with lockAttributes, lockElements, lockAllAttributesExcept, lockAllElementsExcept and lockItem.

That matters on a shared server. appcmd unlock config opens the section for every application on the machine. A <location> element with a real path in it opens it for one. If you are unlocking a security-relevant section such as windowsAuthentication, use the narrower form, and question whether the site should be setting it at all.

The URL Rewrite codes

The difference between 500.52 and 500.53 is which stage the outbound rule was configured to run at, not how late the failure was. If you are looking at a 500.53, the rule has preCondition behaviour that puts it ahead of the output cache update, and that is the part to examine.

When the detail is not on the page

• Enable Failed Request Tracing for status 500 and read the trace. Microsoft names it as the way to identify an incorrect module or DLL reference when the error text does not.
• Collect a Process Monitor trace for the file access failures. It is the documented route for 0x8007010b and 0x80070003, where the path in the error looks fine and the access still fails.
• Compare the merged configuration with appcmd list config against a server where the site works. The file is not portable on its own; the server configuration it depends on has to travel with it.
• Check the IIS log for the request and confirm the sc-status and sc-substatus you think you are getting.

Every code this article covers

Confirm the fix worked

1. Request the previously failing URL and confirm it returns the page rather than an error.
2. Request it from a remote client as well as from the server console.
3. Run appcmd list config "<site>/" and confirm the merged configuration holds what you expected and nothing you did not.
4. If you unlocked a section, run appcmd search config "<site>/" /section:<name> and confirm nothing else on the box has started overriding it.
5. Check the IIS log for that request: sc-status 200 with sc-substatus 0.

Questions people ask about this