The knowledge base / All cheat sheets
● Always in your toolkitAbout the project ↗

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

CommandWhat it does
Get-NetTCPConnection -State ListenList TCP listeners
Get-NetTCPConnection -LocalPort 443 -State ListenInspect the service port
Get-NetTCPConnection -LocalPort 443 -State Listen | Select-Object LocalAddress,LocalPort,OwningProcessCapture listener address and process ID
Get-Process -Id 1234Identify the process owning the listener
Get-NetTCPConnection -State EstablishedInspect current established TCP connections
Test-NetConnection server.example.com -Port 443 -InformationLevel DetailedTest 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 Listen

Check 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,OwningProcess

Inspect the local bind address and PID for that listener.

3. Identify the process owning the listener

Get-Process -Id 1234

Match 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 Detailed

Run 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.

Microsoft Get-NetTCPConnection

Microsoft Test-NetConnection

Microsoft Get-NetTCPConnection