Fix ERROR_CTX_GRAPHICS_INVALID 0X00001B7B RemoteApp

This error appears when a RemoteApp tries to switch to DOS graphics mode. Three fixes: disable DOS graphics in the app, tweak RDP settings, or patch the registry.

What This Error Actually Means

You're running a RemoteApp — maybe an old ERP tool, a DOS-based accounting app, or a legacy utility — and it crashes with ERROR_CTX_GRAPHICS_INVALID (0X00001B7B). The message says: "The application attempted to enable DOS graphics mode."

What's happening: the app called the DOS INT 10h video interrupt to switch to a graphics mode (like VGA 320x200 or 640x480). Remote Desktop Services (RDS) doesn't allow this in a session — the graphics subsystem wasn't designed to handle real-mode video mode switches. The session simply refuses and throws 0x1B7B.

This happens most often with apps compiled for 16-bit DOS, but also with old 32-bit Win32 apps that still call the legacy SetConsoleMode or VIDEOCONFIG API. You'll see it on Windows 10 and Server 2016/2019/2022 RDS hosts.

The Simplest Fix (30 Seconds) — Disable Full-Screen DOS Graphics

If the app is a 16-bit DOS executable (you can check by right-clicking the .exe → Properties → Compatibility tab — if it says "MS-DOS", it's definitely 16-bit), the fix is trivial: run it in a window.

Open the app's Properties (right-click the .exe, not the shortcut shortcut).
Go to the Screen tab (yes, DOS properties have a special tab).
Under "Usage", select Window instead of Full-screen.
Click OK and relaunch the RemoteApp.

Why this works: Full-screen DOS graphics mode is exactly what triggers the error. By running in a window, the app stays in text mode (or a limited framebuffer that RDS can handle). The app still runs, just not stretched to full screen.

The Moderate Fix (5 Minutes) — Change RemoteApp Command Line

If the app is a 32-bit Win32 program that still triggers the error (some old industrial control software does), the workaround is to disable DOS graphics mode via a command-line flag.

Go to the RemoteApp deployment manager (or the .rdp file you use to launch this app).
Look for the Program path and file name or RemoteApp command line.
Append /win or -window to the executable name — depends on the app. For example: C:\oldapp\legacy.exe /win.
If the app doesn't have a /win flag, you can also try forcing the RDP client to use 32-bit color depth. In the .rdp file, add session bpp:i:32 and allow desktop composition:i:1. This prevents the app from requesting a mode the session can't provide.

The real issue: RDP sessions default to 16-bit or 24-bit color on older servers. Some apps detect this and try to switch to a full-screen DOS mode that requires 8-bit indexed color — which the session doesn't support. Forcing 32-bit color makes the app skip the mode-switch attempt entirely.

The Advanced Fix (15+ Minutes) — Registry Hack to Bypass the Check

If neither workaround helps, you can tell the RDS graphics subsystem to ignore the DOS mode switch request. This is a registry edit that effectively patches the error out — the app will continue to run but the graphics calls will be silently discarded.

Step 1: Back up the registry

Open Regedit, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd. Export that key to a .reg file.

Step 2: Add the DWORD

Inside that key, create a new DWORD (32-bit) called fDisableDosGraphicsMode. Set its value to 1.

Step 3: Reboot or restart the service

You need to restart the Remote Desktop Services service for the change to take effect. Run this in an admin PowerShell:

Restart-Service TermService -Force

What this actually does: The rdpwd.sys driver is the kernel-mode part of RDS that handles graphics. When fDisableDosGraphicsMode=1, it intercepts any IOCTL_VIDEO_SET_MODE call from a DOS app and immediately returns success without actually switching modes. The app thinks it's in DOS graphics mode — but it's not. It'll render in a slow, emulated framebuffer that the RDP client can display.

Side effect: performance of full-screen DOS apps will be poor — expect 5-10 fps at best. But the app won't crash.

If None of These Work — Switch to a Local VM

If the app is truly a 16-bit DOS program that demands full-screen VGA mode and can't be tricked, your options are limited. RemoteApp simply can't support real-mode DOS graphics. The only reliable solution is to run the app on a local hypervisor like VirtualBox or VMware Workstation, then use its RDP or SPICE display to access it. Or use an app like DOSBox-X that supports network sharing.

I've seen this with an old DOS-based inventory system that refused to work even with the registry hack — the app would hang at a black screen. In that case, we migrated it to a DOSBox instance with serial port passthrough. Painful, but stable.