Field Guide

RDP authenticates, then shows only a blank or black screen.

Use this when credentials are accepted and the session opens, but Explorer never paints, the desktop stays black, or you only get a mouse pointer. The order below is intentional: start with the least disruptive transport and graphics changes before you widen into published-app or shell policy cleanup.

Search RDP Issues Open Windows Domain
First Triage

Confirm it is a rendered-session problem, not a logon failure.

  • Test one affected user and one administrative account with mstsc /admin so you can tell whether the issue is session creation or the user shell.
  • Before touching policy, clear client-side bitmap caching in mstsc.exe > Show Options > Experience > Persistent bitmap caching and test again. Microsoft lists bitmap caching as the first fix path for blank-screen sign-in behavior.
  • If the problem began after GPU, display-driver, VMware console, Hyper-V video, or patch changes, move straight to the graphics-policy steps below.
  • Capture gpresult /h c:\temp\rdp-gpo.html on the target host if you can reach console or alternate management so you can verify which RDS policies are actually winning.
Fix Order

Try the highest-yield GPO and registry changes in this order.

  1. Force the client to stop using RDP UDP first. GPO: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client > Turn Off UDP On Client = Enabled. Registry: reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDP /t REG_DWORD /d 1 /f.
  2. Disable WDDM for RDP sessions on the server next. GPO: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment > Use WDDM graphics display driver for Remote Desktop Connections = Disabled. Registry: reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fEnableWddmDriver /t REG_DWORD /d 0 /f.
  3. If the host has a physical or virtual GPU path, disable hardware-GPU preference for RDS sessions. GPO: 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 = Disabled. Registry: reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v bEnumerateHWBeforeSW /t REG_DWORD /d 0 /f.
  4. Force a full desktop instead of a single-app shell. GPO: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment > Always show desktop on connection = Enabled. Registry: reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fTurnOffSingleAppMode /t REG_DWORD /d 1 /f.
  5. If the session is still blank, clear any forced shell or published-program policy. GPO: Computer Configuration and User Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment > Start a program on connection = Disabled or Not Configured. Field note: do this in policy first because it is safer to validate than manually clearing shell-launch values in the registry.
Why This Order Works

Change transport first, then graphics, then shell behavior.

This is HelionFall’s operational order, inferred from Microsoft’s blank-screen KB plus the documented RDS transport and graphics policies. UDP and WDDM changes are the fastest, cleanest ways to prove whether the blank screen is coming from transport/rendering. Shell and published-program cleanup comes later because it changes how the entire session starts, not just how it paints.

  • Step 1 is the fastest low-risk isolation move when WAN, VPN, packet handling, or only some clients are affected.
  • Steps 2 and 3 are the highest-yield server-side fixes after GPU, VM display, or servicing changes.
  • Step 4 is useful when users are dropped into the wrong shell model or published-app behavior.
  • Step 5 is where to look when logon succeeds but the wrong startup program or RemoteApp configuration prevents Explorer from ever appearing.
Apply And Validate

Do not stack all five changes at once.

  1. Apply one step only, then run gpupdate /force on the affected host.
  2. For steps 2 and 3, prefer a full reboot of the RDS host or server after the policy change so the graphics stack is genuinely reset.
  3. Retest with the same affected account and one admin account so you can tell whether the fix is session-wide or user-specific.
  4. If the desktop appears after one step, stop there and document the winning policy rather than leaving every workaround in place.
  5. If none of the steps work, investigate user shell launch, profile corruption, explorer.exe startup, third-party credential providers, and event logs under Applications and Services Logs\Microsoft\Windows\TerminalServices-*.
Related Policies

Settings that commonly sit next to the real cause.

  • Prioritize H.264/AVC 444 graphics mode for Remote Desktop Connections: if enabled broadly, test by backing it out when only some thin clients or WAN paths fail.
  • Configure H.264/AVC hardware encoding for Remote Desktop Connections: review if black-screen behavior started after GPU or encoder-driver changes.
  • RemoteApp and collection settings in Server Manager: review if only one RDS collection or published app presents a blank session.
  • Third-party display, screen-capture, EDR, or remote-control agents: review if the issue started after endpoint tooling or overlay-driver changes rather than Windows policy.