STATUS_CTX_CDM_DISCONNECT (0X400A0005) – Client Drive Mapping Fix

What's Actually Happening Here

Error 0X400A0005 means the Client Drive Mapping (CDM) service on the terminal server lost the connection to your local drives during a Remote Desktop session. This isn't a random crash — it's a deliberate disconnect triggered by a timeout or a conflict. The reason step 3 works is that stale filter drivers or bad registry values block the redirection from reconnecting.

You'll see this on Windows 10/11 workstations connecting to Windows Server 2016/2019/2022, and it's especially common after a Windows Update that changes RDP behavior or after installing a third-party VPN that hooks into the network stack.

Fix 1: The 30-Second Registry Tweak

This is the first thing to try because it's dead simple and fixes the most common cause: a corrupted or missing fEnableDiskMapping value.

1. Press Win + R, type regedit, hit Enter.
2. Navigate to

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

3. Look for a DWORD named fEnableDiskMapping. If it's missing, create it (right-click -> New -> DWORD (32-bit Value)).
4. Double-click it and set the value to 1.
5. Reboot the machine — not the session, the whole OS.

Why this works: fEnableDiskMapping tells the RDP listener to accept drive redirection requests from clients. If it's set to 0, or absent (which Windows treats as 0), the server silently ignores your local drives. You'll get the disconnect error when the session tries to map drives and the server says “nah.”

Skip this if you're on Windows 11 22H2 or later — those builds already have it set correctly by default. Move to Fix 2 instead.

Fix 2: The 5-Minute Group Policy Check

If the registry tweak didn't stick or you're in a domain environment, group policy overrides local registry settings. Here's where you check both the local policy and any inherited GPOs.

1. Open gpedit.msc (or rsop.msc to see resultant policy if you're on a domain).
2. Go to

   Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Device and Resource Redirection

3. Find “Do not allow drive redirection” — set it to Disabled or Not Configured.
4. Also check “Allow drive redirection” (if present on your version) — set it to Enabled.
5. Run gpupdate /force in an admin command prompt, then reboot.

The real gotcha here: if you're on Windows 10/11 Pro or Enterprise, the “Do not allow” policy can be enabled by default in some security templates. I've seen it enabled by a security baseline that blocks all redirection “for security.” The error code doesn't tell you it's policy — it just says the service disconnected, which is the server's way of giving up.

Pro tip: If you're connecting from a Windows 10 client to a Server 2019 host, check the policy on both sides. The client policy also has a drive redirection setting under User Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Connection Client — though that one usually just affects the UI, not the actual mapping.

Fix 3: The 15+ Minute Deep Clean

This is for the stubborn cases where Fix 1 and 2 didn't help. What's actually happening here is a driver conflict — usually from a third-party filter driver that hooks into the file system and breaks the RDP redirection. The usual suspects: antivirus (especially McAfee, Symantec, or Trend Micro), backup software (like Veeam or Acronis), or a VPN client (particularly Cisco AnyConnect or Pulse Secure).

Step 3a: Identify the Culprit

1. Open an admin command prompt and run

   driverquery /v /fo list | findstr /i "filter"

2. Look for any filter driver that isn't Microsoft's. The watermark is third-party names like SymDS, SymEFA, VeeamFlt, Acronis, vsock (VMware), or VBox (VirtualBox).
3. For each suspect, disable it temporarily:

   fltmc unload [driver name]

4. Test your RDP session. If the drive mapping works, you found the problem.

Important: fltmc unload is temporary — it'll come back on reboot. You need to properly disable the service or uninstall the software.

Step 3b: Check the RDP Listener

Sometimes the RDP listener itself gets corrupted by a Windows Update. Run this in an admin PowerShell:

Get-WmiObject -Class Win32_TerminalServiceSetting -Namespace root\cimv2\TerminalServices | Select-Object TerminalPort, fEnableDiskMapping

If fEnableDiskMapping shows False even after you set the registry to 1, the listener refused the value — rare, but happens after a botched update. The fix is to recreate the WinStations key:

1. Open an admin command prompt.
2. Run

   reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v fEnableDiskMapping /f

3. Then

   reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v fEnableDiskMapping /t REG_DWORD /d 1 /f

4. Restart the Remote Desktop Services service: net stop TermService && net start TermService

If that doesn't work, the nuclear option is to remove and reinstall the RDP role (on Server) or reset the RDP listener on Windows 10/11 with netsh int ip reset and a reboot. I've only needed that twice in five years, but it works.

When to Give Up and Use a Workaround

If you've done all three fixes and the error persists, check if you're using a VPN that uses split tunneling. Some VPNs (especially SSL VPNs like Palo Alto GlobalProtect) will drop drive mapping because they route traffic through the remote gateway and the SMB packets can't find their way back. In that case, disable split tunneling for the RDP session or map drives via a UNC path directly to the server instead of relying on client drive mapping.

But honestly, 90% of the time it's Fix 1. Start there.