A message saying a port is already in use usually means another program is using the network port your app needs. To resolve the conflict, find a port owner, confirm what the process does, and then decide whether to stop it or configure your app to use another port.
Windows includes built-in tools for checking TCP and UDP ports. PowerShell can connect a port number to a process ID, while Command Prompt and Task Manager offer useful alternatives. These steps can help when a local development server will not start, a service fails to bind, or an application reports that a port is occupied.
How to find a port owner with PowerShell
Start with PowerShell if you know the port number. You can usually inspect your own processes without administrator access. Elevated access may be needed to see details about processes owned by other accounts.
- Right-click Start and open Terminal or Windows PowerShell.
- Replace 3000 in this command with the port you want to check.
Get-NetTCPConnection -LocalPort 3000 -State Listen
The output can include the local address, local port, connection state, and OwningProcess. That last value is the process ID, or PID. A row with Listen in the state column means a process is waiting for connections on that TCP port.
Use the PID to identify the program. Replace 1234 with the number shown in your output:
Get-Process -Id 1234
To display the port and process details together, run:
$connection = Get-NetTCPConnection -LocalPort 3000 -State Listen
$connection | Select-Object LocalAddress, LocalPort, State, OwningProcess
Get-Process -Id $connection.OwningProcess
If the command returns multiple rows, check each local address and PID. A program may listen on both IPv4 and IPv6 addresses, or more than one process may be involved in a complex setup. Repeated rows do not automatically indicate a problem. Pay attention to the address as well as the port, since an app may be bound to one interface rather than every interface.
List listening ports when you do not know the number
If an app’s error message does not name the port, check its settings, configuration file, or startup output. Many development tools print the local address and port when they start. The app’s documentation may also explain where its port is configured. Once you have the number, search for it directly.
You can list TCP connections in the listening state and sort them by port:
Get-NetTCPConnection -State Listen | Sort-Object LocalPort | Format-Table LocalAddress, LocalPort, OwningProcess
Note a row’s PID and run Get-Process -Id 1234, replacing 1234 with the number. To display process names alongside the port details, use:
Get-NetTCPConnection -State Listen | ForEach-Object {
$process = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
[pscustomobject]@{
Address = $_.LocalAddress
Port = $_.LocalPort
PID = $_.OwningProcess
Process = $process.ProcessName
}
} | Sort-Object Port
You may see repeated entries when a process listens on multiple addresses. A process name may also be missing if your account cannot access its details or if the process ended between commands. Reopen Terminal as an administrator and repeat the check if you need to inspect a process owned by another account.
Use netstat and Task Manager as alternatives
The Command Prompt netstat command is useful when PowerShell’s networking commands are unavailable or a troubleshooting guide calls for it. Open Command Prompt or Terminal and run:
netstat -aon
The output includes the local address, foreign address, state, and PID. Look for a local address ending in the port number you are checking and a state of LISTENING. For example, a local address ending in :3000 indicates port 3000. The final column contains the PID.
To filter the output for a specific port, run:
netstat -aon | findstr :3000
Check the results carefully. The port number may appear in a foreign address as well as a local address, and a matching line does not always mean a program is listening on that local port. Confirm the local address and state before taking action. If the output is long, you can use the filtered command first, then compare its columns with the full output when the match is unclear.
Match the PID to a process in Task Manager:
- Open Task Manager with Ctrl+Shift+Esc.
- Select Details. If the tab is hidden, choose More details.
- Find the PID column. If it is not visible, right-click a column heading, choose Select columns, and enable PID.
- Match the PID from netstat to the process in the list.
Or look up the PID in Command Prompt by replacing 1234 with the number from the output:
tasklist /FI “PID eq 1234”
Task Manager’s process name can help you recognize an application, but it may not show why the program is running. Check the process properties or the application’s usual startup method before deciding to close it.
Check UDP ports separately
TCP and UDP are different network protocols, so a TCP check will not identify a process using a UDP port. If the application reports a UDP port conflict, inspect UDP endpoints in PowerShell:
Get-NetUDPEndpoint -LocalPort 5353
Replace 5353 with the port you are checking. If the output includes an OwningProcess value, look up that PID with Get-Process -Id 1234, replacing 1234 with the actual number. UDP does not use TCP connection states, so you will not see the Listen state shown in the TCP examples.
If the command returns no results, double-check the port number and protocol. Some error messages mention a port without making it clear whether the app is trying to use TCP or UDP. You can also confirm the protocol in the app’s configuration or documentation before changing anything.
Choose a safe fix after identifying the process
Finding the process is only the first step. Before stopping anything, check whether it belongs to an app you recognize, a background service, or a tool you still need. Another local server may be using the port intentionally, and stopping it could interrupt work that depends on it.
- Close an app you started. Stop it through its own window or terminal when possible. For a development server, use its normal stop command or close the terminal session that launched it.
- Change your app’s port. If you need both programs, configure the new app to use another available port. Update any matching browser address, local client, or configuration setting so those tools connect to the new port.
- Restart a service carefully. Identify the service before changing it. To search for a Windows service by PID in PowerShell, run Get-CimInstance Win32_Service | Where-Object ProcessId -eq 1234 | Select-Object Name, DisplayName, State, replacing 1234 with the actual PID.
- Investigate unfamiliar processes. Check the executable name and, when available, its location and publisher. A familiar-looking process name alone does not prove that it is safe to terminate.
Avoid ending an unknown process just because it owns the port. Some Windows services share a host process, and force-closing it can interrupt unrelated functions or cause errors. If you do not recognize the process, ask your administrator before stopping it. When the process is a service, using its service controls is generally safer than terminating the process directly.
What to do when the port check shows nothing
An empty result does not always mean the application is mistaken. Confirm the port number, whether the app uses TCP or UDP, and whether it is running in the same Windows environment you are checking. A port used inside a virtual machine, container, or remote computer may not appear as a local Windows listener in the way you expect.
The conflicting process may also have exited since the error occurred. Run the command again while the error is present. If the app says it cannot bind to an address, the issue may involve that specific address rather than every network interface. Compare the address in the error with the local address shown by PowerShell.
Also check whether the application is already listening under a different account or launched with elevated permissions. In that case, an ordinary terminal may not reveal all the process details. Open an elevated Terminal only when you have permission to do so, then repeat the query and compare the PID and address.
Once you know the PID and process name, you can make a targeted change instead of guessing or rebooting. Start with PowerShell for a TCP check, use netstat as another view, and treat unfamiliar system processes with care.