How to Fix ASP.NET Core 500.19 Configuration Error on IIS

An ASP.NET Core site that worked yesterday returns 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”. Nothing in your code has run yet. IIS stopped before the app started, because the web.config file it reads is not valid. The fix is to find the line IIS rejects, correct it, and confirm the site starts. This guide shows how to read the error, the causes that appear most often on Windows hosting, and how to test each fix without guessing.

On SiteHarbour’s Windows hosting, IIS and Plesk run the site, so the configuration file is the part you control. The steps below work on any Plesk Windows server.

How 500.19 differs from the other IIS errors#

A 500.19 is a configuration error, detected before the app runs. It is different from a 502.5, where the app started and then failed, and from a 500 error with a stack trace, where the app ran and threw an exception on a request. The error code’s sub-code, shown in the page or in the log, narrows it further. A 500.19 with the sub-code 0x80070021 usually means the file is locked by another process, which is a different fix from a syntax error.

Step 1: Read the reason in the error log#

The browser page is generic, but IIS writes the exact problem to the Windows event log and to the request log. Open Event Viewer on the server, or ask your host for the entries, and look at the System log for events from the source IIS-Configuration or IIS. The event names the file, the line and the attribute that failed. Note the file name, because it may be a site-level web.config, or one in a subfolder.

Expected: a message such as “Configuration file has an invalid element” or “The attribute is invalid”, with a line number. That line is the one to fix.

Step 2: Check the file for the usual faults#

Most 500.19 errors come from one of four changes to web.config:

• A malformed XML element. A missing closing tag, a stray character, or an ampersand that is not written as &. Open the file in a code editor that highlights XML errors, which shows the exact line.
• A section IIS does not know. A rewrite or handler element used before its module is installed. The error names the unknown element.
• An attribute value that IIS rejects. A typo in a value such as redirectType or stopProcessing.
• A duplicate section. Two rewrite or system.webServer blocks in the same file, often after two plugins or two guides each added one.

Keep a copy of the file before you change it. A broken web.config stops the whole site, so the copy is your way back.

Step 3: Validate the file before you upload it#

An XML check on your own computer catches most faults before they reach the server. In PowerShell, parse the file and read the error if there is one:

[xml](Get-Content .\web.config -Raw)

Expected: no output when the file is well formed. A red error names the line and the character that is wrong. This check catches broken XML only. It does not check IIS-specific attribute values, so the event log is still the authority for those.

Step 4: Check the ASP.NET Core section#

For an ASP.NET Core app, the aspNetCore element must sit inside system.webServer, and its attributes must match the published output. A common mistake is a processPath that points at dotnet while the arguments value names a DLL that is not in the folder. A wrong DLL name does not cause a 500.19. IIS accepts the file, starts the app, and the app then fails with a 502.5. Check that the DLL name matches the file in the folder exactly, including capital letters.

<system.webServer>
  <handlers>
    <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
  </handlers>
  <aspNetCore processPath="dotnet" arguments=".\MyApp.dll" stdoutLogEnabled="false" />
</system.webServer>

Replace MyApp.dll with your DLL name. The handler line must name AspNetCoreModuleV2, which is the module IIS uses for ASP.NET Core on the plans.

Step 5: Remove a duplicate or unknown block#

If a plugin or a guide added a second rewrite block, merge the rules into one. If an element is unknown, the module that provides it is not installed. Remove the element, or ask your host to install the module, and retest. Do not leave an unknown element in place as a workaround, because the site will fail again on the next change.

Step 6: Test and confirm#

Upload the corrected file, load the site, and check the status code. Then check the event log again, because a warning can remain after the error page clears. Load one page that uses the database, since a connection string problem can appear only then, as described in how to connect ASP.NET Core to MS SQL Server.

Common mistakes#

• Editing the file in a word processor. It adds formatting and breaks the XML. Use a plain text or code editor.
• Trusting the browser page. The event log names the exact line.
• Changing several attributes at once. Change one, test, then change the next.
• Removing the file. A missing web.config changes the behaviour, and the site may show the default page instead.
• Uploading the source file. Upload the copy from the publish output, so the DLL name matches.

Frequently asked questions#

Why did it work before the last deploy?#

The deploy changed the file, or it copied a file from another project. Compare the new file with the previous one, or roll back the deploy.

What does the sub-code mean?#

It narrows the cause. For example, 0x80070021 usually means another process holds the file, which a restart of the site or the server resolves.

Can a 500.19 come from the app itself?#

No. The app has not started when the error occurs. An error inside the app shows as a 500 with a stack trace or as a 502.5.

Does restarting the site help?#

Only when the file is locked. A syntax error stays until the file is corrected.

A 500.19 means IIS rejected the configuration before the app ran. Read the event log for the exact line, check the XML and the ASP.NET Core section, merge any duplicate blocks, and change one thing at a time. Keep a copy of the working file so you can go back. For the errors that appear after the app starts, read how to fix ASP.NET Core 502.5 process failure on Windows hosting.