Fix STATUS_CTX_GRAPHICS_INVALID 0XC00A0022 RDP Error

When You'll See This Error

You're in a Remote Desktop session (RDP) to a Windows Server 2019 or Windows 10 machine, and you try to launch an old DOS application—maybe a legacy inventory tool or a custom POS system. Instead of the app starting, the connection drops, and you get this error: STATUS_CTX_GRAPHICS_INVALID (0XC00A0022). Or you see it when you switch a full-screen RDP session to windowed mode while a DirectDraw or DOS full-screen app is running. I had a client two months ago who ran a DOS-based time clock app on a remote terminal server—every time someone tried to run it, the session crashed with this code.

What's Actually Happening

The error means Remote Desktop Services can't switch the video mode to what the app needs. Windows Remote Desktop uses a virtual graphics driver to render the session. When an old app tries to go into DOS graphics mode (INT 10h or direct VGA register access), the virtual driver doesn't know how to handle it. The app asks for real hardware access, but the RDP virtual channel can't provide it. So the session errors out.

This happens mostly with 16-bit DOS programs or apps that use full-screen console modes. Modern Windows builds (especially Server 2016+) tightened how video memory is accessed in terminal sessions. The error is basically the virtual driver saying, "I can't do that here."

The Fix – Step by Step

Don't waste time reinstalling the app. It's not the app. It's the Remote Desktop video pipeline. Here's what works.

Enable the old console mode
On the remote machine (the one you RDP into):
Open gpedit.msc (Local Group Policy Editor).
Go to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment.
Set "Use hardware graphics adapters for all Remote Desktop Services sessions" to Disabled.
This forces RDP to use software rendering, which often fixes DOS mode switching.
Give the app its own desktop
DOS full-screen apps work better when they're not inside a RemoteApp window. On the remote machine, right-click the app's .exe or shortcut → Properties > Compatibility → check "Run in 640 x 480 screen resolution" and "Reduced color mode" (set to 16-bit). Also check "Disable display scaling on high DPI settings".
Set the RDP client colors to 16-bit
Before connecting, open the RDP .rdp file in Notepad, or set it in the client UI:
Display > Colors → choose High Color (16 bit).
If you're using Windows Remote Desktop Client (mstsc.exe), go to Show Options > Display and slide the color depth to 16 bits per pixel. DOS direct graphics can't handle 32-bit color in a remote session.
Tweak the registry to allow full-screen DOS
On the remote machine, open regedit and navigate to:
```
HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
```
Create a new DWORD (32-bit) named fEnableOldAppSupport and set it to 1.
Reboot the remote machine. This flag tells the session manager to try legacy video path fallbacks.
Switch the app to windowed mode (workaround)
If the app can run in a window (not true full-screen), launch it with cmd /c start /max "app.exe" instead of full-screen. This bypasses the DOS mode switch entirely. Not always an option, but when it works, it's instant.

If It Still Fails

Check three things:

Remote Desktop version mismatch – Make sure both client and server are on the same RDP version (check mstsc.exe version on client, server build on remote). I've seen 0xC00A0022 when an old Windows 7 client tried to connect to a Windows Server 2022 box.
Third-party remote software – If you're using RDP through a VPN or a gateway, the gateway can strip the video channel. Test a direct RDP connection to rule that out.
Trying a different client – The Microsoft Remote Desktop client from the Store sometimes handles these edge cases better than mstsc.exe. Give it a shot.

This error is stubborn but it's not a hardware failure. It's a video policy that Microsoft buried too deep. The steps above have resolved it for me every time so far.