Why Does IIS Return a 500.19 Error and How to Fix It (2026 Guide)

You deployed your application to IIS, opened the browser, and instead of your web page you see HTTP Error 500.19 – Internal Server Error. If that sounds familiar, you are in the right place. Our team has hit this error dozens of times across ASP.NET, ASP.NET Core, and plain static sites, and we know exactly how frustrating that vague error page can be.

The IIS 500.19 error is one of the most common deployment failures on Windows Server and local development machines alike. The good news is that it is also one of the most fixable IIS errors you will encounter. Unlike a generic 500 error, the 500.19 page always includes an HRESULT code that points you to the exact root cause.

In this guide, we will break down why IIS returns a 500.19 error and walk through every major HRESULT code with specific, tested fixes. Whether you are deploying classic ASP.NET Framework apps or modern ASP.NET Core applications targeting .NET 8, you will find the solution here.

What Is the IIS 500.19 Error?

HTTP Error 500.19 is an IIS-specific Internal Server Error that fires when the web server cannot read or process the configuration data needed to serve a request. That configuration data lives primarily in your web.config file and the server-level ApplicationHost.config file.

Think of it this way: IIS acts like a restaurant manager checking a recipe book (your config files) before serving a customer. If the recipe book is missing pages, written in a language the manager cannot read, or locked in a cabinet, the manager refuses to serve the dish and returns error 500.19.

What makes the 500.19 error different from a generic 500.0 error is the HRESULT code. This hexadecimal code appears right on the error page and tells you the precise reason IIS failed. Common codes include 0x8007000d (malformed XML), 0x80070021 (locked section), and 0x80070005 (access denied).

The error page also shows a Config Source section, which should point to the specific line in your configuration file causing the problem. When Config Source shows -1 and 0, it means IIS could not even begin reading the file, which usually points to a missing module or a completely unreadable config.

Quick Diagnostic: Identify Your Error Code

Before you try any fix, find the HRESULT code on your error page. It appears in a line that looks like HRESULT: 0x8007000d or under the “Error Code” heading. Once you have that code, match it to the reference below.

HRESULT Code Quick Reference:

• 0x8007000d – The data is invalid (malformed XML or unrecognized config element)
• 0x80070021 – This configuration section cannot be used at this path (locked section)
• 0x80070005 – Access is denied (insufficient permissions on config or content)
• 0x800700b7 – Cannot add duplicate collection entry (duplicate config element)
• 0x8007007e – The specified module could not be found (missing DLL or module)
• 0x800700c1 – Not a valid Win32 application (bitness mismatch between app pool and DLL)
• 0x80070003 – The system cannot find the path specified (missing config file or virtual directory)
• 0x8007010b – The directory name is invalid (inaccessible content directory)
• 0x8007052e – Logon failure (remote share authentication credentials invalid)

Diagnostic flow: If your code is 0x8007000d or 0x8007007e, start with config validation and module installation. If it is 0x80070005 or 0x80070003, check file and folder permissions. If it is 0x80070021, the configuration section is locked at the server level. If it is 0x800700c1, your application pool bitness does not match your binary.

Common Causes of HTTP Error 500.19

From our experience and from analyzing thousands of Stack Overflow votes and forum threads, five root causes account for nearly all 500.19 errors.

1. Missing ASP.NET features or modules. IIS does not include ASP.NET support by default on a fresh Windows installation. If ASP.NET is not enabled in Windows Features, or if the ASP.NET Core Hosting Bundle is not installed, IIS cannot process the handlers and modules your web.config references. This is the single most common cause for new deployments.

2. Malformed web.config XML. A single unclosed tag, a typo in an element name, or a misplaced configSections element will make the entire file unparseable. IIS stops reading and returns 0x8007000d.

3. Insufficient permissions. The application pool identity (typically IIS_IUSRS or a specific app pool account) must have read access to the website directory and the web.config file. After publishing from Visual Studio, manually set permissions can get wiped out.

4. Locked configuration sections. IIS uses a configuration hierarchy where server-level settings can lock specific sections from being overridden in web.config. If your config tries to change a locked setting, you get 0x80070021.

5. Post-update breakage. Windows updates, WSUS uninstalls, and Visual Studio version upgrades can silently change IIS configuration or remove modules. Many administrators report 500.19 errors appearing after a routine patch cycle with no code changes.

How to Fix IIS Error 500.19 (by HRESULT Code)

Each HRESULT code requires a different fix. We have tested every solution below in production environments on Windows Server 2019, Windows Server 2022, Windows 10, and Windows 11.

Error Code 0x8007000d – Malformed or Invalid Configuration

This is the most frequently encountered 500.19 error code. It means IIS found invalid data in a configuration file. The cause is either malformed XML in web.config or an XML element that IIS does not recognize because a required module is not installed.

Step 1: Open your web.config file in a text editor and check for XML syntax errors. Look for unclosed tags, missing closing brackets, or invalid characters. Visual Studio will highlight XML errors with red squiggly lines if you open the file there.

Step 2: Verify that configSections is the first child element inside <configuration> if it exists. Placing any custom XML before the closing </configSections> tag is a common mistake that triggers this error.

Step 3: If your web.config references the URL Rewrite module (look for <rewrite> elements) and you get 0x8007000d, install the URL Rewrite module from the Microsoft Download Center. This is the top-voted fix on Stack Overflow with over 490 upvotes.

Step 4: For ASP.NET Core applications, this error almost always means the .NET Core Hosting Bundle is missing. Jump to the ASP.NET Core section below for installation steps.

Error Code 0x80070021 – Locked Configuration Section

This code means your web.config tries to override a configuration section that is locked at the server level in ApplicationHost.config. The error message will tell you which section is locked.

Step 1: Open IIS Manager and select the server node in the left panel (the top-level entry, not your site).

Step 2: Double-click Feature Delegation in the Management section. This screen shows every configurable section and whether it is locked (Read Only) or unlocked (Read/Write).

Step 3: Find the section mentioned in your error message and change its delegation from Read Only to Read/Write. Right-click the section and select the appropriate unlock option.

Alternative (command line): Open an elevated command prompt and run the following command to unlock a specific section. For example, to unlock the handlers section:

appcmd unlock config /section:handlers

To unlock all sections at once, edit ApplicationHost.config directly (located at %windir%\System32\inetsrv\config\applicationHost.config) and change overrideModeDefault="Deny" to overrideModeDefault="Allow" for the relevant section.

Error Code 0x80070005 – Insufficient Permissions

Access denied. The application pool identity does not have permission to read the web.config file or the website content directory. This is the second most common 500.19 error.

Step 1: Right-click your website folder in Windows Explorer and select Properties, then go to the Security tab.

Step 2: Click Edit and add the IIS_IUSRS group. Grant it Read and Execute permissions. If your application writes to the folder (logs, uploads), add Write as well.

Step 3: If your application pool uses a specific identity (not ApplicationPoolIdentity), add that specific account instead. In IIS Manager, you can check the pool identity under Application Pools, then Advanced Settings, then Identity.

Step 4: Apply the permissions recursively to all subfolders and files. Click Advanced in the Security dialog, enable Replace all child object permission entries, and click Apply.

One community-tested fix that comes up repeatedly: after changing a domain admin password, IIS Basic Settings credentials can become stale. Open IIS Manager, right-click your site, select Basic Settings, click Connect as, and re-enter the updated credentials.

Error Code 0x800700b7 – Duplicate Configuration Entry

Cannot add duplicate collection entry. Your web.config tries to add a handler, module, or MIME type that is already defined at a parent level in the configuration hierarchy.

Step 1: Read the error message carefully. It will name the specific element that is duplicated, such as a handler name or MIME type extension.

Step 2: Search your web.config for the duplicate entry. A common case is a <staticContent> section that adds a <mimeMap> for an extension like .less or .woff that a parent config already defines.

Step 3: Either remove the duplicate entry from your web.config, or wrap it in a <remove> element before adding it. For example:

<staticContent><remove fileExtension=".less" /><mimeMap fileExtension=".less" mimeType="text/css" /></staticContent>

Step 4: For duplicate handler entries, use the <clear /> element at the top of your <handlers> section to remove all inherited handlers before adding your own.

Error Code 0x8007007e – Invalid Module or DLL Reference

The specified module could not be found. IIS is trying to load a native DLL referenced in ApplicationHost.config or web.config, but the file does not exist on disk.

Step 1: Check the error details for the module name or DLL path. The error usually includes the file path it tried to load.

Step 2: Navigate to the referenced path and verify the DLL exists. A common scenario is a module registered for a 32-bit DLL that was never deployed to the 64-bit server.

Step 3: If the module is a .NET Framework assembly, run aspnet_regiis -i from the appropriate Framework folder (for .NET Framework 4.x, use %windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis -i). This re-registers ASP.NET with IIS.

Step 4: For ASP.NET Core, this error typically means the AspNetCoreModuleV2 is registered in ApplicationHost.config but the actual module DLL from the Hosting Bundle is missing. Reinstall the .NET Core Hosting Bundle.

Error Code 0x800700c1 – Bitness Mismatch

Not a valid Win32 application. Your application pool is configured for one architecture (32-bit or 64-bit) but is trying to load a DLL compiled for the other architecture.

Step 1: Open IIS Manager and go to Application Pools. Select the pool your site uses.

Step 2: Click Advanced Settings and find Enable 32-Bit Applications.

Step 3: If your application or any referenced DLL is 32-bit, set this to True. If everything is compiled for 64-bit, set it to False.

Step 4: Recycle the application pool after changing this setting. Right-click the pool and select Recycle.

This error commonly appears when a legacy 32-bit component (like an old COM object or native DLL) is deployed to a 64-bit application pool. Identify which DLL is the culprit using the error details, then set the bitness accordingly.

Error Code 0x80070003 – Cannot Read Configuration File

The system cannot find the path specified. IIS cannot locate the web.config file or the physical path configured for your site or virtual directory.

Step 1: Open IIS Manager, right-click your site, and select Basic Settings. Check the Physical path field.

Step 2: Verify that the physical path exists on disk and contains a valid web.config file. If you published from Visual Studio, confirm the publish target folder matches the IIS physical path.

Step 3: Click Test Settings in the Basic Settings dialog. This will tell you if the physical path is accessible and if authentication is working.

Step 4: If the path uses a network share (UNC path), verify the share is accessible from the server and that the connect-as credentials are valid. UNC pass-through authentication failures are a common source of this error in load-balanced environments.

Fixing 500.19 Error for ASP.NET Core Applications

ASP.NET Core has a specific set of 500.19 causes that trip up even experienced developers. The most common mistake is assuming that installing the .NET SDK is enough for IIS hosting. It is not.

The .NET SDK lets you build and run applications locally using Kestrel. It does not install the IIS integration module. For IIS to host an ASP.NET Core app, you need the .NET Core Hosting Bundle (also called “Windows Server Hosting”).

What the Hosting Bundle installs: The bundle installs the ASP.NET Core Module V2 (ANCM), which is the native IIS module that proxies requests to your Kestrel backend. Without it, IIS sees the <aspNetCore> handler in your web.config, does not recognize it, and returns 500.19 with 0x8007000d.

Installation steps:

Step 1: Download the .NET Hosting Bundle from the official Microsoft .NET download page. Match the version to your application (for example, .NET 8 apps need the .NET 8 Hosting Bundle).

Step 2: Make sure IIS is installed before you install the Hosting Bundle. If you install the bundle first and then enable IIS, the ANCM module will not register in ApplicationHost.config. If you already made this mistake, repair or reinstall the Hosting Bundle after enabling IIS.

Step 3: Run the Hosting Bundle installer as Administrator. After installation, open IIS Manager, select your server node, and double-click Modules. You should see AspNetCoreModuleV2 in the list.

Step 4: Set your application pool to No Managed Code for the .NET CLR version. ASP.NET Core runs its own runtime, so the pool should not use the .NET Framework CLR.

Step 5: Choose your hosting model in web.config. In-process hosting (the default) runs your app inside the IIS worker process for better performance. Out-of-process hosting runs Kestrel behind IIS as a reverse proxy.

Rick Strahl’s well-known blog post on this topic highlights an important detail: the 500.19 error from a missing Hosting Bundle will not show up in Event Viewer. This is because IIS fails before the ANCM module ever loads, so no module-level event is logged. If Event Viewer shows nothing for your 500.19 error on an ASP.NET Core app, the Hosting Bundle is the prime suspect.

How to Fix IIS Error 500.19 for Classic ASP.NET Applications

Classic ASP.NET Framework applications (ASP.NET 4.8 and earlier) have their own set of 500.19 triggers. The solutions are different from ASP.NET Core, so we cover them separately here.

Enable ASP.NET in Windows Features. On Windows 10 and Windows 11, open Turn Windows features on or off, navigate to Internet Information Services, then World Wide Web Services, then Application Development Features, and check both ASP.NET 3.5 and ASP.NET 4.8 (or 4.6, depending on your Windows version). This single fix has over 140 upvotes on Stack Overflow.

Also enable .NET Extensibility. In the same Application Development Features list, check .NET Extensibility 3.5 and .NET Extensibility 4.8. These provide the handler framework that ASP.NET relies on.

Enable Http Activation. Under .NET Framework 4.8 Advanced Services, expand WCF Services and check HTTP Activation. Multiple community reports confirm this resolves 500.19 for applications that use WCF endpoints.

Set the correct application pool .NET version. If your app pool is set to No Managed Code but your application targets .NET Framework 4.x, change the pool’s .NET CLR version to .NET CLR Version v4.0.30319. A mismatch here will cause IIS to fail when it tries to load ASP.NET modules.

Note on aspnet_regiis: Older guides recommend running aspnet_regiis -i to register ASP.NET with IIS. On modern Windows versions (Windows 10 and later), this command is deprecated. Use the Windows Features dialog instead. The elmah.io blog post on this topic specifically flags this as an outdated recommendation.

Understanding the web.config and ApplicationHost.config Files

To understand why 500.19 errors happen, you need to understand the IIS configuration hierarchy. IIS reads configuration from multiple levels, and conflicts between them are a primary source of errors.

Level 1: ApplicationHost.config (server-level). Located at %windir%\System32\inetsrv\config\applicationHost.config, this is the master configuration file for IIS. It defines which modules are loaded, which sections can be overridden, and default settings for all sites on the server. Only administrators can edit this file.

Level 2: Site-level web.config. Placed in the root of your website, this file overrides server-level settings for your specific site. You can only change settings that the server-level config has unlocked (see the 0x80070021 fix above).

Level 3: Application-level web.config. If you have virtual applications under your site, each can have its own web.config that further overrides settings. Settings cascade downward, with the closest config file taking precedence.

Override mode and Feature Delegation. Each configuration section in ApplicationHost.config has an overrideModeDefault attribute. When set to Deny, no web.config can change that section. When set to Allow, site-level configs can override it. The Feature Delegation UI in IIS Manager provides a visual interface for managing these locks without editing XML directly.

Understanding this hierarchy helps you diagnose why a setting that worked in development (where you control the full stack) fails in production (where a server admin may have locked certain sections). When you see 0x80070021, always check Feature Delegation first.

How to Diagnose 500.19 Errors Using IIS Tools

When the error page alone does not give you enough information, IIS provides several diagnostic tools that can reveal hidden details about what went wrong.

Failed Request Tracing (FREB). This is the most powerful diagnostic tool for IIS errors. It produces a detailed XML trace of every step IIS took while processing your request, including the exact point where it failed.

To enable it, open IIS Manager, select your site, and double-click Failed Request Tracing Rules. Create a new rule, set the content to trace as ASP.NET or All Content, and set the status code to 500. Make your request again, then navigate to %windir%\System32\inetsrv\failedreqlogfiles\ to find the trace file. Open the XML in a browser for a human-readable view.

Event Viewer. Check the Windows Event Viewer for additional error details. Go to Windows Logs then Application, and filter by the IIS or ASP.NET source. Note that for ASP.NET Core 500.19 errors caused by a missing Hosting Bundle, Event Viewer will show nothing useful because the ANCM module never loaded. For permissions and configuration errors, though, Event Viewer often contains the exact file path or account that caused the failure.

Process Monitor (ProcMon). Sysinternals Process Monitor captures every file system and registry access in real time. Run ProcMon, set a filter for your IIS worker process name (typically w3wp.exe), reproduce the error, and look for ACCESS DENIED results. This is the fastest way to identify which file or registry key the application pool identity cannot read.

AppCmd. The appcmd.exe tool at %windir%\System32\inetsrv\appcmd.exe lets you inspect and modify IIS configuration from the command line. Use appcmd list config "YourSiteName" to dump the effective configuration for a site, including inherited values. Use appcmd list modules to verify that required modules like AspNetCoreModuleV2 are loaded.

IIS 500.19 vs Other IIS Errors (500.0, 500.21, 500.22)

The 500.19 error is part of a family of IIS sub-status codes that all start with 500. Knowing the differences helps you apply the right fix without wasting time on the wrong one.

500.0 – Generic Internal Server Error. A module or handler threw an unhandled exception during request processing. The application code itself failed, not the configuration. Check your application logs and Event Viewer for the exception details.

500.19 – Configuration Data is Invalid. The error this article covers. IIS could not read or process a configuration file. The problem is in web.config, ApplicationHost.config, permissions, or missing modules, not in your application code.

500.21 – Server Error in Application, Handler does not exist. A specific handler referenced in your config is not registered. Similar to 500.19 but narrower in scope. Usually fixed by installing the missing module that provides the handler.

500.22 – Extension not allowed. An ASP.NET HTTP module or handler is defined in web.config but the application pool is in Integrated mode while the config entry is written for Classic mode (or vice versa). Migrate the config entries using appcmd migrate config.

If you see 500.19 specifically, stay on this page. If you see 500.0, your application code is the problem. If you see 500.21 or 500.22, focus on handler registration and pipeline mode compatibility.

Preventing HTTP 500.19 Errors

The best fix is preventing the error from happening in the first place. Based on our deployment experience and community pain points, here is a pre-deployment checklist that catches the vast majority of 500.19 causes before they reach production.

Pre-Deployment Checklist:

• Verify IIS is installed with ASP.NET features enabled (Windows Features dialog)
• Install the .NET Core Hosting Bundle AFTER enabling IIS (for ASP.NET Core apps)
• Install the URL Rewrite module if your web.config uses <rewrite> rules
• Confirm web.config is valid XML (open it in Visual Studio and check for errors)
• Verify configSections is the first child element of <configuration>
• Check for duplicate MIME type or handler entries that might conflict with server-level config
• Set the application pool .NET CLR version to match your application (No Managed Code for ASP.NET Core)
• Verify the application pool bitness matches your native DLLs (32-bit vs 64-bit)
• Grant IIS_IUSRS read permissions on the website folder and web.config
• Test the physical path connection in IIS Manager (Basic Settings, Test Settings)
• Unlock any configuration sections your app needs via Feature Delegation
• Run appcmd list modules to verify all required modules are loaded

Common mistakes to avoid: Do not install the Hosting Bundle before enabling IIS, or the ANCM module will not register. Do not use Visual Studio publish profiles that delete all existing files, as this can strip manually configured permissions. Do not assume that because your app runs locally on IIS Express it will run on full IIS, because IIS Express auto-registers modules that full IIS does not.

Windows update prevention: After major Windows updates, verify that ASP.NET features are still enabled. Some updates can reset Windows Features settings. Also verify that the AspNetCoreModuleV2 is still present in IIS Manager Modules after a .NET runtime update. If it disappears, reinstall the Hosting Bundle.

Configuration backup: Before making any changes to ApplicationHost.config, back it up using appcmd add backup "PreChangeBackup". You can restore it with appcmd restore backup "PreChangeBackup" if anything breaks. This is especially important before applying Windows updates to production servers.

FAQ’s

Conclusion

The IIS 500.19 error looks intimidating, but it is one of the most fixable issues in web hosting. The key is reading the HRESULT code on the error page and matching it to the correct fix. Whether you are dealing with malformed XML (0x8007000d), locked sections (0x80070021), permission denials (0x80070005), or a missing ASP.NET Core Hosting Bundle, the solutions are systematic and well-documented.

By understanding why IIS returns a 500.19 error, you can move from guessing at random fixes to diagnosing the root cause in minutes. Bookmark the HRESULT reference table at the top of this article, run through the pre-deployment checklist before your next release, and use IIS diagnostic tools like Failed Request Tracing and Process Monitor when the error page alone is not enough.

Your next step: find your HRESULT code, jump to the matching fix section above, and follow the steps. Most 500.19 errors resolve in under 15 minutes once you know the exact cause.