Windows TCP listener and process investigation cheat sheet
Map a TCP listener to its owning process and compare local binding with a remote connectivity test.
Windows PowerShell with the NetTCPIP module. Some process details require elevated read privileges.
Updated · Windows · 6 min read
| Command | What it does |
|---|---|
Get-NetTCPConnection -State Listen | List TCP listeners |
Get-NetTCPConnection -LocalPort 443 -State Listen | Inspect the service port |
Get-NetTCPConnection -LocalPort 443 -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess | Capture listener address and process ID |
Get-Process -Id 1234 | Identify the process owning the listener |
Get-NetTCPConnection -State Established | Inspect current established TCP connections |
Test-NetConnection server.example.com -Port 443 -InformationLevel Detailed | Test TCP from an affected client |
Walkthrough
Replace port 443 and server.example.com with the approved service. Run listener checks on the server and the TCP probe on an authorized client; the probe sends traffic.
Step 1: List TCP listeners
Get-NetTCPConnection -State Listen
Inspect local addresses, local ports and owning PIDs. A listener on loopback is not a listener on every interface. The command is a point-in-time view and does not list UDP sockets.
Step 2: Inspect the service port
Get-NetTCPConnection -LocalPort 443 -State Listen
Replace 443 with the intended TCP port and compare the binding with the service design. No result can mean the process is not listening at that moment or that the wrong port was inspected.
Step 3: Capture listener address and process ID
Get-NetTCPConnection -LocalPort 443 -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess
Record the exact PID and address for the incident. An address of 127.0.0.1 is local-only; an all-interface binding is still subject to host and network policy.
Step 4: Identify the process owning the listener
Get-Process -Id 1234
Replace 1234 with the PID from the previous result. A PID can be reused after a process exits, so collect both observations close together and confirm the application owner.
Step 5: Inspect current established TCP connections
Get-NetTCPConnection -State Established
Compare local and remote endpoints with a known healthy baseline. Existing established connections do not establish that new clients can connect or that application authentication succeeds.
Step 6: Test TCP from an affected client
Test-NetConnection server.example.com -Port 443 -InformationLevel Detailed
Run from the client network and inspect TcpTestSucceeded, source address and interface. A successful TCP handshake does not validate HTTP, TLS certificates or user authorization.
WORKED INCIDENT
Practical case: A web service works locally but remote users time out
Fictional teaching scenario; observations are examples, not captured production output.
Situation
A Windows-hosted web service answers on the server itself but clients cannot connect.
Investigation sequence
1. Inspect the service port
Get-NetTCPConnection -LocalPort 443 -State ListenCheck the expected listener on the server and record the port.
2. Capture listener address and process ID
Get-NetTCPConnection -LocalPort 443 -State Listen | Select-Object LocalAddress,LocalPort,OwningProcessInspect the local bind address and PID for that listener.
3. Identify the process owning the listener
Get-Process -Id 1234Match the PID to the expected application process and confirm that it has not restarted between observations.
4. Test TCP from an affected client
Test-NetConnection server.example.com -Port 443 -InformationLevel DetailedRun the same TCP port test from an authorized affected client.
Example findings
Illustrative findings: the expected process listens only on 127.0.0.1:443, while a remote client TCP test fails.
Interpret the findings
The loopback-only binding is a supported explanation for remote connectivity failure. Check the application’s intended exposure and firewall path before changing any setting.
Verify the outcome
After an approved binding correction, repeat the listener and client TCP checks, then verify the normal application and TLS flow.
Escalation handoff
Share server identity, bind address, process ID, client source and test timestamps with the application owner.