HTTP Error 500.19 Internal Server Error (IIS Config)

Problem

You deploy a site to IIS, open it, and instead of your homepage you get a stark server-generated page: HTTP Error 500.19 - Internal Server Error, with the words “The requested page cannot be accessed because the related configuration data for the page is invalid.” Somewhere on that page is a line labeled Config Error, another labeled Config Source showing three lines of XML, and — the part everyone skips — an Error Code in hexadecimal. That hex code is the entire diagnosis. Everything else on the page is scenery.

Symptoms

• Every request to the site (or virtual directory) returns 500.19; nothing gets through, because IIS never finishes reading config.
• The error page names a Config Source file — usually a web.config in your app folder, sometimes applicationHost.config.
• An Error Code like 0x8007000d, 0x80070021, 0x80070005, or 0x800700b7 appears near the top.
• The failure often appears right after a deploy, a server migration, a module uninstall, or copying a config from another machine.
• An external HTTP check shows the server is up and returning a 5xx — so DNS, TLS, and routing are fine and the problem is entirely on the origin’s config.

What 500.19 Actually Means

IIS builds a site’s effective configuration by merging a hierarchy: the machine-wide applicationHost.config, then a web.config for every folder from the site root down to the requested path. It does this before it hands the request to your application. 500.19 is IIS saying “I could not build that merged configuration,” and it refuses to serve anything until it can.

This is why 500.19 is not a 500. A plain 500 means your code ran and threw. A 500.19 means your code never started, because the server couldn’t even assemble the settings it needed to start it. The distinction matters because it tells you where not to look: not the app, not the database, not the framework. The problem is in a file IIS reads, or in permission to read it, or in a module that gives a config section its meaning.

The hex Error Code is the sub-diagnosis, and each value points somewhere specific. Treat it as the first thing you read, not the last. The XML snippet under Config Source shows the offending lines, but the hex tells you why they offend — malformed, locked, unreadable, or duplicated are four completely different fixes that all render the same red page.

Top 3 Causes

1. Malformed XML or a section for a module that isn’t installed — 0x8007000d. Either the web.config has broken XML (an unclosed tag, a bad merge, a copy-paste that dropped a bracket), or it declares a section like <rewrite>, <applicationInitialization>, or an ARR/<proxy> block whose module was never installed on this box. The config is often perfectly valid; the server just doesn’t recognize the section because the feature is missing. The tell: the Config Source points at exactly the section for the module you forgot to install. Install URL Rewrite (or the relevant module), or remove the section.
2. A configuration section locked at a higher level — 0x80070021. The section is set to overrideModeDefault="Deny" in applicationHost.config, so a web.config that tries to define it is rejected. This is the “it worked on my machine” error: identical config, different lock state. The tell: the same config file deploys cleanly on one server and throws 500.19 on another. Fix with appcmd unlock config -section:system.webServer/<section>, or promote the setting into applicationHost.config — do not just delete the setting your app depends on.
3. The app pool identity can’t read the content or config — 0x80070005. 0x80070005 is ERROR_ACCESS_DENIED: the worker process identity (IIS AppPool\<PoolName> or ApplicationPoolIdentity) lacks read permission on the physical path or the web.config, or a virtual directory’s “Connect as…” credentials for a UNC share are wrong or expired. The tell: it tracks with where the files live and who the pool runs as, not with the config contents. Grant the app pool identity read access to the site folder, or fix the UNC credentials.

Diagnose with DechoNet

• HTTP Check confirms the server is reachable and returns a 5xx status rather than timing out or refusing the connection — that tells you the box is up and the failure is config, not a down origin, a DNS miss, or a closed port. If the external check can’t even connect, you’re chasing the wrong layer.
• SSL Check verifies the TLS handshake completes, so you can rule out a certificate or HTTPS-binding problem masquerading as a server error before you go spelunking in web.config.
• DNS Check confirms the hostname resolves to the server you’re actually editing — a surprising number of “my config fix didn’t work” cases are edits applied to the wrong box because DNS points somewhere else.

Resolution Checklist

• Read the hex Error Code first. 0x8007000d (invalid/unrecognized), 0x80070021 (locked), 0x80070005 (access denied), 0x800700b7 (duplicate entry) each have a different fix. Everything below depends on which one you have.
• For 0x8007000d, open the web.config named under Config Source and validate the XML — a lone bad character or unclosed element is enough. If the XML is clean, check whether the failing section belongs to a module (URL Rewrite, Application Request Routing, Application Initialization) that isn’t installed on this server.
• For 0x80070021, run %windir%\system32\inetsrv\appcmd unlock config -section:<section-name> for the exact section the page names, or set the override at the applicationHost.config level.
• For 0x80070005, grant the app pool identity read access to the physical path (icacls "C:\path" /grant "IIS AppPool\YourPool:(OI)(CI)R"), and re-check any UNC “Connect as” credentials.
• For 0x800700b7 (“Cannot add duplicate collection entry”), find the setting defined twice — usually the same <add> in both a parent web.config and the child — and remove one, or use <remove> before <add>.
• After the fix, confirm from outside that the site returns a real 200 (or your app’s actual response) rather than a cached error page.

When to Escalate

• If the Config Source points at applicationHost.config rather than your app’s web.config, the problem is server-wide, not app-specific — coordinate with whoever owns the IIS host before editing machine-level config, because an unlock or override change there affects every site on the server.
• If you’ve cleared the hex code’s specific cause and 500.19 persists, capture the full error page (code, Config Source, and the file path) and check the Windows Application event log; a broken or partially-installed module can leave a section registered but non-functional, which needs a repair or reinstall rather than a config edit.