TermService hangs (RDP stuck at logon screen) after Sept 2026 updates – self-wait in RDPSERVERBASE!WDLIB_Close on Windows Server 2022 build 20348.5622

Environment • Azure Standard_B4ms VM running Windows Server 2022 Datacenter: Azure Edition 21H2 (build 20348.5622) • Updates installed 2026-09-18: KB5122881, KB5122882, KB5087424 • RDS session host for ~4 users on unstable WAN links, SQL Server local, workgroup (no domain)

Symptom TermService stays “Running” but no new RDP logon completes: TCP and NLA succeed, the session is created with only csrss.exe (no winlogon/LogonUI/dwm), and the client stays on the logon background. quser hangs and Azure Run Command hangs, while Serial Console works and the console lock screen keeps updating. Service Control Manager logs 7011 timeouts (300000 ms) for iphlpsvc and NlaSvc about 5 minutes after the hang starts. Killing the TermService svchost recovers RDP without rebooting. CPU, memory and disk metrics are normal.

Occurrences: 2026-09-24 (RDP unavailable from ~13:40 until a forced reboot at 19:09) and twice on 2026-10-02 (~09:30 and ~11:12); never before the Sept 18 updates.

Dump analysis (TermService svchost, 52 threads, second incident of 2026-10-02) Two threads are stuck with this stack:

OnReadCompleted → MCSIcaRawInputWorker → RecognizeMCSFrame → HandleAllSendDataPDUs → [dispatch] → SM_MCSSendDataCallback → SC_OnDataReceived → DCS_ReceivedShutdownRequestPDU → WDCloseStack → WDLIB_Close → RtlWaitOnAddress

• HandleAllSendDataPDUs, when Feature_MSRC121465 is enabled, does lock inc dword ptr [X+14h] before dispatching the PDU and calls MCSReleaseDispatchGuard afterwards. Both threads return to HandleAllSendDataPDUs+0x221, right after the indirect dispatch call, so they are inside the guarded dispatch. • WDLIB_Close, when Feature_3802373433 is enabled, loops while ((int)(X+0x14) > 0) RtlWaitOnAddress(X+0x14, &v, 4, NULL) with no timeout. • In the dump, the counter at X+0x14 is 1 for both threads, so each thread waits for its own dispatch guard: a re-entrant self-wait. • Each thread owns its CRDPWDUMXStack critical section (!cs -l -o: RecursionCount 2, two waiters each). Waiters confirmed via the wait address in RCX (CS + 8): SendHeartbeatPacket and CRemoteTerminal::DoTerminate → GetServerAutoReconnectInfo. • New connections hang in CDefaultConnectionHandler::FindUserSessionToReconnect waiting on an outbound LRPC call. • All frames are in Microsoft modules (termsrv, rdpcorets, rdpbase, RDPSERVERBASE).

Questions

1. Is this a known issue with the interaction between Feature_MSRC121465 and Feature_3802373433?
2. Is there a fix, a newer cumulative update, or a supported configuration to avoid it?
3. Is uninstalling any of the Sept 18 updates a recommended temporary mitigation?