STATUS_CTX_CDM_CONNECT (0X400A0004) on Terminal Connection

What This Error Actually Means

If you're staring at the 0X400A0004 error in Event Viewer or a login screen, stop hunting for a real problem. This event is informational – it's the Client Drive Mapping service connecting during a Remote Desktop session. Citrix and native RDP both log this. I've seen it on Windows Server 2016, 2019, and 2022, plus Windows 10 and 11 clients running the Remote Desktop Connection client.

The trigger is simple: someone logs into a remote desktop or Citrix session, and the drive mapping service negotiates drive redirection. That's it. No crash, no data loss, no user impact. But if it's cluttering your logs or confusing users, you can squash it.

Cause #1: Drive Redirection Is Enabled (Most Common)

By default, RDP and Citrix allow local drives to be mapped into the remote session. When the Client Drive Mapping service connects those drives, it fires the 0X400A0004 event. It's expected behavior – not a bug. The event ID is 0X400A0004 under TerminalServices-SystemEventManager in Event Viewer.

Fix: If you want the drives mapped (most people do), do nothing. It's working as designed. But if you're tired of seeing it in logs, disable drive mapping.

For native RDP: Create a GPO or local policy at Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Device and Resource Redirection. Set "Do not allow drive redirection" to Enabled. Reboot the server or run gpupdate /force.

For Citrix: In Studio, edit the delivery group policy. Under Citrix Policies -> Resources -> Drive Redirection, set "Client drive redirection" to Prohibited. Alternatively, disable it per user in the Citrix Workspace app client settings.

Skip any registry hacks here – they're overkill. Policy is cleaner.

Cause #2: Third-Party Drive Mapping Software (Less Common)

Some backup or file sync tools (like Carbonite, Druva, or ownCloud) install their own drive mapping drivers. These hook into the RDP session and can trigger additional 0X400A0004 events during logon. The event will still show as Client Drive Mapping Service, but the root cause is the third-party driver.

Fix: Open Event Viewer and check the details of the event. Under EventData, look for a DriverName or DevicePath that references a non-Microsoft file. If you see something like \Device\CarboniteDrv, that's your culprit.

Uninstall the third-party tool's drive mapping component, or disable its RDP integration in the app's settings. For example, in Carbonite, go to Settings -> General -> Advanced and uncheck "Map drives in remote sessions". No need to nuke the whole app.

If you can't find the driver, use driverquery in an admin command prompt and look for anything named rdpdr or similar. Filter with driverquery /si to see unsigned drivers – most third-party ones aren't signed by Microsoft.

Cause #3: Corrupted RDP Session or User Profile (Rare)

This one's a stretch, but I've seen it twice in 14 years. If the event floods the log every few seconds during a session, not just at logon, the user profile's RDP settings might be corrupted. Usually happens after a failed profile migration or a botched Windows update.

Fix: Test with a fresh local admin account. Create a new user, log in via RDP, and check Event Viewer. If the event only fires once at logon, the original user's profile is hosed. Rename the user's profile folder (e.g., C:\Users\OldUsername.bak) and have them log in again. Windows creates a fresh profile.

Alternatively, delete the user's registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-xxxx (find the right SID). Back up first. Reboot, let Windows rebuild.

One more thing: if you're using RDS farm with session brokers, check the broker logs. Sometimes 0X400A0004 fires due to load balancing timing issues. Reboot all session hosts to clear stale connections.

Quick-Reference Summary Table

Bottom line: 0X400A0004 is not a real error. It's a notification. If it's annoying you, kill drive redirection. If it's breaking something, you've got a different problem – check the application event logs instead.