Network "Waiting Connections"

[stdedos]

Hello there! I have been seeing a "variable number" of

that just seem to pile up. I am wondering:

1. Who opened them? wininit.exe, System, etc all own connections. Who is that "Waiting Connections" that has no PID?
2. They mostly seem to be opened, rather than garbage collected. Could it be a bug?

[AltF5]

I believe it’s something to do in the Kernel. Does TCPView show similar?

These’s also a NirSoft tool out there too that does similar

[stdedos]

Yeah; they are called [ Time Wait ]. No more info 😕

[stdedos]

Nirsoft's LiveTcpUdpWatch attributes them to C:\ProgramData\Battle.net\Agent\Agent.7866\Agent.exe

[DavidXanatos]

These are connections that have been closed usually but where the close acknowledge packet wasn't received yet, they are attributed to system as the opening process usually discards the connection after close and does not wait for the ACK.

[stdedos]

I guess there isn't a way to flush those connections?

• There's a "glitch" in another networking software that I'd like to diagnose, and I am thinking it this behavior
• A lot of those connections are opened from/to localhost, and I actually see them created in SI (in addition to those that are timing out / removed)

[dmex]

@stdedos

The default timeout is +120 seconds and Microsoft recommended changing the value to 30. See the TcpTimedWaitDelay docs here:
https://learn.microsoft.com/en-us/biztalk/technical-guides/settings-that-can-be-modified-to-improve-network-performance

[dmex]

Who is that "Waiting Connections" that has no PID?

The kernel doesn't return PIDs for waiting connections.

They mostly seem to be opened, rather than garbage collected. Could it be a bug?

Waiting connections are in a closed state. It could be a driver issue or ISP/network issue dropping ACK packets before they're received.