IIS Web Apps Errors, 5xx, Cold Start, Deployment, and Config Fixes
Why IIS Web Apps Errors Keep Appearing
I've seen this exact situation play out on dozens of servers: you push a new deployment, flip the DNS, and within minutes your monitoring dashboard lights up red. HTTP 500.19. HTTP 404. Application pool crashes. The IIS error messages that Windows hands you are almost deliberately unhelpful, cryptic hex codes, internal file paths from Microsoft's own build servers, and event log entries that feel like they were written for a robot audience, not a human one trying to fix a live production site at 2 AM.
IIS web apps errors fall into a few broad buckets, and knowing which bucket you're in is half the battle. The most common are 5xx server-side errors, the notorious HTTP 500.0 and HTTP 500.19 codes, which almost always come down to either a misconfigured web.config, a broken application pool identity, or a missing module. Then there are cold start and warm-up problems, where your IIS application pool recycles overnight and the first user in the morning gets a 30-second delay while the runtime spins up. Deployment errors are their own category: permissions mismatches, locked DLLs, and failed COM object instantiation that worked fine on staging but immediately explodes in production.
Config errors are particularly sneaky. IIS reads your web.config before it does almost anything else, and a single malformed XML tag or a reference to a handler that isn't installed will produce a 500.19 and refuse to serve a single byte. What makes this worse is that the default IIS error page deliberately hides the actual diagnostic detail from external clients, for good security reasons, so if you're testing from a different machine you'll just see a generic "500 Internal Server Error" with no clue what went wrong.
Who sees IIS web apps errors most often? Developers who inherited a legacy Classic ASP application, teams migrating from an older Windows Server version to Server 2019 or 2022, and anyone running mixed-mode authentication with Kerberos and Active Directory. The IIS platform itself is well-tested and stable, when things go wrong, it's almost always a configuration or permission problem, and that means it's fixable.
I know this is frustrating, especially when it blocks your work or, worse, blocks your customers. Let's get systematic about it. Browse all Microsoft fix guides →
The Quick Fix for IIS Web Apps Errors, Try This First
Before you go deep into Failed Request Tracing or Event Viewer archaeology, there's one change that unlocks the real error message hidden behind IIS's generic 500 screen. Turn on detailed errors for local requests, or temporarily for all requests, so IIS stops obscuring what's actually wrong.
Open IIS Manager (press Win + R, type inetmgr, hit Enter). In the left-hand Connections pane, click on your site or application. In the Features view in the center, double-click Error Pages. On the right-hand Actions pane, click Edit Feature Settings…. Switch the radio button from Custom error pages to Detailed errors. Click OK.
Now reload the failing URL. IIS will show you the actual error: the full exception message, the failing line in your web.config, the missing module name, or the exact permission denial. Nine times out of ten, that one message tells you exactly where to look next.
If you see HTTP Error 500.19 with a sub-status description mentioning "cannot read configuration file" or "configuration section cannot be used at this path," the culprit is almost certainly one of three things: a syntax error in your web.config, a locked configuration section that's been set at the server level and is blocking a site-level override, or a handler/module referenced in your config that isn't installed on this particular server. The detailed error page will show you the exact config file and line number.
For HTTP 500.0 errors, the detailed view will usually surface an HRESULT code and a COM-related message. Note that code, you'll need it in the steps below.
Once you've captured the real error, flip error display back to custom pages before you push anything to a production environment. Detailed errors should never be left on for external clients, they expose internal path structures and server configurations.
web.config in the inheritance chain is causing the conflict, IIS config can be inherited from the server root, the site level, and the application folder, and the guilty file isn't always the one you expect.
Every IIS application pool crash, failed COM object, and ASP execution failure writes an entry to the Windows Application Event Log. I can't stress this enough: do not skip this step. The Event Log is where IIS puts the information it won't show in the browser.
Press Win + R, type eventvwr.msc, and press Enter. In the left pane, expand Windows Logs and click Application. Look for Error entries with sources like IIS-W3SVC-WP, ASP.NET, Transaction Server, or W3SVC. Sort by date and filter to the window when your failures started.
Pay particular attention to EventID 4134 from the Transaction Server source, this is the signature of a COM component instantiation failure. The entry will show you the ProgID and CLSID of the component that failed, along with an HRESULT. The HRESULT 0x80080005 specifically means "server execution failed," which ties directly to MTS package identity problems. If you see this code, jump straight to Step 3.
For general application pool crashes, look for WAS (Windows Process Activation Service) entries. A recurring pattern of application pool recycling at irregular intervals, especially under moderate load, often points to memory pressure or an unhandled exception in managed code that's not being caught.
// PowerShell: Pull last 50 Application log errors from IIS sources
Get-EventLog -LogName Application -EntryType Error -Newest 50 |
Where-Object { $_.Source -match "IIS|W3SVC|ASP|Transaction" } |
Select-Object TimeGenerated, Source, EventID, Message |
Format-ListRun that command in an elevated PowerShell window. If you see a wall of the same EventID repeating, that's your problem. Copy the full message text, you'll reference it in every subsequent step.
The IIS HTTP 500.19 internal server error is one of the most common IIS web apps errors, and it always means IIS couldn't read or parse a configuration file. The detailed error page (which you enabled in the Quick Fix section) will show you a "Config Error" description and a "Config File" path. Those two pieces of information are everything.
The most frequent sub-error is Error Code 0x8007000d, this means a configuration section in your web.config is locked at the machine level and your application is trying to override it at the site or application level. Open IIS Manager, navigate to your server node (the top level in the Connections pane), and double-click Configuration Editor. Navigate to the section path shown in the error (e.g., system.webServer/handlers). In the right-hand panel, look at the lock icon. If "Override Mode" is set to "Deny," change it to "Allow" and click Apply.
If the error is a straight XML parse failure, the config file has a syntax error, open the file in a proper XML editor, not Notepad. Visual Studio Code with the XML extension will highlight the broken tag immediately.
Another very common cause: a module referenced in <handlers> or <modules> in your web.config simply isn't installed on this server. If your config references StaticCompressionModule or DynamicCompressionModule and those IIS features weren't added during Windows setup, you'll get a 500.19. Fix it through Turn Windows features on or off → Internet Information Services → World Wide Web Services → Performance Features, and check the relevant boxes.
// PowerShell: Validate web.config XML syntax before deploying
[xml](Get-Content "C:\inetpub\wwwroot\YourApp\web.config")
# If this throws an error, your XML is malformed, fix it before restarting IISAfter fixing the config, run iisreset /noforce from an elevated command prompt and test again.
If your IIS web app serves Classic ASP pages that instantiate COM components, there's a specific failure pattern you need to know about. The error looks like this:
Server object error 'ASP 0177 : 80080005'
Server.CreateObject Failed
/yourpage.asp, line XX
Server execution failedOr, if the component is instantiated directly without Server.CreateObject:
Microsoft VBScript runtime error '800a01ad'
ActiveX component can't create object: 'YourCOM.Component'This happens because the Microsoft Transaction Server (MTS) Package that hosts your COM component has its identity set to Interactive User, meaning it runs as whoever is currently logged in to the server console. The moment that person signs out (a nightly Windows Update reboot, an operator logging off for the day), the COM components become unreachable and every ASP request that touches them fails with 0x80080005.
The fix is permanent and straightforward. Open Component Services (press Win + R, type dcomcnfg, press Enter). Expand Component Services → Computers → My Computer → COM+ Applications. Right-click your MTS package and select Properties. Go to the Identity tab. Switch from Interactive User to This User and enter a dedicated service account with the minimum permissions needed to run the component. Click OK.
Set a strong password on that service account, and make sure the account has Log on as a service rights via Local Security Policy. After saving, right-click the package and click Start to confirm it comes up cleanly. The ASP 0177 / 80080005 error will stop immediately, this fix is confirmed by Microsoft as the authoritative resolution for this failure mode.
Here's another IIS web apps error that looks nearly identical to the MTS package issue but has a completely different root cause. If your Application Event Log shows:
Failed on creation from object context: CoCreateInstance
(ProgId: ADODB.Connection.1.5)
(CLSID: {some-GUID-here})And your browser shows:
Microsoft VBScript runtime error '800a01ad'
ActiveX component can't create object...the problem is not the MTS identity. It's a file system permission issue. The anonymous access account (IUSR_machinename) and the out-of-process worker account (IWAM_machinename) don't have read access to the DLLs being instantiated.
Open Windows Explorer and navigate to the ADO directory:
C:\Program Files\Common Files\System\ADORight-click the ADO folder, select Properties → Security tab → Edit. Click Add and type IUSR_YourMachineName (substitute your actual machine name, you can find it by running hostname in a command prompt). Grant Read & Execute and Read permissions. Repeat for IWAM_YourMachineName. Click Apply and OK.
This applies broadly: any time ASP is trying to create an object from a DLL and failing with 800a01ad, check whether IUSR and IWAM have read access to the directory containing that DLL. The same fix applies to custom COM components you've registered, navigate to the directory where the DLL is registered and grant the same Read permissions to those two accounts.
After updating permissions, do a full iisreset and retest. The VBScript runtime error should be gone. If it persists, also check that the COM component is properly registered by running regsvr32 yourcomponent.dll from an elevated command prompt.
When the Event Log and detailed error pages still aren't giving you enough to go on, Failed Request Tracing (FRT) is the most powerful IIS diagnostic tool in existence. I've used it to track down errors that had stumped teams for days. It captures a complete log of everything IIS did to handle a request, every module that touched it, every authentication check, every handler decision, right up to the moment it failed.
To enable it: open IIS Manager, click on your site, and in the Features view double-click Failed Request Tracing Rules. In the right Actions pane, click Add…. Set the content type to All Content (*) or narrow it to the specific file extension you're troubleshooting. Set the status codes to the range you want to capture, for IIS web apps errors, enter 500-599. On the next screen, check all three trace provider boxes: ASP, ASPNET, and WWW Server. Leave verbosity at Verbose and click Finish.
Also make sure FRT logging is enabled at the site level: click your site in the Connections pane, then in the right Actions pane click Failed Request Tracing…. Check the Enable box and confirm the log directory path (default is %SystemDrive%\inetpub\logs\FailedReqLogFiles).
Now reproduce the error. Navigate to the log directory and open the most recent fr######.xml file in Internet Explorer (it ships with an XSL stylesheet that renders it as a readable HTML report). Look for the last event before the failure, the module name and event data in that row will tell you exactly what component caused the 500 error.
// PowerShell: List the most recent FRT log files
Get-ChildItem "C:\inetpub\logs\FailedReqLogFiles" -Recurse -Filter "*.xml" |
Sort-Object LastWriteTime -Descending |
Select-Object -First 5 FullName, LastWriteTimeOnce you've identified the root cause, remember to disable FRT, it does add overhead, and you don't want verbose XML traces accumulating on a production disk indefinitely.
Advanced Troubleshooting for IIS Web Apps Errors
Diagnosing High CPU in an IIS Application Pool
A runaway application pool that pegs a CPU core at 100% is one of the nastier IIS web apps errors because it's not a clean crash, the site stays "up" but becomes completely unresponsive. The official Microsoft guidance here is clear: the first step is to correlate the high CPU spike with requests in the IIS access logs, then take a process dump at the moment of high CPU for analysis.
From an elevated command prompt, use ProcDump from the Sysinternals suite to capture a dump of the w3wp.exe process when CPU exceeds a threshold:
procdump -c 85 -s 10 -n 3 -ma w3wp.exe C:\dumps\This waits for the w3wp process to hit 85% CPU for 10 consecutive seconds, then captures 3 full memory dumps to the C:\dumps\ directory. Open those dumps in WinDbg or Visual Studio and look at the active thread call stacks, the stack that repeats across many threads is your hot path.
Common culprits: inefficient LINQ queries generating enormous in-memory collections, synchronous I/O on the request thread, or a tight loop in a background thread that the application pool is running. In Classic ASP, infinite loops caused by a RecordSet that never hits EOF are a frequent offender.
Diagnosing Native Memory Leaks in the Application Pool
If your application pool worker process (w3wp.exe) grows in memory over hours or days until IIS recycles it, and you see that recycle happening in the Application Event Log, you may have a native memory leak. This is distinct from a managed heap leak. Native leaks happen in unmanaged COM components, native modules, or P/Invoke calls that allocate memory without ever freeing it.
Microsoft's official guidance recommends enabling ETW logging through IIS to capture memory allocation events. Open an elevated command prompt and run:
logman create trace iisleak -p "Microsoft-Windows-IIS" 0xFFFFFFFF 5 -ets
logman start iisleak -ets
// ... reproduce the leak scenario ...
logman stop iisleak -etsThe resulting ETL file can be analyzed in Windows Performance Analyzer (WPA) from the Windows Assessment and Deployment Kit.
Processor Affinity and NUMA Topology Issues
On multi-socket servers with NUMA (Non-Uniform Memory Access) architecture, IIS has a known limitation where processor affinity settings configured through IIS Manager may not correctly honor NUMA node boundaries. If you've set processor affinity for an application pool and still see cross-NUMA memory access (identifiable through Performance Monitor counters), this is a documented behavior. The workaround is to set affinity via the applicationHost.config file's <cpu> element directly, specifying the exact logical processor mask, rather than using the IIS Manager UI's checkbox grid.
Kerberos Double-Hop and Authentication Failures
If your IIS app uses Windows Integrated Authentication and you're seeing 401 errors on resources that the app tries to access on behalf of the user, like a SQL Server on a different machine, you're hitting the Kerberos double-hop limitation. The web server receives the user's Kerberos ticket but can't re-delegate it to the downstream server without explicit configuration.
The fix requires configuring Service Principal Names (SPNs) for the service account running the IIS application pool and enabling Kerberos constrained delegation in Active Directory. This is strictly a domain admin operation, IIS alone can't fix it.
Prevention & Best Practices for IIS Web Apps Errors
The best IIS web apps error is the one you never see in production. After years of watching the same failure patterns repeat, here's what genuinely moves the needle on reliability.
Never run application pools under interactive user identity. This is the single root cause of the ASP 0177 / 80080005 error, and it's entirely avoidable from day one. Every application pool should run under either a dedicated service account with minimal permissions or the built-in ApplicationPoolIdentity virtual account. Document the service account for each pool in your runbook so the next person doesn't have to reverse-engineer it.
Validate web.config before every deployment. A deployment pipeline that ships a broken XML config file to production is a deployment pipeline that will cause an outage. Add a pre-deployment step that runs the PowerShell XML parse check shown in Step 2. Takes two seconds and catches the majority of config-induced 500.19 errors before they ever hit a real server.
Use Application Initialization module for cold start. IIS cold start, the delay users experience after an application pool recycles, happens because the runtime doesn't start until the first real request arrives. The Application Initialization IIS module (installable via Turn Windows features on or off → IIS → Application Development Features) lets you pre-load the application during IIS startup. Set startMode="AlwaysRunning" on the application pool and preloadEnabled="true" on the application in applicationHost.config.
Configure appropriate recycling schedules, not default ones. The default IIS application pool recycle is set to every 1,740 minutes, just under 29 hours. For most applications this is fine, but for applications with genuine memory leaks or COM stability issues, you may need to tune this. Set recycling to happen during a known low-traffic window (a specific time of day) rather than on a rolling interval, and log recycle events to the Windows Event Log so you know when they happen.
Keep IUSR and IWAM account permissions audited. Any time you install new components or move a site to a new directory, the read permissions for IUSR and IWAM need to follow. Create an automated check, a weekly PowerShell script that verifies read access to key DLL directories, rather than waiting for a 800a01ad error to tell you something changed.
- Enable Failed Request Tracing in staging environments permanently, there's no cost when no failures occur, and it captures the first sign of any new deployment issue.
- Set IIS application pool to restart after a specific number of errors using the Rapid-Fail Protection settings rather than letting a broken pool hammer your server indefinitely.
- Create a health-check endpoint in every IIS web app that exercises the critical code paths (database connection, COM component instantiation) and monitor it every 60 seconds with your alerting system.
- Keep a tested
web.configbackup in source control and automate the diff check between what's in the repo and what's deployed, configuration drift is one of the most common causes of mysterious IIS errors months after an initial deploy.
Frequently Asked Questions About IIS Web Apps Errors
Why do I keep getting HTTP 500.19 even after I fix the web.config syntax?
A valid XML file isn't enough, the configuration section itself might be locked at the server level. Open IIS Manager, go to the server node, open Configuration Editor, find the section matching the one in your error (e.g., system.webServer/handlers), and check whether Override Mode is set to Deny. If it is, change it to Allow. Also double-check that every module and handler referenced in your config is actually installed on the server, a reference to a missing module produces a 500.19 even with perfect XML syntax.
My IIS app works fine for hours then suddenly returns 500 errors, what causes that?
This pattern almost always points to either an application pool recycle clearing in-memory state your app depends on, or a session/connection pool exhaustion that builds up over time. Check your Event Log around the exact time the failures start, look for WAS or W3SVC entries indicating a pool recycle. If the recycle is happening because the pool hit its memory limit (Rapid-Fail Protection threshold), you have a memory leak to track down using the ProcDump approach described in the Advanced Troubleshooting section. If there's no recycle event, the issue may be a connection string pool timeout or a COM component that reaches an internal failure state after a certain number of calls.
How do I fix the "Server execution failed" ASP 0177 80080005 error without rebooting?
You don't need a reboot, just a package identity change. Open Component Services (dcomcnfg), find your MTS package under COM+ Applications, right-click Properties → Identity tab, switch from Interactive User to a specific named service account, then right-click the package and select Start. The fix is immediate. The 80080005 error occurs because the Interactive User identity stops working the moment anyone logs off the server console, so switching to a non-interactive service account eliminates the failure condition entirely. This is confirmed as the official Microsoft resolution for this error.
What's the difference between HTTP 500.0 and HTTP 500.19 in IIS?
HTTP 500.0 is a general internal server error, it means the application itself threw an unhandled exception or a COM component failed to execute. The error is in the running code. HTTP 500.19, on the other hand, means IIS couldn't even load the configuration for the site or application, the failure happens before a single line of your application code runs. So 500.19 is always a config or permissions problem with your web.config or applicationHost.config, while 500.0 requires looking at application logs, the Event Viewer, and potentially Failed Request Tracing to find the runtime exception.
Is HTTP 405 Method Not Allowed an IIS configuration problem or an application bug?
Usually IIS configuration. HTTP 405.0 means the server understood your request method (like PUT or DELETE) but no handler is configured to accept it for that URL. The most common scenario: you're building a REST API and IIS's built-in WebDAV module is intercepting PUT and DELETE requests before your application sees them. Disable WebDAV in IIS Manager (under the site's Modules feature, remove WebDAVModule) or add an explicit <remove> for it in your web.config. You may also need to remove the WebDAV handler from the <handlers> section. After those changes, a full iisreset will surface your application's own handling for those methods.
How do I stop IIS cold start from making the first request after a pool recycle take 30+ seconds?
Install and configure the IIS Application Initialization module. In applicationHost.config (found at C:\Windows\System32\inetsrv\config\applicationHost.config), set your application pool's startMode attribute to AlwaysRunning and add preloadEnabled="true" to your application's site definition. Optionally, create an <applicationInitialization> section in your web.config that specifies a warm-up URL path, IIS will hit that URL during startup, which causes the runtime to initialize fully before the first real user request arrives. This eliminates cold start delays entirely and is the official Microsoft-recommended approach for production IIS deployments that can't afford warm-up latency.