Fix IIS 503 error: Disable WebDAV and hidden segments

The fix

Open IIS Manager. Expand your server node, then Sites, and select the site throwing the 503. On the right, under Manage Server, click Restart. If that doesn't stick, do this:

1. Click the site's Application Pools from the left tree.
2. Find the pool your site uses. Right-click it and select Recycle.
3. Now disable WebDAV: back in the site view, double-click WebDAV Authoring Rules (if you see it). Click Disable WebDAV in the right panel.
4. Open Request Filtering — double-click that icon. Go to the Hidden Segments tab. Look for bin, App_Code, App_Data — if they're there, that's normal. But if you see web.config or global.asax listed, that's your problem. Select any that aren't supposed to be blocked and click Remove.
5. Finally, open a command prompt as admin and run:

   net stop w3svc && net start w3svc

Test your site. If it loads, you're done. If not, read on.

Why this works

What's actually happening here is that IIS's application pool crashes because a module or request filtering rule blocks a legitimate request. The 503 Service Unavailable message is IIS telling you the worker process (w3wp.exe) has stopped responding — usually after hitting a fatal error threshold.

WebDAV is the most common culprit. It's enabled by default on Windows Server 2012 R2 through 2022, but most sites don't need it. The WebDAV module intercepts PUT, DELETE, and PROPFIND requests. If a client (or even a search bot) sends an unexpected WebDAV verb, IIS's request handling can throw an unhandled exception, crash the app pool, and trigger the 503.

The Request Filtering module is another trap. It blocks certain URL segments for security. But if you (or a deployment script) accidentally added web.config as a hidden segment, every request to your site fails because IIS sees that path as forbidden — but it doesn't show a 403; it silently kills the pool. Yes, it's a bug in how older IIS versions handle the hidden segments list combined with module ordering.

Recycling the app pool clears the crashed worker process. Disabling WebDAV removes the module that triggered the crash. Cleaning hidden segments ensures the URL isn't being blocked at the filter level. Restarting the WAS service (W3SVC) re-reads the configuration cleanly.

Less common variations

503.2 — Lock request limit exceeded

This one shows up as 503.2 in the browser or event log. It means the request filter's Maximum URL segments limit is too low. Default is 255, but some apps like SharePoint or custom MVC routes can exceed that. Open Request Filtering, click Edit Feature Settings, and raise the Maximum URL segments to 1024. Also check Maximum query string and Maximum allowed content length — bump those too if your app POSTs large data.

App pool identity permissions

Sometimes the app pool crashes because the identity account (like ApplicationPoolIdentity) can't read the site's physical path. Check the event log for errors from WAS source. If you see The worker process failed to initialize or Could not load file or assembly, the fix is granting read/execute permissions on the site folder to IIS_IUSRS or the pool's specific identity. Right-click the site folder > Properties > Security > Add IIS AppPool\YourPoolName with read & execute.

Third-party modules (URL Rewrite, ARR, Helicon)

If you're running URL Rewrite or Application Request Routing (ARR), a bad rewrite rule can cause an infinite loop that exhausts the app pool's thread pool. Disable custom modules one by one to isolate it. In IIS Manager, click the server node, then Modules. Uncheck suspect modules, recycle the pool, test. The usual offender is a rule that rewrites .* to http://localhost:8080/{R:1} without proper conditions — ARR will loop back to itself.

Prevention

First, disable WebDAV globally on the server unless you explicitly need it. Open IIS Manager, click the server node, open Modules, find WebDAVModule, and remove it. Or use PowerShell:

Remove-WebConfigurationProperty -PSPath IIS: -Filter system.webServer/modules -Name . -AtElement @{name='WebDAVModule'}

Second, set up a monitoring script that checks the app pool state every 60 seconds. Here's a one-liner you can schedule in Task Scheduler:

$pool = Get-IISAppPool 'YourPoolName'; if ($pool.State -ne 'Started') { Restart-WebAppPool $pool.Name; Write-EventLog -LogName Application -Source IIS -EntryType Warning -EventId 1001 -Message 'App pool recycled from 503 detection' }

Third, enable Application Pool Rapid-Fail Protection intelligently. It's on by default, but set the failure count to 10 (not the default 5) and the time window to 10 minutes. That gives you enough runway to fix the root cause without the pool permanently shutting down. In the app pool's Advanced Settings, set Rapid Fail Protection > Failure Count = 10.

Finally, log every 503 to the Windows event log. In IIS Manager, select the site, open Failed Request Tracing, enable it, and define a rule for status code 503. That writes detailed XML trace files showing exactly which module failed and why. You'll find them in %SystemDrive%\inetpub\logs\FailedReqLogFiles\.