Fix '500 Internal Server Error' in IIS on Windows Server

30-Second Fix: Check the Application Pool

The culprit here is almost always the application pool. First, open IIS Manager. Click Application Pools on the left pane. Find the pool your site uses—look at the site's Basic Settings if you're not sure. Right-click it and hit Stop, then Start again. If the error disappears, you've got a pool that was crashed or hung.

Check the pool's .NET CLR version too. If your site runs .NET 4.x, the pool must be set to v4.0. Mixing versions causes a 500 every time. Also, make sure the Managed Pipeline Mode matches your app—Classic for older apps, Integrated for modern ones.

If the pool crashes again after restarting, look at the Event Viewer. Open Windows Logs > Application and filter for WAS or W3WP errors. You'll see something like "A process serving application pool 'X' terminated unexpectedly." That points straight to a crash—likely a bad module or missing file.

5-Minute Fix: Verify Permissions

Permissions screw up more 500 errors than you'd think. The app pool runs under a specific identity—usually ApplicationPoolIdentity or NetworkService. That identity needs Read & Execute access to your site's root folder and any subfolders with files.

Right-click your site folder in File Explorer, go to Security, and check the list. If you don't see the identity, click Edit > Add. Type IIS AppPool\”DefaultAppPool” (replace the name with your actual pool name) and grant Read & Execute, List folder contents, Read. Apply and test the site.

For older apps with Windows Authentication, the folder also needs Authenticated Users or Everyone (temporarily) to rule out auth failures. Don't leave Everyone in there after testing—that's asking for trouble.

15+ Minute Fix: Dig into Modules and Dependencies

If the pool is running and permissions are right, you've got a deeper issue. I've seen this happen after a URL Rewrite module update or a missing Web Deploy component. Open IIS Manager, select your site, and double-click Modules. Look for any modules with a red error icon—those are failing. Remove them temporarily and reload the page.

Another common cause: missing VC++ redistributables. If your app uses a compiled DLL (like ASP.NET Web Forms or a custom module), make sure the correct Visual C++ Redistributable is installed. Go to Programs and Features and check for Microsoft Visual C++ 2015-2022 Redistributable (x86 and x64). Missing one of these? Download and install from Microsoft's site.

Failed Request Tracing is your best friend for this step. Enable it in IIS by clicking your server node, then Failed Request Tracing Rules. Add a rule for statusCode 500 and set the output to %SystemDrive%\inetpub\logs\FailedReqLogFiles. Hit the site again to trigger the error, then open the generated XML file in Internet Explorer (it renders better there). Look for MODULE_SET_RESPONSE_ERROR_STATUS or GENERAL_READ_ENTITY_END—those lines usually name the failing module.

If you still get no clear answer, try a clean install of IIS. Uninstall the Web Server (IIS) role from Server Manager, reboot, then reinstall. It sucks, but it wipes out any corrupted configs. Before you do that, backup C:\Windows\System32\inetsrv\config\applicationHost.config just in case.

Note: I've seen a bad web.config cause 500 errors too. Temporarily rename the file to web.config.bak and test. If the error goes away, you've got a malformed config—check for duplicate keys or invalid XML.

One last thing: if your app uses ASP.NET MVC, make sure the system.webServer section in web.config has the right modules and handlers entries. Missing ExtensionlessUrlHandler-ISAPI-4.0_64bit is a classic problem. You can fix it by running %windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -i from an admin command prompt.

That covers about 95% of the 500 errors I've dealt with. Start with the pool, move to permissions, then fall back to tracing and dependencies. You'll nail it.