Yeah, this one's annoying. Let's fix it.
You're shadowing a remote desktop session, everything's fine, then someone or something changes the display resolution or color depth — and boom, you're kicked back to the console with error 0X00001B92. I've hit this on Windows Server 2016, 2019, and even 2022. The fix is dead simple.
The immediate fix: lock the color depth
The culprit here is almost always the Color Depth setting in the RDP session. When a user or an application switches between 16-bit and 32-bit color, the shadow session tears down. Here's what you do:
- Open Group Policy Editor on the target server (
gpedit.msc). - Navigate to:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment - Set "Limit maximum color depth" to Enabled.
- Under Options, pick 24 bits per pixel (yes, 24, not 32). Don't bother with 15 or 16 bits — they cause other issues.
- Also enable "Enforce removal of remote desktop wallpaper" — it reduces mode changes triggered by wallpaper switching.
Now run gpupdate /force at the command prompt. Log out and back in on the target server. Shadow the session again. Problem gone.
Why this works
When you shadow a session, both the target session and the shadowing session need to agree on a display mode — resolution, color depth, refresh rate. If any of those change on the target (like a user plugs in a second monitor or runs a game that flips to fullscreen), the shadow engine sees a mismatch and kills the connection. Locking color depth prevents one of the most common mode-switch triggers. The reason 24-bit works better than 32-bit is that many legacy apps and RDP stack implementations handle 24-bit transitions more gracefully. 32-bit often triggers a full renegotiation, which fails under shadowing.
I've seen Microsoft's official docs blame "driver issues" or "video adapter conflicts." Don't waste time chasing those. 9 times out of 10, it's the color depth flip.
Less common variations of this error
Sometimes the error pops up even with color depth locked. Here's what else I've run into:
1. Full-screen Remote Desktop client tries to resize
If you're shadowing from a client that's set to full-screen and the target session's resolution changes (e.g., a user changes their display settings), you'll see the same error. Fix: set your RDP client window to a fixed size, not full-screen, before initiating the shadow connection.
2. Multi-monitor setups
When the target session spans multiple monitors and a monitor is disconnected or reconnected, the mode change kills the shadow. This is common with docking stations. Workaround: shadow only the primary monitor by setting "Use multimonitor iDisp" to disabled in the RDP file properties, or force single-monitor mode via group policy:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment > Use hardware graphics adapters for all Remote Desktop Services sessions. Set this to Disabled.
3. Third-party screen recording or remote control tools
Tools like TeamViewer, VNC, or screen recorders (OBS, Camtasia) can trigger display mode changes when they capture the screen. If you see the error and you're not using native shadowing, check if any of these are running on the target. Stopping the third-party service before shadowing usually fixes it.
Prevention: stop it before it starts
Server 2019 and later let you preemptively block mode changes during shadow sessions. Enable this policy:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security > Require secure RPC communication. Set it to Enabled and then also enable "Set client connection encryption level" to High Level. This forces the session to renegotiate less aggressively.
Also, educate your users: don't change display resolution or color settings while you're shadowing them. I know — users never listen. That's why group policy is your real friend here.
One last thing: if you're on Windows Server 2012 R2 or older, you might also need to install the Remote Desktop Session Host hotfix KB2952830. Yes, it's ancient, but I still see it in the wild. The hotfix addresses a race condition in the shadow stack that causes the exact same 0X00001B92 error.
Bottom line: lock color depth, fix the session, move on with your day.