Fix STATUS_PORT_DISCONNECTED (0xC0000037) on Windows 10/11

30-second fix: Restart the affected service or app

What's actually happening here is a race condition. Your program (say, OpenVPN or Docker Desktop) holds a reference to a communication port that's already been torn down by the kernel. The easiest thing is to just restart whatever is failing.

• Close the app showing the error — don't just hide it, fully quit.
• If it's a service, right-click the taskbar, open Task Manager, find the process, and End task.
• Wait 5 seconds. Then relaunch.

If that's all it takes, you're done. But if the error keeps coming back, the problem is deeper — the port isn't getting properly cleaned up.

5-minute fix: Reset Winsock and flush TCP connections

When a port disconnects but the socket isn't released, the kernel gets confused. The quickest way to clear that stale state is a Winsock reset. This is safe — it doesn't touch your files or settings, just repaves the network stack's internal roads.

1. Open Command Prompt as Administrator (right-click Start, choose Terminal (Admin) or Command Prompt (Admin)).
2. Run these three commands in order:

   netsh winsock reset
   netsh int ip reset
   ipconfig /flushdns

3. Restart your computer. Not just a logoff — a full restart.

Why step 2 works: winsock reset removes any bogus LSP (Layered Service Provider) entries that might be intercepting port calls. The int ip reset rewrites TCP/IP registry keys to defaults. flushdns is just peace of mind — it clears stale DNS mappings that could be pointing to dead ports.

Test your app after reboot. Error gone? Great. If not, keep reading.

15+ minute fix: Hyper-V/Virtual Switch port cleanup

If you're running Docker Desktop, WSL2, or any Hyper-V virtual machine, this error usually comes from the virtual switch. The reason is that Windows doesn't always release virtual ports when a container or VM stops abruptly. The port stays in CLOSE_WAIT state forever.

1. Identify which process owns the port. Run this in an admin PowerShell:

   netstat -ano | findstr :<port_number>
   # Look for the PID in the last column

2. Find the process name by PID:

   tasklist /fi "PID eq <PID_number>"

3. If it's vmms.exe or docker.exe, kill it:

   taskkill /F /PID <PID_number>

4. Then restart the Hyper-V Virtual Machine Management service:

   net stop vmms
   net start vmms

5. If you use Docker, also run wsl --shutdown in PowerShell to kill the WSL2 kernel, then restart Docker Desktop.

One real trigger for this error: I've seen it when a Docker container crashes during a port bind, leaving the host port half-open. The container's gone, but the kernel still thinks the port belongs to a disconnected endpoint. Killing vmms and restarting it forces a full port sweep.

If none of these work, you might have a third-party firewall or VPN driver (like Cisco AnyConnect or OpenVPN TAP) that's hooking into the Winsock stack. Uninstall those temporarily and retry. If the error stops, you've found the culprit.

Final note: I recommend running the Winsock reset even if you end up needing the Hyper-V fix. It's quick, harmless, and clears a lot of junk. If you're still stuck after these three steps, check Windows Event Viewer (Applications and Services Logs > Microsoft > Windows > NetworkProfile) for more specific clues.