Find which Windows process owns a port or a connection

A service refuses to start because “the port is already in use”. A firewall log shows a workstation making outbound connections to an address nobody recognises. A user swears nothing is uploading, yet the uplink graph disagrees. Each of these tickets comes down to one question: which process on this Windows machine owns that socket? Windows gives you several ways to answer it, and the Sysinternals tool TCPView gives you the most readable one. This guide covers all of them, because on a locked-down server you may only have the built-in tools.

Option A: TCPView (GUI)

TCPView is a free Microsoft Sysinternals utility that lists every TCP and UDP endpoint with its owning process, including the service name where one applies. It runs on Windows 8.1 / Server 2012 and newer, needs no installation, and ships with a command-line twin, Tcpvcon.

Get TCPView from Microsoft’s Sysinternals site (it’s also part of the Sysinternals Suite). Check the file’s digital signature is Microsoft’s before running it — see where to get tools safely.
Run it elevated (right-click → Run as administrator). Without elevation, you may not see process details for endpoints owned by other users or by services.
Use the filter box to type the port number, such as 8080, or the remote address you’re chasing.
Read the Process and PID columns. For services hosted in svchost.exe, TCPView also shows the service name, which is usually what you actually need.
Watch the colours. By default TCPView refreshes every second: new endpoints flash green, closing ones red, and changed ones yellow. For a connection that lives only a few seconds, this is often the only way to catch it. You can change the refresh rate under Options.
If you need to stop an established connection for testing, right-click it and choose Close Connection. This only works for TCP connections in the ESTABLISHED state, and the application may simply reconnect. You can also end the owning process from the same menu — be careful on servers.
Use Save to write the current table to a text file for the ticket.

Option B: Tcpvcon (command line)

Tcpvcon is included in the TCPView package. Its syntax is close to netstat:

tcpvcon [-a] [-c] [-n] [process name or PID]

-a shows all endpoints (the default is established TCP connections only),
-c prints CSV,
-n skips name resolution.

# every endpoint for one process, as CSV, no DNS lookups
tcpvcon -a -c -n sqlservr.exe > sql-endpoints.csv

That CSV is handy when you need to prove to an application owner which ports their process holds.

Option C: netstat (always available)

# who is listening on or connected to port 8080?
netstat -ano | findstr :8080

The last column is the PID. Match it to a process:

tasklist /FI "PID eq 4312"
# for svchost PIDs, list the services inside
tasklist /svc /FI "PID eq 4312"

netstat -b shows the executable name directly, but it needs an elevated prompt and is slow on busy machines.

Option D: PowerShell

PowerShell’s networking cmdlets return objects, which makes them better for scripts and remote checks:

# listening TCP port -> process
Get-NetTCPConnection -LocalPort 8080 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess,
    @{n='Process';e={(Get-Process -Id $_.OwningProcess).ProcessName}}

# all established connections to a suspicious remote address
Get-NetTCPConnection -RemoteAddress 203.0.113.50 |
  Select-Object LocalPort, RemotePort, State, OwningProcess

# UDP has no state, so use the endpoint cmdlet
Get-NetUDPEndpoint -LocalPort 5353 | Select-Object LocalAddress, OwningProcess

Run the same thing against a remote server over PowerShell remoting with Invoke-Command -ComputerName SRV01 -ScriptBlock { ... }, provided WinRM is enabled and you’re authorised to administer it.

Special cases worth knowing

PID 4 (“System”) owning port 80, 443 or 5985 usually means the kernel HTTP.sys listener — IIS, WinRM, or another HTTP.sys-based component registered a URL on it. TCPView will show “System”; to see which URL is registered, use:
```
netsh http show servicestate
```
svchost.exe hosts many services. The service name in TCPView, or tasklist /svc, tells you which one.
Ports held with no process (“[System Process]” or an unknown PID) are often connections in TIME_WAIT after the process has exited. They clear on their own.
Excluded port ranges. Hyper-V, WSL and Docker can reserve blocks of ports that no process “owns”, so a service fails to bind even though nothing shows up. Check with:
```
netsh interface ipv4 show excludedportrange protocol=tcp
```

Common mistakes

Running non-elevated. You’ll see ports but not always the owning process details.
Trusting the process name alone. Malware likes names like svchost.exe. Check the path (Process Explorer or Get-Process -Id <pid> | Select Path) and the signature.
Killing the process on a production server to free a port without knowing what it is. Identify first; stop the service properly.
Forgetting IPv6. A service can be listening on [::]:8080 while you search only for 0.0.0.0:8080.
Chasing a one-second connection with netstat. Use TCPView’s live highlighting or a loop in PowerShell; a single snapshot will miss it.

When a process view isn’t enough

TCPView tells you who is talking and to whom, not what they are saying. When you need payload, timing, or protocol errors, move to a capture with Wireshark; the trade-offs are laid out in Wireshark vs TCPView. For more on TCPView itself, read the TCPView review, and browse related tools under Host & Connection Checks and Throughput & Packet Inspection.