{"id":98,"date":"2026-07-09T09:00:00","date_gmt":"2026-07-09T09:00:00","guid":{"rendered":"https:\/\/backendside.com\/blog\/2026\/07\/09\/map-processes-open-connections-windows-server\/"},"modified":"2026-07-09T09:00:00","modified_gmt":"2026-07-09T09:00:00","slug":"map-processes-open-connections-windows-server","status":"publish","type":"post","link":"https:\/\/backendside.com\/blog\/2026\/07\/09\/map-processes-open-connections-windows-server\/","title":{"rendered":"Which Process Owns That Port? Mapping Connections to Processes on a Windows Server"},"content":{"rendered":"

You run a quick scan and there it is: something is listening on port 8443, or an outbound connection keeps reaching a remote address you do not recognise. The port is easy to see. The hard question is always the same one — which process opened it?<\/em> On Windows, every socket is owned by a process, and every process has a PID. Mapping a connection back to that PID, and then to a real executable on disk, is the core skill behind server monitoring, incident response and network debugging. This guide walks through every reliable way to do it.<\/p>\n

The one number that ties it all together: the PID<\/h2>\n

A TCP or UDP endpoint on Windows is never anonymous. The kernel records the owning process ID (PID)<\/strong> for every connection and every listening socket. So the job is really two lookups:<\/p>\n

    \n
  1. Port → PID<\/strong> — find which process ID owns the port or connection.<\/li>\n
  2. PID → process<\/strong> — turn that number into a name and, ideally, a full path on disk so you know exactly what is running.<\/li>\n<\/ol>\n

    Do both and the mystery is solved. Let us do it manually first, so you understand what is happening, and then with a tool that collapses both steps into one live view.<\/p>\n

    Step 1 — Map the port to a PID with netstat<\/code><\/h2>\n

    The classic tool is netstat<\/code>. The flags that matter are -a<\/code> (all connections and listening ports), -n<\/code> (numeric — do not resolve names, which is much faster), and crucially -o<\/code> (show the owning PID). Open an Administrator<\/strong> command prompt or PowerShell and run:<\/p>\n

    netstat -ano<\/code><\/pre>\n
    Every row ends with a PID in the last column. A typical listening line looks like this:<\/p>\n
      Proto  Local Address        Foreign Address      State        PID\n  TCP    0.0.0.0:8443         0.0.0.0:0            LISTENING    5240\n  TCP    10.0.0.12:52210      93.184.216.34:443    ESTABLISHED  7864<\/code><\/pre>\n
    Now narrow it to the port you care about. On Windows, findstr<\/code> is the filter of choice:<\/p>\n
    netstat -ano | findstr :8443\nnetstat -ano | findstr LISTENING\nnetstat -ano | findstr ESTABLISHED<\/code><\/pre>\n
    The first line shows only rows touching port 8443; the others let you see just the listeners, or just the live established sessions. In the example above, port 8443 is owned by PID 5240<\/strong>. That is half the puzzle.<\/p>\n
    Step 2 — Turn the PID into a process name with tasklist<\/code><\/h2>\n
    A bare number is not much use, so map it to a process. tasklist<\/code> with a PID filter does exactly that:<\/p>\n
    tasklist \/FI \"PID eq 5240\"<\/code><\/pre>\n
    Image Name          PID  Session Name    Session#   Mem Usage\n=================== ==== =============== ========== ============\njava.exe           5240  Services              0     412,880 K<\/code><\/pre>\n
    If the PID turns out to be a svchost.exe<\/code> — the shared host for Windows services — the name alone will not tell you which service is responsible. Add \/svc<\/code> to expand it:<\/p>\n
    tasklist \/svc \/FI \"PID eq 5240\"<\/code><\/pre>\n
    That lists every service hosted inside the PID, so you can tell whether it is the DNS Client, the Web Deploy agent, or something you did not expect.<\/p>\n
    The one-shot shortcut: netstat -anob<\/code><\/h2>\n
    You can skip the two-step dance and ask netstat<\/code> to print the owning executable directly with the -b<\/code> flag:<\/p>\n
    netstat -anob<\/code><\/pre>\n
    This shows the process name (and sometimes the component that requested the connection) under each row. It is handy, but it comes with two real costs: it requires Administrator rights<\/strong>, and it is noticeably slow<\/strong> — enumerating the executable for every socket can take many seconds on a busy server, and the output is verbose and awkward to scan. It is a good spot-check, not something you want to run in a tight loop.<\/p>\n
    The PowerShell way — and why it is nicer<\/h2>\n
    On any modern Windows Server, PowerShell gives you the same mapping as structured objects you can filter and sort. Get-NetTCPConnection<\/code> already includes the OwningProcess<\/code> (the PID), so you can go straight from a port to the process in a single pipeline:<\/p>\n
    # Which process is listening on port 8443?\nGet-Process -Id (Get-NetTCPConnection -LocalPort 8443 -State Listen).OwningProcess<\/code><\/pre>\n
    That prints the process name, and because it is a real process object you also get the path via .Path<\/code>. To see the connection and its owner side by side, join the two yourself:<\/p>\n
    Get-NetTCPConnection -State Listen |\n  Select-Object LocalAddress, LocalPort, State, OwningProcess,\n    @{Name='Process'; Expression={ (Get-Process -Id $_.OwningProcess).Name }},\n    @{Name='Path';    Expression={ (Get-Process -Id $_.OwningProcess).Path }} |\n  Sort-Object LocalPort | Format-Table -AutoSize<\/code><\/pre>\n
    UDP listeners work the same way through Get-NetUDPEndpoint<\/code>. This is far more pleasant than parsing netstat<\/code> text, and it is scriptable — but you are still hand-writing calculated properties every time, and each snapshot is frozen the instant it runs.<\/p>\n
    Where the manual approach starts to hurt<\/h2>\n
    These commands all work, and every Windows admin should know them. But on a live server the friction adds up:<\/p>\n