GetExtendedTcpTable(), MIB_TCPTABLE_OWNER_PID and TIME_WAIT

| 2 Comments
I have a client who is possibly suffering from TIME_WAIT accumulation issues 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...

2 Comments

I think TCPView from SysInternals has the same problem.

It can display every connection and its state, and it has a column that shows the owning process.

But as soon as a TCP connection goes into a TIME_WAIT state, the process column changes to (System Process):0.

If the great Mark Russinovich couldn't solve this, it is probably not a easy problem. :)

... Alan

I'm not going to spend any time on it, it just would have been convenient.

Leave a comment

About this Entry

Practical Testing: 31 - A bug in DestroyTimer. was the previous entry in this blog.

In response to @dhanji on unit testing is the next entry in this blog.

I usually write about C++ development on Windows platforms, but I often ramble on about other less technical stuff...

Find recent content on the main index or look in the archives to find all content.

I have other blogs...

Subscribe to feed The Server Framework - high performance server development
Subscribe to feed Lock Explorer - deadlock detection and multi-threaded performance tools
Subscribe to feed l'Hexapod - embedded electronics and robotics
Subscribe to feed MegèveSki - skiing