STATUS_CONNECTION_DISCONNECTED 0xC000020C — Fix SMB Mapped Drives

If you're staring at STATUS_CONNECTION_DISCONNECTED (0xC000020C), the message underneath it says it all: "the transport connection is now disconnected." That's Windows telling you the SMB session your app was using got yanked out from under it. The share, the mapped drive, the UNC path — whatever was talking over port 445 — is gone.

You'll see this most often in Explorer when a mapped drive went to sleep, in event logs from file servers, or coming out of line-of-business apps that keep a UNC path open all day. I've hit it on everything from Server 2012 R2 boxes serving QuickBooks databases to Windows 10 workstations with a drive letter for a NAS that idles out after 15 minutes.

Here's the order I troubleshoot it in, and what actually fixes it.

Cause 1: The share went idle and Windows dropped the session

This is the culprit in probably 70% of the tickets I've seen. Windows (and the server on the other end) will silently tear down an SMB session that hasn't moved any bytes in a while. The workstation keeps the drive letter, Explorer still shows it, but the moment you click into it you get 0xC000020C or a hang followed by a reconnect.

On the server side, the setting is autodisconnect. Default is 15 minutes. On the client side there's similar idle behavior, plus newer SMB2/3 has its own keepalive that doesn't always save you.

First, confirm it. On the client, run:

net use
net statistics workstation

Look for sessions that show "Disconnected" or a status of "Unavailable." Then go to the server and check:

net config server

If AutoDisconnect shows 15, that's your ticking clock.

The real fix: raise or disable the idle disconnect on the server, and add a persistent keepalive on the client.

net config server /autodisconnect:-1

That sets it to never auto-disconnect. Don't leave it at -1 forever on a busy file server — you'll accumulate stale sessions. -1 works fine on a small office server. On anything with 50+ users, set it to 60 or 120 instead.

On the client, if it's a mapped drive, don't just tick "Reconnect at sign-in." That does nothing for idle drops. Instead, use a scheduled task or a small script that touches the share every few minutes. Something like:

dir \\fileserver\share > NUL

Run it every 5 minutes via Task Scheduler. Ugly, but it works, and I've used it in production for years on stubborn NAS boxes that ignore autodisconnect changes.

Cause 2: SMB1 vs SMB2/3 mismatch or negotiation failure

Second most common. You've got an old NAS, an old print server, or a legacy app that only speaks SMB1, and either the client has SMB1 disabled (which Microsoft has been pushing hard since 2017) or the server only speaks SMB1 and the client refuses to fall back. The session hands off, negotiation fails, and you get 0xC000020C on the reconnect attempt.

Confirm what's enabled on the client:

Get-SmbClientConfiguration
Get-SmbClientConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol

On the server:

Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol

If SMB1 is off on the client but the target device only speaks SMB1, that's your disconnect. You've got two choices, and I'll be blunt: firmware-update the device if you possibly can. SMB1 is a security nightmare (WannaCry lived on it). If you absolutely cannot replace the device, re-enable SMB1 on the specific client machine only, and only for that machine:

Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol-Client -NoRestart

Don't enable SMB1 server-side on anything internet-facing. Ever. The 0xC000020C will go away, but you'll trade it for a CVE.

Also worth checking the SMB dialect actually being used. Run this after a successful connect:

Get-SmbConnection

If you see Dialect 1.0, you know why things are flaky. Force the client to demand SMB3 where possible:

Set-SmbClientConfiguration -RequireSecuritySignature $true -Force

Cause 3: Network path instability — NIC power saving, VPN, or MTU

Third on the list, and the one people waste the most time on because it looks like a Windows problem when it's actually the network. The SMB session dies because the underlying transport flapped — NIC went to sleep, VPN rekeyed, or an MTU mismatch silently ate the keepalive packets.

Classic real-world trigger: a laptop on Wi-Fi with "Allow the computer to turn off this device to save power" enabled on the NIC. Lid closes, NIC sleeps, SMB session dies, lid opens, drive shows disconnected. Users think the file server is broken. It isn't.

Disable power management on the NIC. Device Manager → Network Adapters → your adapter → Properties → Power Management → uncheck the box. Or via PowerShell:

Get-NetAdapter | Where-Object Status -eq 'Up' | ForEach-Object {
  $_.PowerManagement | Set-NetAdapterPowerManagement -AllowComputerToTurnOffDevice Disabled
}

If it's VPN, the rekey interval is usually the killer. Check your VPN client logs for reconnects lining up with the 0xC000020C events. On IPSec VPNs, bump the SA lifetime, or move the SMB traffic to a split-tunnel so it doesn't ride the tunnel at all.

MTU is the sneaky one. Test with ping:

ping fileserver -f -l 1472

If that fails but -l 1400 works, you've got an MTU problem somewhere on the path — usually VPN or a crappy ISP. Fix it on the router/VPN side. Setting the client NIC MTU lower as a workaround is fine short-term but it's papering over a real network fault.

Quick-reference summary

One last thing — don't chase this with sfc /scannow or a Windows update rollback. I've watched people burn hours on that. 0xC000020C is a transport-layer disconnect. It's the share, the protocol, or the wire. Fix one of those three and the error goes away.