Yeah, that error's a pain – you're just trying to get WSL2 or a Hyper-V VM running and suddenly you're staring at STATUS_PORT_ALREADY_SET (0XC0000048). I've had clients call me about this at least a dozen times. The good news: it's almost always a port conflict, and you can fix it in under five minutes.
The Quick Fix
Open an elevated PowerShell (right-click Start, select "Windows PowerShell (Admin)") and run this:
net stop winnat
net start winnat
That's it. The Windows NAT service (winnat) is what WSL2 and Hyper-V use to map ports. When it caches a stale reservation, it throws this error. Restarting it flushes the cache.
If that doesn't do it, you need to manually clear the port reservation. Run:
netsh interface ipv4 show excludedportrange protocol=tcp
Look for the port range that includes the one your app is trying to use. If you see something like 2144-2243 and your app wants 2200, that's the conflict. To clear it, you have to stop winnat, delete the reservation, then restart winnat:
net stop winnat
netsh int ipv4 add excludedportrange protocol=tcp startport=2200 numberofports=1 store=active
Wait, that adds a reservation. To delete one, you need to remove the specific range. But the excluded ranges are managed by the system – you can't just delete them. What you can do is change your app's port to something outside the excluded range. Check the list from the command above, pick a port that's free, and reconfigure your app or WSL .wslconfig file.
Why This Happens
Here's the deal: Windows reserves blocks of ports for Hyper-V and WSL. When you restart WSL or reboot, sometimes those reservations don't get released properly. The system still thinks a port is taken even though the process is gone. That's your 0XC0000048.
I once had a client whose Docker Desktop kept crashing with this error every time they rebooted their laptop. The offending port was 8080, which some other Windows service kept reserving. After we figured out the range, we just told Docker to use 8081 instead. Problem solved.
Less Common Variations
WSL2 Not Starting at All
If you get this error when trying to run wsl --install or start a distribution, the winnat restart usually fixes it. But if not, try:
wsl --shutdown
Then restart winnat again. And make sure you're not running an old VPN client – some of them, especially enterprise ones like Cisco AnyConnect, mess with the network stack and cause port conflicts.
Hyper-V VM Network Adapter Fails
Occasionally, a VM will fail to start with this error because the virtual switch is trying to bind to a port already used by another VM. Fix: open Hyper-V Manager, check your virtual switch settings, and assign a different port range to each switch.
Docker Desktop Specific
Docker Desktop uses WSL2 and can throw this error if the Docker daemon's port (typically 2375) is already taken. The fix is to change the daemon port in %USERPROFILE%\.docker\daemon.json to something else, then restart Docker Desktop.
Prevention
Here's how to avoid this in the future:
- Don't use the same port for multiple services. Sounds obvious, but I've seen clients run a web server on 8080 and then try to start Jenkins on 8080 too.
- Keep Windows and WSL updated. Microsoft has fixed several port-related bugs in recent builds. Make sure you're on the latest version of Windows 10/11 (check Settings > Update & Security).
- Use dynamic ports for WSL. In your
.wslconfigfile (create it in%USERPROFILE%if you don't have one), add:
[wsl2]
networkingMode=mirrored
This makes WSL share the host's network stack, so port conflicts become rare. I've been running this on my personal machine since Windows 11 22H2 and haven't seen this error since.
Also, if you're a power user who frequently messes with Windows services, consider writing a quick batch script to restart winnat when you hit this error. It's saved me a ton of time.
Bottom line: this error isn't scary. It's just Windows being picky about ports. Restart winnat, pick a different port if needed, and you're back in business.