A generic 500 page and one line in the event log is a poor starting point for debugging IIS. Failed Request Tracing (FREB) fixes that: it records a full trace of every module decision for requests that match your failure conditions, showing you exactly which module returned the error and why. It is the right tool for 500.19 configuration errors, 500.30 startup failures, slow pages, and rewrite loops.<\/p>\n\n
FREB is an optional IIS component. On a full GUI install: Server Manager, Add Roles and Features, Web Server (IIS), Health and Diagnostics, and tick Tracing. From PowerShell:<\/p>\n\n
Install-WindowsFeature Web-Http-Tracing<\/code><\/pre>\n\nThe feature installs the provider and the log infrastructure; it does not start tracing anything until you define a rule.<\/p>\n\n
Create a tracing rule<\/h2>\n\n
In IIS Manager, select the site, open Failed Request Tracing, and enable it. Then open Failed Request Tracing Rules, Add Rule, and define:<\/p>\n\n
- Content to trace: all content, or a specific extension\/path (for example *.aspx or \/api\/*).<\/li>
- Failure conditions: status code ranges such as 500-599, or time taken over a threshold such as 30 seconds, or both.<\/li><\/ul>\n\n
Equivalent command-line setup with appcmd:<\/p>\n\n
appcmd set site \"Default Web Site\" -traceFailedRequestsLogging.enabled:true\nappcmd set config \"Default Web Site\" -section:system.webServer\/tracing\/traceFailedRequests \/+\"[path='*',customAction=500]\" \/commit:apphost<\/code><\/pre>\n\nTraces land in %SystemDrive%\\inetpub\\logs\\FailedReqLogFiles by default, one folder per failed request.<\/p>\n\n
Reading the trace XML<\/h2>\n\n
Each failed request produces an XML file (open it in a browser – the XSL stylesheet renders it readably) plus the raw file. The trace is a chronological list of events from every module that touched the request. You are looking for two things:<\/p>\n\n
- Entries with Level=”Warning” or “Error” – these are the events where a module failed.<\/li>
- The GENERAL_SET_RESPONSE_ERROR_STATUS \/ MODULE_SET_RESPONSE_ERROR_STATUS entries, which record the HTTP status and substatus code (for example 500.19 or 500.30) and name the module that set it.<\/li><\/ul>\n\n
The last error-level entry before the response is sent is normally your culprit. From the command line you can grep for it:<\/p>\n\n
Select-String -Path \"C:\\inetpub\\logs\\FailedReqLogFiles\\w3svc1\\*.xml\" -Pattern \"MODULE_SET_RESPONSE_ERROR_STATUS\" | Select-Object -First 5<\/code><\/pre>\n\nCommon failure patterns<\/h2>\n\nSymptom<\/th> What the trace shows<\/th> Fix<\/th><\/tr><\/thead> 500.19<\/td> CONFIGURATION_ERROR event in the config section<\/td> Malformed web.config or missing section; fix the line reported in the trace<\/td><\/tr> 500.30<\/td> In-process startup failure before modules complete<\/td> Check the stdout log and Application event log for the real exception<\/td><\/tr> 502.5<\/td> Process failure in out-of-process hosting<\/td> The app crashed on launch; read stdout and fix startup<\/td><\/tr> 404.19 \/ 404.20<\/td> Request filtering rejected the extension<\/td> Add the extension to the allowed list in Request Filtering<\/td><\/tr> Rewrite loop<\/td> Multiple URL_REWRITE passes with no terminal match<\/td> Fix the rewrite rules – add a condition or a stopProcessing flag<\/td><\/tr> Slow request<\/td> Time taken exceeds your threshold; one module dominates<\/td> Identify the slow module (often auth or compression) and optimize it<\/td><\/tr><\/tbody><\/table><\/figure>\n\nStatic files and managed requests<\/h2>\n\n
FREB traces the whole pipeline, not just managed code. A slow static-file request shows up in the StaticFileModule events; a rewrite loop shows repeated URL Rewrite passes over the same URL. This is what makes FREB better than application logs alone for IIS-level problems: you see exactly which module spent the time or returned the status, including modules that never touch your application code.<\/p>\n\n
For ASP.NET Core apps specifically, split your debugging: FREB covers everything IIS-side (bindings, rewrite, request filtering, static files), while the app’s own startup failures surface in the stdout log and the Application event log. The classic pairing – a 500.30 in FREB plus a first-chance exception in stdout – resolves most broken first deploys in minutes.<\/p>\n\n
Retention and cleanup<\/h2>\n\n
Trace files accumulate fast. Set sane limits up front so a burst of failures cannot fill the disk:<\/p>\n\n
appcmd set config -section:system.webServer\/tracing\/traceFailedRequestsLogging \/maxLogFiles:20 \/maxLogFileSizeKB:1024 \/directory:\"%SystemDrive%\\inetpub\\logs\\FailedReqLogFiles\"<\/code><\/pre>\n\nThat caps the site at 20 trace files of 1 MB each, which is plenty for a debugging session and self-cleaning afterwards. When the investigation is over, disable the rule in IIS Manager or with appcmd – leaving FREB enabled on a busy production site is a classic cause of unexplained disk-full alerts.<\/p>\n\n
Operational notes<\/h2>\n\n- Tracing has a real cost: every matching request writes XML to disk. Enable FREB only on the site you are debugging, and only for the duration of the investigation.<\/li>
- Set sane limits – maximum trace file count and size – so a busy site does not fill the disk while you are away.<\/li>
- Disable the rule when you are done. Leaving FREB on in production is a common cause of mysterious disk-full alerts.<\/li><\/ul>\n\n
FREB turns IIS debugging from guesswork into reading a transcript. Enable the feature, define a narrow rule, reproduce the failure, and read the last error-level event – in most cases the fix is visible within minutes. If you are still choosing where to host the site you will be debugging, compare Windows VPS plans on our table<\/a>, or check our main site<\/a> for Windows Server VPS options with full IIS access.<\/p>\n\nIf you want a Windows VPS where you control IIS completely – including Failed Request Tracing – Hostwinds’ Windows VPS plans<\/a> include full administrative access and unmanaged control of the web server.<\/p>","protected":false},"excerpt":{"rendered":"