Debug Diagnostics - Hanging ASP.NET web service

A large number of CLOSE_WAIT is almost always caused by networking issues
(either the NIC in the web server or something downstream). If packets are
being dropped, then the TCP RFC spells out that you have to go into a
timeout situation to ensure no duplicate packets are on the network.

In a (usermode) debugging scenario you will typically see a bunch of threads
in a WinSock call (WS2_32.dll, etc.). The threads will all be in a WAIT
state (WaitForSingleObject() is probably at the top of the stack).

You can create a log with threads using IISState either during a hang or a
crash.


Pat



"Boro Marinkovich" <boro.marinkovich.TakeThisOut@t4g.com> wrote in message
news:uI97icZQGHA.5400@TK2MSFTNGP09.phx.gbl...
> We have an asp.net web service application (3 actually) setup to run in
> seperate application pools. We are finding that one of the applications
> hangs intermittently but does not crash. During this time a netstat shows
> a
> large number of CLOSED_WAIT status for connections to the server. To fix
> the problem, we have found that we need to delete and recreate the
> application pool as it seems to become corrupt.
>
> We are attempting to use the IIS Toolkit Debug Diagnostics tool to get a
> stack trace dump when the hang occurs. However this tool appears to only
> create a dump when the application crashes, rather then hangs.
>
> Is there a way to force a stack trace dump so we can analyze where the
> application hangs to attempt to resolve the bug.
>
> Thanks.
> Boro
>
>
 >> Stay informed about: Debug Diagnostics - Hanging ASP.NET web service