
{/* banner prompt: A vivid infographic-style scene where a stream of glowing data blocks flows through a semi-transparent proxy filter that visibly plucks out a single red block, labelled "0x08", causing a connection icon downstream to display a red error symbol "0x609". Clean light-gray background, sharp isometric perspective, muted blue-and-red palette, technical but clear. */}

RDP error 0x609 — "An authentication error has occurred" — is a CredSSP failure. The standard advice is to check your NLA settings, patch your CredSSP version, or relax the encryption level. None of it helped us, because the error only appeared when connecting *through a proxy*. Direct connections to the same server worked perfectly every time.

That asymmetry is the only clue you need. If direct works and proxied doesn't, the proxy is transforming something it shouldn't be.

## The setup

We were relaying RDP over a WebSocket tunnel — client connects to a local port, a relay forwards the raw TCP stream through a WebSocket connection to a gateway, gateway connects onward to the Windows machine. A standard CONNECT-style proxy, just over WebSocket instead of a raw TCP pipe.

The first phase of an RDP connection (X.224 → CredSSP → MCS → RDP) is negotiated in the clear before any screen data flows. Our relay passes bytes through untouched, so in theory the server should see exactly the same handshake whether or not a proxy is in the middle.

In theory.

## What 0x609 actually tells you

The Windows error 0x609 maps to `STATUS_LOGON_FAILURE` inside the CredSSP layer, but that description is misleading. It doesn't necessarily mean the credentials are wrong. It can also mean the CredSSP negotiation *completed* but the session couldn't be established afterwards — the error surfaces at the CredSSP layer because that's where the TLS channel lives, and whatever went wrong downstream comes back through it.

The useless nature of this error code is part of what makes 0x609 hard to debug. You're essentially told "something authentication-related failed" without any pointer to where in the multi-phase handshake the failure occurred.

## Reading the X.224 handshake

RDP starts with an X.224 Connection Request (CR) from the client. Buried inside the TPKT/X.224 framing is a `requestedProtocols` field — a bitmask that advertises which security layers the client supports:

- `0x01` — SSL/TLS
- `0x02` — NLA (CredSSP over NTLM/Kerberos), also called HYBRID
- `0x08` — HYBRID_EX (an extension to NLA used by modern Windows)

Modern `mstsc` sends `0x0b` — all three bits set. The server responds with an X.224 Connection Confirm (CC) that includes a `selectedProtocol` field indicating which mode it chose.

Here is where we found the divergence.

**Direct connection:** the CC came back with `selectedProtocol = 0x08` (HYBRID_EX).

**Through the proxy:** the CC came back with `selectedProtocol = 0x02` (HYBRID, plain NLA).

Same client. Same server. Different `selectedProtocol`. The proxy was changing something in the CR before it reached the server.

## The hidden transformation

The proxy had a small normalisation function applied to the first TCP frame on each new connection. Its purpose was compatibility: some older Windows environments support NLA but reject HYBRID_EX outright, returning an immediate RST. So the function detected the X.224 CR structure, read the `requestedProtocols` field, and cleared the `0x08` bit before forwarding.

The intent was conservative — strip the extended mode, keep plain NLA, everything still authenticates. It worked on the servers we originally tested it against.

What we hadn't accounted for: some Windows Server versions advertise both HYBRID and HYBRID_EX, but internally require the HYBRID_EX flow to complete a session correctly. When forced into HYBRID mode by the altered CR, they complete CredSSP — all five steps of the NTLM exchange succeed, credentials are verified — and then the MCS Connect-Initial fails. The session can't start.

The mechanism: HYBRID_EX adds a step that HYBRID omits. After the CredSSP exchange, the server sends an Early User Authorization Result PDU before the MCS layer begins. This PDU is part of the HYBRID_EX contract. When the server is put into HYBRID mode (because `0x08` was stripped from the CR), it doesn't send this PDU — but if the server's internal session setup expects it, or if the subsequent MCS framing depends on state that only HYBRID_EX establishes, the session fails. From the client's side it arrives as a 0x609.

In pseudo-code, what was happening:

```
# CR goes out with 0x0b (SSL | NLA | HYBRID_EX)
# proxy strips 0x08 → 0x03 (SSL | NLA)
# server selects HYBRID (0x02) — the highest it can given the offer
# CredSSP runs normally and succeeds
# server tries to start MCS in HYBRID_EX mode internally
# HYBRID_EX Early User Authorization PDU never arrives
# MCS Connect-Initial fails
# error surfaces as 0x609 on the CredSSP channel
```

## The fix

Remove the stripping entirely. Pass `requestedProtocols` through unchanged.

The original compatibility concern — older servers rejecting HYBRID_EX — turned out to be unwarranted in practice. Modern `mstsc` has been sending HYBRID_EX for years and servers handle it gracefully: if they don't support it they simply select a lower mode in the CC. The server's CC is the right place for that negotiation to happen, not a proxy in the middle.

## What to check if you hit this

If you're seeing 0x609 only through a proxy and direct connections work:

1. **Capture both sides of the relay.** You want the raw bytes the server sees, not the bytes the client sent. Log the first frame in each direction.

2. **Find the X.224 CC and read `selectedProtocol`.** It's a 4-byte little-endian value a few bytes into the CC. If it differs between direct and proxied connections, the proxy is rewriting the CR.

3. **Check for any transformation applied to the first message.** Header parsers, encoding normalizers, protocol fixups — anything that touches the first frame of a new TCP connection is a candidate.

4. **Compare `requestedProtocols` in the CR.** If the proxy is changing the bitmask, restore it to pass through verbatim and retest.

The broader principle: a byte-stream proxy should be transparent. Any transformation that modifies the protocol negotiation — even a seemingly harmless bit-clear — can break assumptions downstream that neither the proxy nor its author can fully anticipate.

The server, not the proxy, decides which protocol variant to use. Let it.


382e2999388b1e72bcf9d4247ef23ebd4cbf4a713c088c0f858abd20ba469856

How we debugged RDP error 0x609 appearing only through a WebSocket proxy, and why stripping the HYBRID_EX bit from the protocol negotiation breaks the entire session.

A CredSSP 0x609 error appearing only through a proxy but not on direct connections — traced to a single HYBRID_EX bit being silently stripped from the RDP X.224 handshake.

Debugging RDP 0x609: The Protocol Bit a Proxy Should Never Touch


{/* banner prompt: Of course! Here are three creative and engaging prompts for a banner image, each with a different artistic direction but all reflecting the core theme of the blog post.

---

### Prompt 1: The Beacon in the Void

This prompt uses a dramatic, cinematic approach to visualize the problem and solution as a source of light in darkness.

**Prompt:**
```
A cinematic, photorealistic image of a vast, dark, digital abyss representing a system failure. In the center, a single computer monitor floats, its screen pitch black except for the faintly glowing, ominous text "Please Wait...". From the top right corner, a powerful, clean beam of light, symbolizing a Windows update, descends and strikes the monitor. Where the light hits, the black screen begins to dissolve, revealing a vibrant, fully-loaded Windows desktop underneath. The light is composed of tiny, flowing data particles and the iconic circular update arrows. Moody, dramatic lighting, deep shadows, and a strong contrast between the dark void and the bright, hopeful light. --ar 16:9
```
**Why it works:** This prompt creates a powerful metaphor. The "black screen" is an empty void, and the "Windows Update" is a literal beacon of hope and functionality, cutting through the darkness to restore the system. It's visually striking and tells the story of the blog post in a single image.

---

### Prompt 2: The Digital Locksmith

This prompt takes a more conceptual, cyberpunk-inspired approach, framing the problem as a lock and the solution as the key.

**Prompt:**
```
A sleek, futuristic digital art piece. An IT professional is seen from behind, facing a massive, impenetrable digital wall that glows with a faint grid pattern. The wall has a single line of text embedded in it: "Please Wait". In the professional's hand is a glowing, holographic key forged from the Windows logo and circuitry patterns. They are about to insert this "update key" into a barely visible keyhole on the wall, causing cracks of bright blue light to emanate from the insertion point, ready to shatter the barrier and reveal the bright, working remote desktop behind it. Cyberpunk aesthetic with neon blues, blacks, and whites. --ar 16:9
```
**Why it works:** This prompt personifies the solution. The update isn't just a process; it's the "key" that the IT professional uses to unlock the problem. It highlights the user's frustration (the impenetrable wall) and the simple, elegant power of the solution (the key).

---

### Prompt 3: The System Corruption and Repair

This prompt visualizes the issue from a high-tech, schematic point of view, perfect for a more technical audience.

**Prompt:**
```
A high-tech, holographic schematic of a computer's system architecture, rendered in glowing blue and green lines against a dark background. A critical section labeled "RDP Service" is shown as dark, corrupted, and glitching, with a red "Please Wait" error message flickering nearby. From a main system node labeled "Windows Update Core," a clean, flowing stream of pristine data particles travels along the circuits to the corrupted RDP section. As the data arrives, it purges the corruption, turning the dark, glitching lines back to a healthy, vibrant blue, fixing the error in real-time. Style of an advanced UI display, sharp focus, depth of field. --ar 16:9
```
**Why it works:** This prompt appeals directly to a technical understanding of the problem. It visualizes the "pending update" as a form of system corruption or inconsistency that the update process actively "repairs." It’s a clean, modern, and intelligent way to represent the blog post's main idea. */}

If you've ever tried to connect to a Windows machine via RDP only to be greeted by an endless black screen displaying "Please Wait," you know how frustrating this can be. The good news? It could be an easy fix.

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/02/rdp-please-wait-black-screen-a-simple-fix/please-wait.png)

In my case the target Windows machine has pending system updates that require installation or a restart to complete. Windows Update can interfere with the RDP service's ability to properly initialize the desktop environment, leaving users stranded at the "Please Wait" screen.

## The Simple Solution: Windows Updates

No matter how much we don't want to, but we have to: **update Windows**.

### Step-by-Step Fix

#### Option 1: Physical or Local Access

If you have physical access to the machine:

1. **Log in locally** to the Windows machine experiencing the RDP issue
2. **Check for Windows Updates**:
   - Press `Windows + I` to open Settings
   - Navigate to "Update & Security"
   - Click "Check for updates"
3. **Install all available updates**
4. **Restart the machine** when prompted
5. **Test RDP connection** after the restart completes

#### Option 2: Command Line Approach

If you have limited access but can run commands:

```shell
# Check for updates using PowerShell
Get-WindowsUpdate

# Install updates (requires PSWindowsUpdate module)
Install-WindowsUpdate -AcceptAll -AutoReboot

# Alternative: Use Windows Update command line
UsoClient StartScan
UsoClient StartDownload
UsoClient StartInstall
```

#### Option 3: Group Policy Method

For domain environments:

```shell
# Force Group Policy update
gpupdate /force

# Trigger Windows Update check
wuauclt /detectnow /updatenow
```

### Verification Steps

After applying updates and restarting:

1. **Test RDP connectivity**:
   ```shell
   # Test RDP port connectivity
   telnet target-machine-ip 3389
   ```

2. **Check RDP service status**:
   ```powershell
   # Verify Remote Desktop Services are running
   Get-Service -Name "TermService"
   Get-Service -Name "UmRdpService"
   ```

3. **Verify Windows Update status**:
   ```powershell
   # Check for pending updates
   Get-WindowsUpdate
   
   # Check update history
   Get-WUHistory | Select-Object Date, Title, Result
   ```



9e362af613eefa3f6ac31621c3de02c39258939f9572d02f57ca4c7930aaf05a

Struggling with RDP showing a black 'Please Wait' screen? Learn how pending Windows updates cause this issue and get the simple fix.

Fix RDP black screen with 'Please Wait' message by updating Windows - a simple solution that works.

Tag: Rdp

Tag: Rdp

Debugging RDP 0x609: The Protocol Bit a Proxy Should Never Touch

RDP 'Please Wait' Black Screen? A Simple Fix