I have a client who is possibly suffering from TIME_WAIT exhaustion and I thought that the best way to find out for sure was to get them to add the TIME_WAIT perfmon counter to their normal counter logs so that we could see how and when sockets in TIME_WAIT accumulate on the machine.

The problem is that there doesn’t seem to be a perfmon counter for this, which is unfortunate, especially since you can easily get the number of established and reset connections from the TCPv4 and TCPv6 performance objects.

Since all of this information is available by querying the TCP table with GetTcpTable() or GetExtendedTcpTable() I might put together a utility that polls the TCP table and publishes the a TIME_WAIT counter, however, before doing that I decided to hack up a simple example that polls the TCP table and simply dumps the number of connections in TIME_WAIT to the console. This is a bit like netstat and post processing the output.

I got this working quite nicely and then thought it might be useful to switch to using MIB_TCPTABLE_OWNER_PID so that I could group the connections by process and so show which processes were causing the TIME_WAIT connections to accumulate. Unfortunately the dwOwningPid field is set to zero for connections in TIME_WAIT, which is somewhat understandable, as they can outlive the process that generated them, but unfortunate when they haven’t…