Fix 'An attempt was made to access a socket in a way forbidden by its access permissions' on Windows

The Error

You start your app and immediately get hit with:

SocketException: An attempt was made to access a socket in a way forbidden by its access permissions 0.0.0.0:5000

No other process is using port 5000. The firewall isn't blocking it. You're running as Administrator. Nothing obvious explains why Windows is refusing to let your app bind that port.

Why This Happens

Windows maintains a dynamic (ephemeral) port range — a pool of ports reserved for outgoing connections. Any port inside this range is off-limits for manual binding, even if nothing is currently listening on it.

Hyper-V, WSL2, and Docker Desktop made this much worse. When any of these features are active, Windows aggressively pre-reserves large blocks of ports at boot. The reservations appear in the excluded port range list and block your app silently — no "port in use" error, just the cryptic access permissions message.

Port 5000 gets hit often. It sits inside the default dynamic range on many Windows builds, and Hyper-V frequently grabs the entire 5000–5059 band at startup.

Step 1 — Confirm the Port Is Reserved

Run this in an elevated Command Prompt (Run as Administrator):

netsh interface ipv4 show excludedportrange protocol=tcp

Example output:

Protocol tcp Port Exclusion Ranges

Start Port    End Port
----------    --------
      5000        5059
      5985        5985
     49673       49772
     49773       49872

4 exclusion ranges present

If your port falls inside any of those ranges, that's your culprit. Windows has reserved it and won't let your app bind — regardless of whether anything is actually listening.

Fix 1 — Use a Different Port (Fastest)

The quickest fix: pick a port outside the excluded ranges. Ports like 3000, 8080, 8000, and 8888 are almost never reserved by Hyper-V and work reliably for local development. Avoid arbitrary ports in the 5000–7000 band — that's Hyper-V territory.

For .NET apps, update launchSettings.json:

{
  "profiles": {
    "MyApp": {
      "applicationUrl": "http://localhost:8080"
    }
  }
}

For Node.js:

PORT=8080 node server.js

For Python (Flask):

flask run --port=8080

Fix 2 — Reserve the Port Before Hyper-V Does

Beat Hyper-V to it. Register your own exclusion before Windows boots and Hyper-V won't touch that port. From an elevated Command Prompt:

netsh int ipv4 add excludedportrange protocol=tcp startport=5000 numberofports=1

Wait — this adds an exclusion, which sounds counterintuitive. The trick: user-defined exclusions are processed before Hyper-V grabs its dynamic block. Register port 5000 explicitly and Hyper-V skips it during its own reservation sweep.

Reboot, then verify:

netsh interface ipv4 show excludedportrange protocol=tcp

Port 5000 should now appear as a standalone entry, separate from the large Hyper-V block.

Fix 3 — Shift the Dynamic Port Range

Another angle: push the entire dynamic port range out of your way. On a clean Windows install it starts at 49152, but Hyper-V has a habit of dragging it lower — sometimes all the way into the 5000s.

Check the current range:

netsh int ipv4 show dynamicport tcp

Reset it to the IANA-recommended range (49152–65535):

netsh int ipv4 set dynamicport tcp start=49152 num=16384
netsh int ipv6 set dynamicport tcp start=49152 num=16384

Restart Windows after both commands. This tends to be the cleanest fix when a whole band of ports is blocked — not just 5000 but everything across the 5000–10000 range.

Fix 4 — Disable and Re-enable Hyper-V to Clear Reservations

Still seeing blocked ports after Fix 3? Hyper-V may have locked them in at an earlier boot. Cycling it forces Windows to rebuild the reservation table from scratch:

dism.exe /Online /Disable-Feature:Microsoft-Hyper-V

After it reboots, re-enable:

dism.exe /Online /Enable-Feature:Microsoft-Hyper-V-All

Reboot once more. When Windows comes back up, check the excluded range — the aggressive Hyper-V reservation blocks are usually gone or reduced to a handful of entries.

Note: This temporarily disables WSL2 and Docker Desktop (both depend on Hyper-V). They'll come back once you re-enable it.

Verify the Fix

One quick check before restarting your app — confirm the port is clear:

netsh interface ipv4 show excludedportrange protocol=tcp | findstr "5000"

No output means the port is free. Start your app and it should bind without complaint.

Want a more direct test? Run this in PowerShell:

$listener = [System.Net.Sockets.TcpListener]::new([System.Net.IPAddress]::Any, 5000)
try {
    $listener.Start()
    Write-Host "Port 5000 bound successfully"
    $listener.Stop()
} catch {
    Write-Host "Failed: $_"
}

If the script succeeds, your app will too.

Prevention

• Avoid arbitrary ports in the 5000–7000 range on Windows + Hyper-V. That's where Hyper-V tends to drop large reservation blocks at boot. Established dev ports like 3000, 8080, and 8888 are almost never reserved.
• Set port exclusions in a startup script. If your team always uses port 5000, bake the netsh int ipv4 add excludedportrange command into your dev environment setup script. New machines are protected before Hyper-V ever gets a chance.
• Document your port choices. Put the chosen port in .env.example or README.md so teammates don't hit the same wall when setting up their machines.
• Check reservations after upgrading Windows. Feature updates — especially those that touch Hyper-V or WSL2 — can reset or expand port reservations. Run show excludedportrange after any major Windows update.