Introduction

On Windows, the normal workflow is simple: find the port, read the owning PID, then map that PID to a process name. You can do that with built-in tools such as netstat, PowerShell networking cmdlets, or graphical tools like Resource Monitor and TCPView.

Command Prompt: netstat Plus tasklist

The most portable answer is still netstat, because it is present on almost every Windows machine. To check TCP port 8080, run:

netstat -aon -p tcp | findstr :8080

Typical output looks like this:

TCP    0.0.0.0:8080      0.0.0.0:0      LISTENING      1234
TCP    [::]:8080         [::]:0         LISTENING      1234

The last column is the PID. Once you have it, ask Windows which process owns it:

tasklist /FI "PID eq 1234"

That returns the executable name for the process. For many troubleshooting sessions, that two-step flow is enough.

UDP Looks Different

A common point of confusion is that UDP does not show LISTENING the way TCP does. UDP is connectionless, so you usually just look for the bound local port:

netstat -aon -p udp | findstr :5353

You still get a PID in the final column, and you can still use tasklist to identify the process. The absence of the word LISTENING does not mean the UDP port is unused.

PowerShell Is Cleaner for Automation

If you are already in PowerShell, the networking cmdlets are usually easier to read than parsing netstat output.

For TCP:

$conn = Get-NetTCPConnection -LocalPort 8080 -State Listen
Get-Process -Id $conn.OwningProcess

For UDP:

$endpoint = Get-NetUDPEndpoint -LocalPort 5353
Get-Process -Id $endpoint.OwningProcess

This is especially useful when you need to fold the check into a script, a deployment step, or a troubleshooting runbook.

You can also print only the fields you care about:

Get-NetTCPConnection -State Listen |
    Where-Object LocalPort -eq 8080 |
    Select-Object LocalAddress, LocalPort, OwningProcess

Graphical Options

If you prefer a UI, Windows already ships one useful option and there is also a popular Sysinternals tool.

Resource Monitor

1. Press Win + R
2. Run resmon
3. Open the Network tab
4. Expand Listening Ports
5. Locate the port and read the image name and PID

TCPView

TCPView from Sysinternals gives you a live process-to-port view with filtering and sorting. It is often faster than raw command output when you are interactively hunting for a conflict.

Services and Shared Host Processes

Sometimes the process you find is svchost.exe or another shared host. In that case, the port is owned by that host process, but the real answer you care about may be the Windows service running inside it.

If you hit that situation, follow up with:

Get-Process -Id 1234 | Select-Object Id, ProcessName
Get-Service | Where-Object Status -eq Running

Or inspect the Services tab in Task Manager for that PID. The port owner and the service name are related, but not always identical.

Administrator Rights Can Matter

On some systems, especially when services or protected processes are involved, a normal shell may not show everything clearly. If the output seems incomplete or inconsistent, rerun Command Prompt or PowerShell as Administrator.

That is not always necessary, but it avoids a lot of false conclusions during production debugging.

Common Pitfalls

• Forgetting the -o flag in netstat removes the PID, which makes the result much less useful.
• Searching for :80 too loosely can also match :8080 or similar ports, so inspect the whole row carefully.
• Expecting UDP to show LISTENING leads to wrong conclusions about whether the port is active.
• Stopping at svchost.exe can be misleading because the actual service may still need to be identified.
• Running without elevation can hide or limit results on some systems.

Summary

• On Windows, the standard method is port to PID, then PID to process name.
• 'netstat -aon with tasklist works almost everywhere.'
• PowerShell cmdlets such as Get-NetTCPConnection and Get-NetUDPEndpoint are cleaner for scripts.
• TCP usually shows LISTENING; UDP usually does not.
• If the result points to a shared host process, inspect the underlying service as the next step.