ASP.NET Windows 500 Error

Enable detailed error messages on IIS, troubleshoot web.config issues, and debug ASP.NET applications on Windows servers.

Understanding IIS 500 Errors

A 500 Internal Server Error on a Windows IIS server running ASP.NET means something failed in the application or its configuration, but IIS is hiding the real error behind a generic error page. The first step is always to enable detailed errors so you can see what actually went wrong.

Enable Detailed Errors in web.config

Add the following line of code under the <system.webServer> section of your web.config file:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <httpErrors errorMode="Detailed" />
  </system.webServer>
</configuration>

This tells IIS to display the actual error message instead of the generic 500 page. You can also disable custom errors in the ASP.NET section:

<configuration>
  <system.web>
    <customErrors mode="Off" />
    <compilation debug="true" />
  </system.web>
  <system.webServer>
    <httpErrors errorMode="Detailed" />
  </system.webServer>
</configuration>
Security Warning

Never leave detailed errors enabled on a production site. Once you've identified and fixed the issue, revert to errorMode="DetailedLocalOnly" so detailed errors are only visible when browsing from the server itself.

Rebuilding web.config

If adding the detailed error directive doesn't reveal the actual error, the issue likely stems from improper web.config coding. In this case, the file itself may need to be rebuilt:

Backup the Current File

Rename web.config to web.config.bak to preserve the original.

Create a Minimal web.config

Start with a bare-bones config and add sections back one at a time:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <httpErrors errorMode="Detailed" />
  </system.webServer>
</configuration>

Add Sections Incrementally

Copy sections from your backup one at a time, testing the site after each addition to pinpoint which section contains the error.

Common ASP.NET Configuration Mistakes

  • Mismatched .NET version — the application pool is set to .NET 2.0 but the app requires 4.x
  • Missing modules — required IIS modules like URL Rewrite aren't installed
  • Permission issues — the application pool identity doesn't have read access to the site directory
  • Invalid XML — malformed tags, missing closing brackets, or encoding issues in web.config
  • Duplicate configuration sections — the same section defined twice causes a parser error
  • Locked configuration — trying to override settings that are locked at a higher level in IIS

Application Pool Issues

The Application Pool is the worker process that runs your ASP.NET application. Common issues:

  • Stopped pool — check if the app pool has crashed and stopped. Restart it in IIS Manager.
  • Wrong .NET CLR version — ensure the pool matches your app's framework (v2.0 vs v4.0 vs "No Managed Code").
  • 32-bit vs 64-bit — enable 32-bit applications in the app pool advanced settings if your app requires it.
  • Identity permissions — the pool's identity (ApplicationPoolIdentity, NetworkService, etc.) needs appropriate file system access.

Windows Event Viewer

For errors that don't show up in the browser or IIS logs, check the Windows Event Viewer:

  1. Open Event Viewer (eventvwr.msc)
  2. Navigate to Windows Logs → Application
  3. Filter by Source: ASP.NET or IIS-W3SVC-WP
  4. Look for Error and Warning entries around the time of the 500 error
Plesk Users

If you're on Plesk for Windows, you can also check error logs under Domains → yourdomain.com → Logs. Plesk provides access to both IIS and application-level logs.