TIME_WAIT is the normal state a TCP connection sits in for a while after it closes, and CLOSE_WAIT means the other side has closed but the local program has not closed its socket yet. Thousands of either are a warning sign, not proof of a problem: Windows runs out of outbound ports (port exhaustion) only when one process opens connections faster than they are released, and new outbound connections start failing. Microsoft’s troubleshooting guide says to confirm the failures first, check the System log for Event IDs 4227 and 4231, then group connections by state and process to find the culprit. Port Detective Pro, a Windows app from Automata Labs, shows every TCP and UDP connection with its state and owning process, groups by process and exports the whole table, so the process holding thousands of TIME_WAIT sockets stands out in seconds.
This guide explains both states, the checks Microsoft recommends, the commands to run, and what actually fixes it.
See every connection’s state and owning process, grouped, without parsing netstat output.
Get it from Microsoft
What do TIME_WAIT and CLOSE_WAIT mean?
The TCP specification (RFC 9293) defines both:
| State | RFC 9293 definition | Plain meaning | Who is waiting |
|---|---|---|---|
| TIME-WAIT | ”waiting for enough time to pass to be sure the remote TCP peer received the acknowledgment of its connection termination request” | The connection is closed; the port is held briefly so late packets are not mistaken for a new connection | The side that closed first |
| CLOSE-WAIT | ”waiting for a connection termination request from the local user” | The remote side has closed; the local program still has the socket open | The local application |
On Windows, Microsoft’s port exhaustion troubleshooting guide says that after a session closes, “after a period of 4 minutes (default), the port used by the process or application would be released back to the available pool. During this 4 minutes, the TCP connection state will be TIME_WAIT state.”
The practical difference: TIME_WAIT clears itself with time; CLOSE_WAIT clears only when the program closes the socket. A growing pile of CLOSE_WAIT usually points at a bug in the application, such as a connection that is never disposed. Microsoft’s guide notes CLOSE_WAIT “doesn’t necessarily indicate port exhaustion”.
When does it become port exhaustion?
Each outbound TCP connection from a Windows machine uses a local port from the dynamic range. Microsoft’s guide gives the default: start port 49152, end port 65535, about 16,000 ports. If a process opens and closes connections fast enough that thousands sit in TIME_WAIT for their four minutes, or holds connections open and never closes them, the range can run out. Then new outbound connections fail even though the network is fine.
Microsoft is careful about the signs: “Having huge connections in TIME_WAIT state doesn’t always indicate that the server is currently out of ports,” but a lot of them “does indicate that the process is creating lot of TCP connections and may eventually lead to port exhaustion.”
How do you confirm port exhaustion on Windows?
Following Microsoft’s guide:
- Test outbound connections. Try to reach other machines: a remote share, RDP, or a connection to a known port. If every outbound connection fails while inbound works, keep going.
- Check the System event log in Event Viewer for Event ID 4227 and Event ID 4231, which indicate TCP/IP port problems.
- Check the dynamic port range, in case it was changed:
netsh int ipv4 show dynamicport tcp- Look for one process with a huge number of entries. On Windows 10 and later, netstat’s -q switch also shows ports that have moved out of TIME_WAIT into the BOUND state:
netstat -anobqRun it in an elevated prompt, because -b (the executable name) needs administrator rights.
How do you find which process is using all the ports?
Microsoft’s guide gives a PowerShell one-liner that groups every TCP connection by state and owning process and sorts the biggest groups first:
Get-NetTCPConnection | Group-Object -Property State, OwningProcess | Select -Property Count, Name, @{Name="ProcessName";Expression={(Get-Process -PID ($_.Name.Split(',')[-1].Trim(' '))).Name}}, Group | Sort Count -DescendingThe top rows show the state, the PID and the process name. One process with thousands of TimeWait or Bound entries is your suspect. If the count is spread across many processes, you are more likely looking at normal load.
To watch a single state, filter first:
Get-NetTCPConnection -State TimeWait | Group-Object OwningProcess | Sort Count -Descending | Select -First 10Note that a PID in TIME_WAIT can belong to a process that has already exited. Our guide to PID reuse and killing the wrong process explains why that matters before you act.
How does Port Detective show this?
Port Detective comes in two editions in the Microsoft Store. The free edition gives live tracking of TCP and UDP connections, instant lookup of a port’s process, PID and state, and pinned dev ports. The Store lists deep TCP states such as TIME_WAIT among the paid Power User features, and Port Detective Pro has every feature unlocked:
| Need | Port Detective Pro |
|---|---|
| See all states at once | Live table of every TCP and UDP connection, IPv4 and IPv6, with process, PID, executable path and state |
| Find the noisy process | Group by process, save filter presets, and keep the table responsive with thousands of connections |
| Act on it | One-click kill, guarded by a secure process token so a recycled PID is not killed by mistake; protected OS processes are flagged |
| Script it | Copy any row as a ready-to-run netstat, taskkill or PowerShell command |
| Keep evidence | Export a live timeline of ports opening, closing and changing owner, or the full network state, to CSV or JSON |
| Navigate fast | Ctrl+K command palette |
A port-exhaustion investigation is mostly a counting exercise, and grouping by process with the state column visible is the count. The CSV export is handy when you need to attach the evidence to a bug report for whoever owns the application. Our guide to exporting listening ports to CSV covers the export in more detail, and TCPView and CurrPorts alternatives compares other tools.
Group connections by process, spot the one in TIME_WAIT thousands of times, and export the evidence.
Get it from Microsoft
What actually fixes port exhaustion?
Microsoft’s guide is clear that widening the dynamic port range “is not a permanent solution but only temporary.” The fix is in the process that consumes the ports:
| Cause | Typical fix |
|---|---|
| A new HTTP connection for every request | Reuse connections: one shared client or connection pool instead of a new one per call |
| Connections never closed (CLOSE_WAIT grows) | Dispose sockets and clients in the application code; check error paths |
| A retry loop hammering a failing service | Add backoff and a retry limit |
| A legitimately high-volume service | Spread load, or as a stop-gap, widen the range with netsh while the real fix is made |
Restarting the offending process releases its ports immediately and buys time, but if the pattern is in the code, exhaustion returns.
What about local development?
On a developer machine the symptom is often different: a test suite or a dev server that opens many short-lived connections leaves thousands of TIME_WAIT entries, and a later “address already in use” error looks related. Usually it is a separate problem: a listening port is still owned by an old process. Our guide to finding the process using a port and the kill a process by port page cover that case.
Frequently asked questions
Is TIME_WAIT a problem?
Not by itself. It is a normal part of closing a TCP connection and clears after the timeout, four minutes by default per Microsoft. It becomes a problem only when one process creates so many that the dynamic port range runs out.
Why do I have so many CLOSE_WAIT connections?
The remote side closed those connections and the local program has not closed its end. That is almost always an application issue: sockets or clients that are not disposed. Restarting the program clears them until the code is fixed.
How many ephemeral ports does Windows have?
By default the dynamic range is 49152 to 65535, per Microsoft. Check yours with netsh int ipv4 show dynamicport tcp.
Can I just make the port range bigger?
You can with netsh, but Microsoft calls it a temporary measure. Find and fix the process that consumes the ports.
Does Port Detective need an internet connection?
No. Core features make no external network calls, and the Pro licence works offline.
Try Port Detective
Port Detective is free in the Microsoft Store for live tracking and port lookup. Port Detective Pro is a one-time purchase with every feature unlocked, including grouping, exports, Port Guard and copy-as-command. More detail is on the Port Detective product page.
Start with the free edition, and move to Pro when you need states, grouping and exports.
Get it from Microsoft
Windows and PowerShell are trademarks of the Microsoft group of companies. Port Detective is not affiliated with Microsoft.
Last updated 19 October 2026. Published by Automata Labs, a software company in Canada.