STATUS_CTX_SHADOW_DENIED (0XC00A002A) Remote Session Fix
This error blocks remote shadowing in RDP. The culprit is almost always group policy or registry permissions. Here's how to kill it fast.
30-Second Check: Test with Different User
Before you go digging into group policy, rule out the obvious. This error often pops up when the user you're shadowing is an admin or has special permissions. Try shadowing a standard user session first. If that works, you're dealing with a permissions issue tied to the target user account. If it still fails, move to the next step.
5-Minute Fix: Group Policy Remote Control Settings
The most common cause of 0xC00A002A is the Remote Desktop Session Host policy blocking shadowing at the machine level. Here's how to check it:
- On the target machine, open gpedit.msc (or check domain GPO if this is domain-joined).
- Navigate to:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections - Find "Set rules for remote control of Remote Desktop Services user sessions". Double-click it.
- Set it to Enabled. Then choose "Full Control without user's permission" if you don't want prompts, or "Full Control with user's permission" if you want the user to approve.
- Click OK, then run
gpupdate /forcefrom an admin command prompt.
Don't bother with the "Remote Assistance" settings — that's a different feature. We're fixing shadowing via Remote Desktop Services Manager or mstsc /shadow.
10-Minute Fix: Registry Permissions (When Policy Won't Stick)
If group policy is set correctly but the error persists, the registry key that controls shadow permissions may have been locked down by a security template or a third-party tool. Here's the blunt fix:
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v Shadow /t REG_DWORD /d 4 /fValue of 4 means full control without user permission. Value 2 requires user consent. Value 1 gives view-only access. Reboot or restart the Remote Desktop Services service (net stop TermService && net start TermService) after applying.
Still failing? Check the NTFS permissions on that registry key. Right-click the key, go to Permissions, and make sure SYSTEM and Administrators have Full Control. Some security hardening scripts strip out the SYSTEM account — that'll break shadowing silently.
15+ Minute Fix: WMI and Terminal Services Permissions
If none of the above helped, you've got a deeper permission model issue. The shadow request uses WMI under the hood. Verify the user account has the required privilege:
- Open secpol.msc (Local Security Policy).
- Go to Security Settings > Local Policies > User Rights Assignment.
- Find "Allow log on through Remote Desktop Services" — make sure the user or group is listed there.
- Also check "Access this computer from the network" — same deal.
- Reboot the target machine after changes, since these don't refresh with gpupdate.
Still broken? Time to check the terminal services listener permissions. Run this from an admin PowerShell:
Get-WmiObject -Namespace root\cimv2\TerminalServices -Class Win32_TerminalServiceSettingLook for the ShadowTimeout property. If it's set to 0, change it to a positive value like 60000 (60 seconds). The shadow request times out instantly if this is zero.
When All Else Fails: Event Log Diagnosis
Check the System event log on the target machine for events from source TermDD or RemoteDesktopServices-RdpCoreTS. Filter for Event ID 1149 or 140. They'll tell you exactly which permission check failed — usually a missing SeRemoteInteractiveLogonRight or a broken WMI namespace. Fix whichever privilege the log flags, and you're done.
One last thing: if you're on Windows Server 2022 with Credential Guard enabled, it can block shadowing entirely. Disable it via Group Policy under Computer Configuration > Administrative Templates > System > Device Guard — but only if you're sure the security trade-off is acceptable.
Was this solution helpful?