Every developer takes certain things for granted — like ASP.NET being configured correctly with IIS. Sometimes something non-obvious prevents ASP.NET pages from being served at all, returning an HTTP 500 instead. The frustrating part is that these are often system-configuration issues developers shouldn’t need to think about. The advice below was written for IIS 5.1 on a local dev machine (the 2008-era XP Pro setup); the troubleshooting order still generalizes, and I’ve added notes for where the same problem lives on modern IIS.
The problem is most likely one of:
- IIS or ASP.NET simply not installed correctly
- Security configuration
0. The basics
First, try the classic: reboot the machine.
If that doesn’t work, turn off friendly errors in the browser (IE: Tools > Options > uncheck “Show friendly HTTP error messages”; on modern Windows, use “Detailed errors” in IIS’s error-pages settings or httpErrors existingResponse="PassThrough"). That gets you a message like “Logon failure: user not allowed to log on to this computer” instead of a bare “500 Server error”.
1. Check that IIS works
Be aware of the difference between ASP.NET and IIS: ASP.NET may be installed fine while IIS itself is broken. Some general checks:
- See if you can view
http://localhost/iishelp(old builds) or the IIS welcome page. - Try viewing a plain HTML page through IIS. That bypasses any ASP.NET issues entirely.
If neither serves, IIS itself is disabled or not listening — on modern Windows, check “Turn Windows features on or off” and the IIS manager, or run iisreset.
2. Other web servers interfering
If IIS was just installed, another web server may already own port 80 (Java developers often have Tomcat or Jetty running). Stop the other server, or move one of them to another port. On modern Windows: netstat -ano | findstr :80 and match the PID in Task Manager to find the offender.
3. Re-register ASP.NET with IIS
- Restart IIS:
iisresetat a command prompt. - Re-register ASP.NET:
aspnet_regiis.exe -i(from the framework directory, e.g.%WINDIR%\Microsoft.NET\Framework\v1.1.4322\).
On modern IIS (7+) this step became %WINDIR%\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i for classic-mode apps, or simply enabling the ASP.NET feature — integrated pipeline registers handlers from web.config instead.
If that doesn’t work: uninstall IIS and ASP.NET, rename inetpub to effectively start fresh (keeping the old files), and reinstall. This can reset broken user-account state.
4. Set ASP.NET security permissions
Make sure the ASP.NET worker-process identity has rights on inetpub: add the ASPNET user (IIS 5.1) — on IIS 6+ the identity is the application pool’s Network Service/ApplicationPoolIdentity — to the folder’s users with full control (Security tab in Properties).
5. Check the local security policy
In Admin Tools > Local Security Settings > Local Policies > Security Options: “Shutdown system immediately if unable to log security audits” must be disabled. If it’s enabled and the audit log fills up, Windows refuses new logons — which takes IIS’s worker processes down with it. (This one bit a lot of people; see the registry half below.)
6. Check the registry
In regedit, check:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFailSet it to 0 (it should not be “value not set” or nonzero). This is the same “security audit failure halts logons” behavior as step 5 — the registry key is what the policy writes.
7. Check machine.config as a last resort
As a last resort, edit machine.config — probably in a directory like C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG\machine.config. Find the <processModel> element with attribute userName="SYSTEM" and change it to "MACHINE".
Note that running the worker process as a less-privileged account is the point here — SYSTEM is the highly-privileged default on old builds, and MACHINE is the safer profile. On modern IIS this knob is the application pool identity, and you should never need SYSTEM.