Introduction

On Windows, finding which process is using a specific port is a two-step operation: find the port to get the owning PID, then map that PID to a process name. You can do this with built-in command-line tools (netstat, tasklist), PowerShell cmdlets (Get-NetTCPConnection, Get-NetUDPEndpoint), or graphical utilities like Resource Monitor and Sysinternals TCPView.

The most common scenario is a "port already in use" error when starting a development server, and the steps below resolve it in under a minute.

Method 1: Command Prompt with netstat and tasklist

The most portable approach uses netstat, which is available on every Windows version. To find what is listening on TCP port 8080:

netstat -aon -p tcp | findstr :8080

Typical output:

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

The flags explained:

The last column (12456) is the PID. To find the process name:

tasklist /FI "PID eq 12456"

Output:

Image Name                     PID Session Name        Mem Usage
========================= ======== ================ ============
node.exe                     12456 Console            85,432 K

Now you know node.exe (PID 12456) is listening on port 8080.

One-Liner Approach

For a faster workflow, chain the commands:

for /f "tokens=5" %a in ('netstat -aon -p tcp ^| findstr :8080 ^| findstr LISTENING') do @tasklist /FI "PID eq %a" /NH

This extracts the PID from netstat output and passes it directly to tasklist. In a batch file, double the % signs:

for /f "tokens=5" %%a in ('netstat -aon -p tcp ^| findstr :8080 ^| findstr LISTENING') do @tasklist /FI "PID eq %%a" /NH

Method 2: PowerShell (Recommended for Scripting)

PowerShell provides structured objects instead of text parsing, making it more reliable for automation.

Finding a TCP Port Owner

Get-NetTCPConnection -LocalPort 8080 -State Listen |
    Select-Object LocalAddress, LocalPort, OwningProcess,
        @{Name='ProcessName'; Expression={(Get-Process -Id $_.OwningProcess).ProcessName}}

Sample output:

1LocalAddress LocalPort OwningProcess ProcessName
2------------ --------- ------------- -----------
3::           8080      12456         node
40.0.0.0      8080      12456         node

Finding a UDP Port Owner

UDP is connectionless, so there is no LISTENING state. Instead, query bound endpoints:

Get-NetUDPEndpoint -LocalPort 5353 |
    Select-Object LocalAddress, LocalPort, OwningProcess,
        @{Name='ProcessName'; Expression={(Get-Process -Id $_.OwningProcess).ProcessName}}

Scanning All Listening Ports

To see every listening port and its owner:

1Get-NetTCPConnection -State Listen |
2    Sort-Object LocalPort |
3    Select-Object LocalPort, OwningProcess,
4        @{Name='ProcessName'; Expression={(Get-Process -Id $_.OwningProcess).ProcessName}} |
5    Format-Table -AutoSize

Killing the Process from PowerShell

Once you have the PID, you can stop the process directly:

1# Check what you are about to stop
2Get-Process -Id 12456
3
4# Stop it
5Stop-Process -Id 12456 -Force

Or as a combined one-liner:

Get-NetTCPConnection -LocalPort 8080 -State Listen |
    ForEach-Object { Stop-Process -Id $_.OwningProcess -Force }

Be cautious with this, especially on production systems. Always confirm the process name before killing it.

Method 3: Graphical Tools

Resource Monitor (Built-in)

1. Press Win + R, type resmon, and press Enter
2. Navigate to the Network tab
3. Expand the Listening Ports section
4. Find your port number and read the associated image name and PID

Resource Monitor also shows network activity per process, which is useful when you need more context than just the port binding.

TCPView (Sysinternals)

TCPView from Microsoft's Sysinternals suite provides a live, sortable view of all TCP and UDP endpoints on the system. It updates in real time and lets you close connections or kill processes from the UI.

Download it from the Sysinternals website or install it via winget:

winget install Microsoft.Sysinternals.TCPView

TCPView is particularly useful when you are investigating port conflicts interactively, since you can sort by port number and immediately see all owners.

Handling svchost.exe Results

Sometimes the process that owns the port is svchost.exe, which is a generic host for Windows services. Multiple services can run inside a single svchost.exe instance, so the PID alone does not tell you which service is responsible.

To identify the specific service:

# Find services running in a specific svchost instance
Get-WmiObject Win32_Service | Where-Object { $_.ProcessId -eq 12456 } |
    Select-Object Name, DisplayName, State

Or from the command prompt:

tasklist /SVC /FI "PID eq 12456"

This lists the Windows services hosted by that PID. Common examples include:

TCP vs UDP: Key Differences in Output

The absence of LISTENING in UDP output does not mean the port is unused. It means UDP does not have a connection state. If netstat shows a UDP row with your port number, something is bound to it.

Administrator Privileges

Some system processes and services require elevated privileges to inspect. If your output seems incomplete or the PID column shows 0 or blank values:

1# Run Command Prompt as Administrator
2# Right-click CMD > Run as administrator
3
4netstat -aon -p tcp | findstr :443

In PowerShell, launch an elevated session:

Start-Process powershell -Verb RunAs

Running as Administrator is not always necessary, but it prevents false negatives that can waste significant debugging time.

Quick Reference: Common Scenarios

1:: Find what is using port 3000 (typical React dev server)
2netstat -aon -p tcp | findstr :3000
3
4:: Find what is using port 5432 (PostgreSQL)
5netstat -aon -p tcp | findstr :5432
6
7:: Check if port 443 is in use (HTTPS)
8netstat -aon -p tcp | findstr :443
9
10:: Find all listening ports
11netstat -aon -p tcp | findstr LISTENING

1# PowerShell equivalents
2Get-NetTCPConnection -LocalPort 3000 -State Listen
3Get-NetTCPConnection -LocalPort 5432 -State Listen
4Get-NetTCPConnection -LocalPort 443 -State Listen
5Get-NetTCPConnection -State Listen | Sort-Object LocalPort

Common Pitfalls

Forgetting the -o flag in netstat removes the PID column from the output, making it impossible to identify the process. Always include -o.

Searching for :80 without anchoring matches :8080, :8000, :80 and other ports that contain the sequence 80. Use findstr " :80 " with spaces or findstr /R ":80[^0-9]" for more precise matching.

Expecting UDP ports to show LISTENING leads to the wrong conclusion that the port is free. UDP is stateless, so the bound port shows without any state label.

Stopping at svchost.exe without investigating the underlying service leaves you without actionable information. Use tasklist /SVC or Get-WmiObject Win32_Service to dig deeper.

Running without Administrator privileges can hide system-owned ports. If your results look incomplete, rerun the command in an elevated prompt.

Confusing netstat syntax across operating systems causes errors. On Linux, netstat uses -tulpn, while on Windows it uses -aon -p tcp. The flags are not interchangeable.

Summary

• The standard Windows workflow is: find the port (get the PID), then map the PID to a process name.
• 'netstat -aon with findstr and tasklist works on every Windows version.'
• PowerShell cmdlets (Get-NetTCPConnection, Get-NetUDPEndpoint) return structured objects and are better for scripting.
• TCP shows LISTENING state; UDP does not, but the port is still in use if it appears in the output.
• If the result is svchost.exe, investigate the specific Windows service running inside it.
• Run as Administrator when results seem incomplete or the system port range is involved.
• Use Resource Monitor or TCPView for interactive investigation.