OK - I have to admit that one of my favorite features for IIS 7 is "Failed Request Tracing", otherwise known as "FREB". I've taught breakout sessions about FREB at Microsoft TechEd, and IT administrators love it. (By the way - FREB was originally called "Failed Request Event Buffering", in case you're wondering why the acronym doesn't match. ;-] )
Anyway, FREB is designed as "no repro" tracing, where you can set up tracing rules for specific conditions and IIS will generate log files if those rules are triggered. I like to refer to this as "set it and forget it" logic, because you enable your tracing conditions and then check for log files later.
I enabled FREB tracing for HTTP 500 errors on a new server recently, and I enabled it at the global level so an HTTP 500 error on any web site would generate a log file. A few days later I was checking my HTTP logs using LogParser to give me a break down of HTTP requests by status, and I saw that a few HTTP 500 errors had turned up. Being the geek that I am, for a few fleeting moments I was more elated that I had some live FREB logs to check and I almost forgot about finding & fixing the root cause.
Sure enough, however, IIS 7 had faithfully created several FREB logs for me. Open opening the logs, it correctly listed the logs' trigger status as an HTTP 500 error, and it listed the even as LOG_FILE_MAX_SIZE_TRUNCATE. I assumed that this meant that I had run out of room for my IIS W3C log files. But then I thought - this is strange, it's a new server and I have lots of hard drive space free, so how can I be out of log file disk space?
Then it dawned on me - I was thinking about the wrong log files; the error message was trying to tell me that the FREB logs were too big. By default IIS 7 truncates the FREB log files at 512KB. Since I had turned on full verbosity for the FREB logs, there was simply too much data for the log files to complete.
The following commands took care of that problem, and the next time an HTTP 500 error was triggered I received the full FREB log file and it pinpointed the exact problem:
cd /d "%windir%\system32\inetsrv"
appcmd set config /section:sites -siteDefaults.traceFailedRequestsLogging.maxLogFileSizeKB:1024
Bear in mind, though, that the above command configures your log files so that each can be 1MB in size, instead of the default 512KB. This probably doesn't matter much given the price of hard drive space these days, but I wanted to point it out.
Before closing on this thought, I thought I'd show some of the other commands that I used to configure FREB at the global-level.
- List available global-level FREB settings:
appcmd set config /section:sites -? | find "traceFailedRequestsLogging"
- Enable FREB tracing at the global-level:
appcmd set config /section:sites -siteDefaults.traceFailedRequestsLogging.enabled:true
- Set the default number of FREB logs to 10, instead of the schema default of 50:
appcmd set config /section:sites -siteDefaults.traceFailedRequestsLogging.maxLogFiles:10
- Reset the default max FREB log file size back to 512KB:
appcmd set config /section:sites -siteDefaults.traceFailedRequestsLogging.maxLogFileSizeKB:512
For more information on FREB, see the following topics:
Read the complete post here