Fix ERROR_CTX_SHADOW_INVALID (0X00001B8A) Remote Desktop Shadowing
This error pops up when you try to shadow a Remote Desktop session but the target session isn't set up for remote control. Usually happens after a Windows update or server reboot.
When This Error Shows Up
You’re trying to shadow a user’s Remote Desktop session on a Windows Server 2019 or 2022 box. You run mstsc /shadow:sessionID or use the Remote Desktop Services Manager console. Instead of seeing the user’s desktop, you get ERROR_CTX_SHADOW_INVALID (0X00001B8A). The session ID is correct. The user is logged in. But Windows says no.
I’ve seen this most often after a monthly Windows Update patch cycle or when someone’s been messing with Group Policy for remote control settings. It also pops up if you’ve recently promoted the server to a domain controller (don’t do that, by the way — RDS on a DC is a mess).
What’s Actually Going On
The culprit here is almost always one of two things: either the shadowing permission level for the target session is set to “No Remote Control,” or the WinStation registry key for that session got corrupted. The error literally means the session you’re trying to grab doesn’t have the right flag set to allow remote control. Windows checks this flag before letting any shadow attempt through.
It’s not a network issue. It’s not a firewall problem. Don’t waste time checking RDP port 3389 or restarting the Remote Desktop Services service — those won’t fix this.
Step-by-Step Fix
Step 1: Check Group Policy for Remote Control
Open gpedit.msc on the target server (or Group Policy Management Console if it’s domain-joined). Navigate to:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > ConnectionsFind the policy “Set rules for remote control of Remote Desktop Services user sessions.” Double-click it.
Set it to “Enabled.” Then choose “Full control with user’s permission” or “Full control without user’s permission” — pick whichever fits your org’s policy. I usually go with “without user’s permission” for admin work, but that’s your call.
Click OK and run gpupdate /force in an admin command prompt.
Step 2: Verify the Session’s Remote Control Setting via Registry
If Group Policy looks right but it still fails, the session itself might have the wrong flag. Each logged-in session has a corresponding key under:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\<SessionID>Where <SessionID> is the ID you’re trying to shadow (e.g., RDP-Tcp#2 or just a number like 2).
Look for a DWORD value named fEnableRemoteControl. If it’s not there, create it. Set it to 1 to allow remote control (or 0 to deny). A value of 1 means full control with user’s permission; 2 means without permission. For testing, use 1.
If you see a value of 0, that’s your problem — someone or something set it to deny. Change it to 1, close regedit, and try shadowing again.
Step 3: Check the User’s Remote Control Permission via RDS Manager
Open Remote Desktop Services Manager (not the old Remote Desktop Manager). Right-click the user’s session in the list. Choose Remote Control. If the option is grayed out, the session level permission is blocking it.
You can also check via PowerShell:
Get-RDUserSession | Select-Object SessionID, UserName, RemoteControlStatusIf RemoteControlStatus shows Disabled, the session isn’t allowing shadowing. The Group Policy fix above should flip this, but sometimes it takes a logoff/logon cycle to apply.
Step 4: Force a Session Refresh
If none of that worked, log the user off and back on. I know it’s blunt, but corrupted session flags get cleared on logout. If it’s a production user and you can’t kick them, try using qwinsta from an admin command prompt to see the session list, then rwinsta <SessionID> to reset it. That’ll log them off, so warn them first.
If It Still Fails
Check if the server has the Remote Desktop Session Host role installed. Without that role, shadowing doesn’t work at all — it’s not available on a plain Remote Desktop Services licensing server or on a server running just the RD Gateway role. You need the Session Host role.
Also verify you’re shadowing from an account that has Remote Control permission in the RDS security configuration. Open Remote Desktop Services Manager, right-click the server, go to Properties > Remote Control, and make sure your admin group is listed there.
Last resort: reboot the server. I hate saying that, but sometimes the Terminal Services service gets into a state where session flags don’t refresh. A clean boot fixes that.
Was this solution helpful?