Windows: Only one usage of each socket address (WSAEADDRINUSE 10048)

Hi, it's BlueByte. You start a service and it dies immediately with Only one usage of each socket address (protocol/network address/port) is normally permitted. Nothing is wrong with your code — another socket already owns the port you asked for, and Windows refuses the second bind. The symptom is a startup failure carrying error 10048 (WSAEADDRINUSE), or the .NET form SocketException (10048). We'll walk through what the message means, why the port is taken, how to find and free it, verify, and keep it from clashing again.

What error 10048 is telling you

10048 is the Winsock error WSAEADDRINUSE, and Microsoft's docs describe it plainly as "Address already in use ... Typically, only one usage of each socket address (protocol/IP address/port) is permitted." It shows up in a few shapes depending on the stack:

System.Net.Sockets.SocketException (10048): Only one usage of each socket
address (protocol/network address/port) is normally permitted.

A native Win32 app fails at the bind() call; a .NET app throws SocketException with ErrorCode 10048; IIS or Kestrel logs the same 10048. The constant across all of them: a socket tried to bind to an IP and port that another socket already holds. Your program is fine — the port isn't free.

Why the port is already taken

The bind fails for one of a few reasons:

• Another program is already listening on that port — a second copy of your own service, or a different app that grabbed it first.
• A previous instance is still shutting down. A closed TCP connection sits in TIME_WAIT for a while, and if the old process bound without address reuse, the port stays reserved until that clears.
• The app opened the port twice — two listeners in one process, or a restart that never released the first socket.
• The bind is delayed. When a socket binds to a wildcard address (ADDR_ANY), Microsoft notes the 10048 "could be delayed until the specific address is committed" — so the error can surface on connect/listen rather than the bind line.

Find the process holding the port with netstat

Don't guess which program owns the port — ask Windows. netstat -ano lists every connection with its owning PID (-o "includes the process ID (PID) for each connection", -n numeric, -a all listeners):

netstat -ano | findstr :8080

  TCP    0.0.0.0:8080     0.0.0.0:0      LISTENING       17624
  TCP    [::]:8080        [::]:0         LISTENING       17624

LISTENING on :8080 with PID 17624 is your answer. Turn the PID into a name:

tasklist /fi "PID eq 17624"

If you'd rather see the executable directly, netstat -anob adds it — the docs describe -b as "Displays the executable involved in creating each connection or listening port" — but it needs an elevated prompt.

Or ask PowerShell: Get-NetTCPConnection

On current Windows, PowerShell joins the port to the process in one line:

Get-NetTCPConnection -LocalPort 8080 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess,
    @{ n = 'Process'; e = { (Get-Process -Id $_.OwningProcess).ProcessName } }

LocalAddress LocalPort OwningProcess Process
------------ --------- ------------- -------
0.0.0.0           8080         17624 node

That names both the PID and the process without a second lookup, and it works without an elevated prompt.

Fix it: free the port or move off it

Once you know the owner, choose the fix. If it's a stale instance of your own app, stop it:

taskkill /PID 17624 /F

Stop-Process -Id 17624 -Force does the same in PowerShell. Re-running your service now binds cleanly. If the port belongs to something you can't kill — a system service, or a port you don't own — change your app to a free port instead; that's the honest fix, not fighting over a shared one. If the clash only happens on restart because of TIME_WAIT, set SO_REUSEADDR on the listening socket so a new bind can reuse the recently-closed address. Note Windows also has SO_EXCLUSIVEADDRUSE, which does the opposite — it claims a port exclusively — and is what makes another app's bind fail with WSAEACCES instead.

A real case: a dev server that never let go

You stop a Node dev server with the window's close button and restart it — instant 10048 on :3000. Get-NetTCPConnection -LocalPort 3000 -State Listen shows OwningProcess 8840, Process node. The old process was orphaned when the terminal closed, not killed, so it still holds the socket. You run taskkill /PID 8840 /F, restart, and it binds first try. The port was never broken — the previous node still owned it.

Verify the port is free and the app binds

Confirm nothing owns the port, then start the service:

netstat -ano | findstr :8080

Empty output means the port is free. Start your app; it should reach LISTENING with no 10048. Re-run the netstat line and you'll now see your own service's PID on the port instead of the old one.

Keep the port from clashing again

Shut services down cleanly so the socket is released instead of orphaned — a supervised service (a Windows Service, nssm, or a container restart policy) beats closing a terminal window. Run one instance per port; if you need several, give each its own port or put them behind a reverse proxy. And pin your application to a fixed port you control, so a short-lived outbound connection using an ephemeral port can't grab it first.

How 10048 differs from 10013 and Linux EADDRINUSE

WSAEADDRINUSE (10048) means the address is in use. WSAEACCES (10013, "Permission denied") is different: another socket bound the same address with exclusive access via SO_EXCLUSIVEADDRUSE, or you lack permission — no amount of SO_REUSEADDR moves it. And on Linux the same idea is EADDRINUSE ("address already in use"), but you find the owner with ss -ltnp and free it with kill, not netstat -ano and taskkill. Same concept, different tools and a different address-reuse model.