As part of an ongoing IIS forensics to figure out why a website is spontaneously hanging for 1-3 minutes, I came across a command to show the in-process requests in IIS. This information is supposedly in the IIS Management Console as well but a) it's not capturable easily, and b) it never seems to refresh for me. So I put on my Clever Hat and decided to go old school and go to the command line.
appcmd list request
This lists out the current request queue. I went one step further and created a .bat file to poll this command every 5 seconds, logging it to a text file.
ECHO It's %Now% now
ECHO %Now% >> request.log
appcmd list request >> request.log
ping -n 6 127.0.0.1 >nul
The ping command acts as a sleep timer. Windows ping command executes every second, so this is pinging localhost 6 times (5 seconds total), sent to NUL so I don't see it in the console, then loops around.
The output of the file is similar to this:
REQUEST "e600000180000137" (url:GET /home.asp, time:1216 msec, client:127.0.0.1, stage:ExecuteRequestHandler, module:IsapiModule)
REQUEST "d300000080000582" (url:GET /menu.asp, time:1216 msec, client:127.0.0.1, stage:ExecuteRequestHandler, module:IsapiModule)
Where nothing was queued when the first few polls happened, then there were 2 requests in process at 20:46:53.92. It shows the internal IIS Request ID, what it was, the time (so far) that it's taken, the remote IP address, and where it is in the request process. While the timestamp doesn't give millisecond precision, centiseconds are still pretty good to help narrow things down in other logs. You can subtract the request time's milliseconds from the polling timestamp to figure out a rough starting place for the beginning time of the request. There will be some precision errors since you're subtracting milliseconds from centiseconds, but you'll be very close.
Also, I'm polling every 5 seconds above, which is sorta overkill for this specific exercise. If a request hangs for 1-3 minutes, a 30 second poll of this command is more than sufficient to catch it "in the act" and figure out which request is hanging the longest. Most likely that's the one that will be the culprit for further analysis.
From here you could look at Failed Request Trace logs, Process Monitor, etc. to help narrow down the root cause of your problem.