Fix 0X00000962: Active Connections Still Exist

Windows throws this error when you try to shut down or restart but something's still holding a network connection. Here's how to find and break it fast.

I know this error is infuriating

You hit restart, the screen blinks, then—bam—0X00000962 pops up. Your PC refuses to shut down because some process still has an active network connection. It feels like the computer is being stubborn for no reason. But there's a method to this madness, and once you see it, you'll never be stuck again.

The quick fix: kill the offender with netstat

Open Command Prompt as administrator. Right-click the Start button and pick “Command Prompt (Admin)” or “Terminal (Admin)” on Windows 11.

Then run this to list all active connections with their process IDs (PIDs):

netstat -ano | findstr ESTABLISHED

You'll get a list like this:

TCP    192.168.1.5:52345    192.168.1.10:445    ESTABLISHED    1234

The number on the far right (1234) is the PID. That's the process holding the connection. Now you can kill it with:

taskkill /F /PID 1234

Swap 1234 for the actual PID you see. After that, try restarting again. It'll go through.

Why this works

Windows is paranoid about losing network data. When you request a shutdown, it checks if any TCP connections are still alive. If they are, it throws 0X00000962 and aborts the shutdown sequence. By force-killing the process (or closing the connection), you're telling Windows, “Hey, nothing's pending now.” The /F flag force-stops the process, so it doesn't get a chance to protest.

Most of the time, the culprit is a background app—a file sync tool like Dropbox, a torrent client, or sometimes a stuck Windows service. The netstat trick works for all of them because it shows you exactly who's holding the door open.

When netstat doesn't show anything

If the list is empty or you don't see the connection that's causing trouble, the issue might be a UDP connection. UDP doesn't use ESTABLISHED, so try this instead:

netstat -ano | findstr UDP

You'll see UDP entries with PIDs too. Same deal—find the PID and kill it. But be careful here. Some UDP entries are system processes (like svchost.exe) that you shouldn't kill blindly. If you kill a system process, you might crash something else. Use tasklist to check what the PID is before killing:

tasklist /FI "PID eq 1234"

Still stuck? Check for orphaned connections

Sometimes a process dies but leaves a socket half-open. Windows holds onto it for a while (usually 30–120 seconds). If you're in a hurry, wait a couple minutes and try again. If it persists, you might need to disable the network adapter temporarily, then re-enable it. Here's how:

Open Control Panel > Network and Sharing Center.
Click “Change adapter settings.”
Right-click your active adapter (Wi-Fi or Ethernet) and choose “Disable.”
Wait a few seconds, then right-click again and “Enable.”

That forces Windows to drop all connections on that adapter. It's a blunt instrument, but it works when you can't find the PID.

Less common variations

Some people see this error only when shutting down after a long idle period. That's usually a network drive or a mapped share that Windows is trying to disconnect. If you have mapped drives, try disconnecting them before shutdown: right-click the drive in File Explorer and select “Disconnect.” If that fixes it, you might want to stop mapping that drive at startup.

Another variation shows up on Windows Server with Hyper-V. Virtual machines keep network connections open even when they're paused. If you're running VMs, shut them down cleanly before shutting the host server. Or use:

Get-VM | Stop-VM -Force

in PowerShell. That forces all VMs off, then you can restart.

Prevention: stop the error from coming back

The best way to avoid 0X00000962 is to know which apps are prone to holding connections. Torrent clients and cloud sync tools are the usual suspects. Set them to exit cleanly when you shut down, or better, schedule your shutdown when they're not actively transferring.

Also, keep Windows updated. Microsoft has patched shutdown behavior several times, and newer builds are less trigger-happy with this error. If you're on an old version like Windows 7 or 8.1, consider upgrading—not just for this error, but for security.

Finally, if this keeps happening with no clear culprit, check your NIC drivers. Outdated drivers can cause TCP stacks to misbehave. Head to your motherboard or laptop manufacturer's site and grab the latest Ethernet/Wi-Fi driver. It's a 10-minute job that might save you hours of frustration.