In June it appears that a new IIS debug/diagnostic tool will appear (see June IIS webcasts). Until that appears, we're still using the venerable IIState or ADPlus to troubleshoot IIS Crash/Hang situations.

Recently on an email list a poster asked a query regarding some ASP code they had. Apparently IIS was "hanging" when the code was placed into production. Rather than look through lots of individual pages of ASP code (it might not have had anything to do with the ASP code), we had a look at an IISState log instead.

The problem turned out to be that the poster was using the MSXML HTTP object (XMLHTTP) to make requests to a remote website (they were trying to do some reverse proxying work. The problem with using this in a server-side application is that the HTTP object uses WinInet under the covers, and this limits you to two concurrent HTTP connections to each remote host (per the HTTP v1.1 specification). All the other threads making requests were blocked, giving the appearance of a hang. The lesson to this: use the ServerXMLHTTP object instead.

Caveat: I make no pretense to being a hard-core windows programmer, so my comments below might be off-the-mark, but you can get the basic gist of what's happening. If you look at the IISStage logs, you see a lot of threads that look like this (read from the bottom up):

Thread ID: 21
System Thread ID: 1778
Kernel Time: 0:0:0.31
User Time: 0:0:0.656
Thread Type: ASP
Executing Page: 
 # ChildEBP RetAddr
00 0269ed94 77f43741 SharedUserData!SystemCallStub+0x4
01 0269ed98 77e41817 ntdll!ZwWaitForSingleObject+0xc          <- Wait
02 0269ee08 77e4168f kernel32!WaitForSingleObjectEx+0xac
03 0269ee18 760f3417 kernel32!WaitForSingleObject+0xf
04 0269ee2c 760f3513 WININET!URL_CONTAINER::LockContainer+0x23
05 0269ee40 760f59aa WININET!URL_CONTAINER::GetHeaderData+0x10
06 0269ee4c 760f5963 WININET!GetCurrentSettingsVersion+0x29
07 0269ee60 761081a5 WININET!InternetSettingsChanged+0x10
08 0269f11c 75fd0dbd WININET!InternetConnectA+0xaa            <- Invoke WinInet
09 0269f14c 75fd0e14 urlmon!CINet::INetAsyncConnect+0x122
0a 0269f15c 75fca7d1 urlmon!CINet::INetAsyncOpen+0xde
0b 0269f16c 75fca79a urlmon!CINet::INetAsyncStart+0x18
0c 0269f188 75fc6ef7 urlmon!CINet::Start+0x1c9
0d 0269f1b0 75fc6c7b urlmon!COInetProt::Start+0x62
0e 0269f1f8 72f04304 urlmon!CTransaction::Start+0x3ac         <- Handoff to URLMon
0f 0269f23c 72f03185 msxml3!CXMLHTTP::send+0x144              <- XML HTTP Send Request
10 0269f294 770f6109 msxml3!XMLHTTPWrapper::send+0x52
11 0269f2bc 7713f5ff OLEAUT32!DispCallFunc+0x15d
12 0269f34c 72e9549a OLEAUT32!CTypeInfo2::Invoke+0x232
13 0269f37c 72e95619 msxml3!_dispatchImpl::Invoke+0x6a
14 0269f3ac 72f03968 msxml3!__dispatch::Invoke+0x29
15 0269f3dc 7348b427 msxml3!_dispatchEx::Invoke+0x28