Fix ERROR_CTX_SHADOW_DENIED (0x1B84) in 2 Steps
Remote Desktop shadowing denied? This error pops up when permissions or group policy blocks session control. Here's the fix — quick and dirty.
Yeah, this error is annoying. You're trying to shadow a user's RDP session — maybe for support or training — and Windows slaps you with ERROR_CTX_SHADOW_DENIED (0x00001B84). The request to control another session remotely was denied. Let's fix it.
The Two-Click Fix
This error almost always comes down to two things: permissions or Group Policy. Here's the order I check — and skip the nonsense about restarting the Remote Desktop Services service. That rarely helps.
- Check remote control permissions on the target machine.
Opengpedit.msc(or check the local policy if not domain-joined). Go to:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections
Find the policy named “Set rules for remote control of Remote Desktop Services user sessions.” Double-click it.
Set it to Enabled and choose one of these options:
- Full Control without user's permission (I use this internal support).
- Full Control with user's permission (safer, user gets a prompt).
- Verify the user running shadow has the right privileges.
The person initiating the shadow must be a member of the Remote Desktop Users group on the target machine, or have explicit permission viasecpol.mscunder User Rights Assignment > Allow log on through Remote Desktop Services. Also check they're in the local Administrators group — shadowing needs admin rights by default in modern Windows (Server 2016 and later).
After making these changes, run gpupdate /force on the target machine, then try the shadow command again:
mstsc /shadow:<sessionID> /control /v:<computerName>
That's it. 9 times out of 10, this resolves it.
Why This Works
ERROR_CTX_SHADOW_DENIED is Windows telling you “you don't have permission to do this, and I'm not going to tell you exactly why.” The two causes above are the only ones I've seen in production — across hundreds of servers from Windows Server 2008 R2 to 2022.
The Group Policy setting explicitly enables remote control. Without it, the Remote Desktop Session Host service defaults to denying shadow requests. The user permission part is straightforward — RDP shadowing isn't like a regular connection. It requires elevated privileges because you're taking over an existing session. You need admin rights on the box.
Less Common Variations
Sometimes the standard fix doesn't cut it. Here's what else I've seen:
- Domain vs Local Policy Confusion: If the machine is domain-joined, domain-level Group Policy may override local settings. Check
rsop.mscto see what's actually applying. A domain policy might have remote control disabled — talk to your Active Directory admin. - RDP Listener Permissions: Rare, but corrupt or missing permissions on the RDP-Tcp listener can cause this. Reset it with:
Then restart the service:reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v Security /fnet stop TermService && net start TermService. - Firewall Rules: Shadowing uses the same port as RDP (3389) but if a third-party firewall is blocking session control protocols (like Remote Desktop Services session management), you'll get this. Check firewall logs for blocked traffic on port 3389 from the shadowing machine.
- Session Zero Isolation: On Windows Server 2016+, shadowing into session 0 (console session) is blocked by default. Don't bother trying — it won't work. Stick to user sessions.
Prevention for Next Time
Once you've fixed it, lock it down so it doesn't break again:
- Set the remote control GPO to Full Control without user's permission if you're doing internal admin work. This prevents the prompt that some users accidentally deny.
- Document which accounts have admin rights on the servers. Shadowing breaks when someone removes a junior admin from the local Administrators group.
- Test shadowing after every Windows Update or GPO refresh. Updates have been known to reset the remote control policy to default.
That's the fix. No fluff. Go shadow that session.
Was this solution helpful?