A server refuses to start because port 8080 is taken, and the error names nothing useful. Three commands map the port to a process, and one more tells you whether Windows reserved it.
List listeners with **Get-NetTCPConnection -State Listen**, map the **OwningProcess** to a program, and check **netsh int ipv4 show excludedportrange** before you fight a port Windows reserved.
**Get-NetTCPConnection** shows the local address, the port and the owning PID. Filter by state first, because a port in TIME_WAIT is not the same problem as a listener.
Get-NetTCPConnection -State Listen | Sort-Object LocalPort |
Select-Object LocalAddress,LocalPort,OwningProcess | Format-Table -AutoSizeDNS, game servers and discovery services listen on UDP, which the TCP table does not show. Checking only TCP is why some ports look free and still fail.
Get-NetUDPEndpoint | Sort-Object LocalPort | Select-Object LocalAddress,LocalPort,OwningProcess | Format-Table -AutoSize
netstat -ano | findstr :8080**Get-Process** names the executable and its publisher. An empty Path means a SYSTEM process; run the query elevated to see it.
Get-Process -Id 4032 | Select-Object Id,ProcessName,Path,Company,StartTime
Get-CimInstance Win32_Service | Where-Object ProcessId -eq 4032 | Select-Object Name,DisplayName,StartModeHyper-V, Docker and WSL ask Windows to reserve port ranges. Reserved ports are invisible in the connection table and produce an access-denied error for every app that tries them.
netsh int ipv4 show excludedportrange protocol=tcp
netsh int ipv4 show excludedportrange protocol=udpStop the service when there is one; killing the process only works until its watchdog restarts it. Reserve the fact that PID 4 is the kernel — http.sys holds those ports for other services.
Get-CimInstance Win32_Service | Where-Object { $_.Name -match 'MyApp' } | Select-Object Name,State
Stop-Service -Name MyApp -Force
net stop winnat
net start winnatListen on it from PowerShell instead of starting the whole application. A successful bind is proof; a connection refusal proves nothing.
$l = [System.Net.Sockets.TcpListener]::new([System.Net.IPAddress]::Any, 8080)
$l.Start(); $l.Stop(); 'port free'
Test-NetConnection localhost -Port 8080 -InformationLevel QuietA kernel driver or the HTTP stack holds it. Query with netsh http show servicestate to see which registered URL uses the port, then reconfigure that service.
Either the app lacks permission for a port below 1024 in that context, or the exclusion table blocks it. Check both, and test a port above 8000.
A service, a scheduled task or a watchdog restarts it. Disable the parent or change its configuration; killing is not a fix.
You are not elevated, or the connection is in a state without a live process. Run as administrator and check TIME_WAIT entries separately.
For a stray dev server, yes. For anything running as a service, stop the service so its state is written correctly.
TIME_WAIT entries expire and dynamic reservations are recalculated at boot. A port that frees itself after a restart was never held by a program.
Nothing to undo. Start the service you stopped with Start-Service, and if you restarted winnat, the containers or VMs reconnect on their own.
Free · no account needed · tracks your progress