Terminal Server Hangs After the September Windows Update: An Incident Breakdown With Dumps

The terminal server stopped letting people in. A security update was to blame.

On 14 September 2026 at 14:00, a client's terminal server stopped accepting new connections. Users already working kept working. New sessions hung at the "Please wait for the Remote Desktop Configuration" screen and went no further.

Task Manager would not open. A normal restart never completed: the shutdown command simply hung. Only a hard reset through the hypervisor brought the server back. The next morning it happened again, then again, this time half an hour after boot. The interval between failures kept shrinking.

Two days later the exact same picture appeared on a completely different client's server. Different companies, different software, different infrastructure, and an identical failure. That is what led us to the real cause.

What follows is the full breakdown: how to recognise the problem, the false leads we chased, what the process dumps captured at the moment of the hang actually showed, and how to fix it.

How to recognise the problem

• New RDP connections hang at "Please wait for the Remote Desktop Configuration" or at the welcome stage

• Existing sessions keep working but cannot log off cleanly

• Task Manager does not open

• The qwinsta command, MMC, RDS Licensing Diagnoser and sometimes File Explorer stop responding

• A normal restart does not go through, only a hard reset recovers the host

• The System log fills with event 7011: a timeout of 30000 ms waiting for NlaSvc, iphlpsvc and UmRdpService

One PowerShell command checks for the events:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=7011; StartTime=(Get-Date).AddHours(-24)} |
    Select-Object TimeCreated, @{n='Service'; e={ ($_.Message -replace '\s+',' ') }} | Format-Table -Wrap

A telltale sign: the events come in pairs exactly 30 seconds apart.

The false leads we chased

We are telling this honestly, because it is more useful than a tidy success story. Finding the cause took two days, and most of that time went into theories that turned out to be wrong.

Checked and ruled out: free space on the datastores and guest disks, hypervisor resources, VM snapshots, storage performance, DNS, domain controller availability, RDS licensing, IPv6, the IP Helper service, the shadow copy subsystem, WMI repository size, handle and kernel pool leaks.

We also investigated a backup agent that was creating looping WMI subscriptions failing with a cancellation error. The theory looked convincing, but the problem returned after the agent was fully disabled.

The migrating symptoms were misleading too. One time the server hung starting Windows Search, another time loading a user profile, a third time on the RDS configuration. It looked as if something shared underneath all the services was breaking.

The turning point. The same picture appeared on another client's server. One machine could break for its own reasons. Two independent ones running different software, hardly. Only one thing was common: both had received the same set of September updates.

What the dumps revealed

Rather than keep guessing, we set up a monitor that checks system responsiveness every minute and automatically captures dumps of the key services at the first sign of a hang. The next time round it fired at 11:03:46, six seconds before the first 7011 event hit the log. Dumps of three services, TermService, SessionEnv and UmRdpService, caught the very beginning of the failure.

We then opened them in the cdb console debugger with symbols from Microsoft's servers. The RDPSERVERBASE.dll version in the dump: 10.0.20348.5622, exactly the build that carries the regression.

Automatic analysis sends you down the wrong path

The first thing most administrators do is run the automatic analysis. So did we:

!analyze -v -hang

The debugger pointed at thread 68c with the stack sechost!ScSendResponseReceiveControls and recorded that as the failure bucket. It is a false lead. That is what an ordinary service dispatcher thread looks like while it waits for SCM commands as designed. The real culprit only shows up in the full thread listing via ~*k.

The blocked thread

In the TermService process (svchost, PID 1672), exactly one of 125 threads is blocked: number 111. Here is its stack, verbatim from the debugger:

ntdll!NtWaitForAlertByThreadId+0x14
ntdll!RtlpWaitOnAddressWithTimeout+0x9f
ntdll!RtlpWaitOnAddress+0xd8
ntdll!RtlWaitOnAddress+0x13
RDPSERVERBASE!WDLIB_Close+0x98
RDPSERVERBASE!CRDPWDUMXStack::WDCloseStack+0x12a
RDPSERVERBASE!CRDPWDUMXStack::OnIcaCommand+0x3dc
RDPSERVERBASE!CRDPWDUMXStack::WDCallback_IcaChannelInput+0x131
RDPSERVERBASE!WDICART_IcaChannelInput+0x1f
RDPSERVERBASE!ShareClass::DCS_ReceivedShutdownRequestPDU+0x17c
RDPSERVERBASE!ShareClass::SC_OnDataReceived+0x2f4

Read it bottom to top. The client sent a session shutdown packet, that is the DCS_ReceivedShutdownRequestPDU line. The server began tearing down the session driver stack, that is WDCloseStack. And it got stuck inside WDLIB_Close on a call to RtlWaitOnAddress.

A wait with no timeout

Disassembling the function itself reveals the mechanics of the defect. Before the wait, an internal feature flag is checked, and the fourth argument to RtlWaitOnAddress, the timeout, is zeroed out with an xor instruction:

call  RDPSERVERBASE!wil::details::FeatureImpl<__WilFeatureTraits_Feature_3802373433>::__private_IsEnabled
test  al,al
je    RDPSERVERBASE!WDLIB_Close+0xa7   ; flag off, the wait is skipped
...
xor   r9d,r9d                          ; Timeout = NULL, wait forever
lea   rdx,[rsp+40h]
mov   rcx,rdi
lea   r8d,[r9+4]
call  qword ptr [RDPSERVERBASE!_imp_RtlWaitOnAddress]

NULL in the timeout field means an unbounded wait. The thread will sit there until something wakes it, and nothing will.

And since the thread in the dump sits past the je branch, we know for certain the flag was enabled on this server. That is not an assumption, it is the execution path.

The detail that closes the loop. The flag in the code carries the identifier 3802373433. That is the same number used in Microsoft's Known Issue Rollback mechanism. The binary itself points at the switch the vendor uses to disable the defect.

Why one thread takes down the whole server

A single hung thread is nothing on its own. The problem is that it had already acquired the session object's critical section and will never release it. The debugger confirms: the section at 0x21ff13f2fc0 is locked, lock count 2, owner thread c030, the same number 111.

Session state changes in Windows are processed serially, one after another. So the next logoff waits for the previous one. The SessionEnv dump makes this plain: of its 32 threads, 24 sit in the logoff handler, each stuck in WinStationEnumerateW waiting for a reply from TermService over ALPC. That is the very function qwinsta calls, which is why it stopped responding.

Once the SessionEnv thread pool is exhausted, the service can no longer configure a single new session. That is exactly why new connections stalled at "Please wait for the Remote Desktop Configuration".

Plain data confirms the picture without a debugger. In the process snapshot, 25 sessions hang with an identical set: LogonUI, dwm, fontdrvhost, winlogon. No explorer, no user applications. The log had already reported a successful logoff, yet the sessions were physically alive two minutes later.

The third dump, UmRdpService, shows the scale of the fallout. The service itself is blocked on nothing; it simply still has live device redirection loops for sessions that formally no longer exist. It faithfully serves printers and drives for users who left five minutes ago, because nobody told it to stop.

This also answers why restarting the service and shutting down normally never helped. You cannot stop TermService while it holds a thread in an unbounded wait. The Service Control Manager waits for a reply, never gets one, and the shutdown sequence stops at that exact point. A hard reset is all that is left.

Resources had nothing to do with it

It is worth noting what the dumps do not show. At the moment of failure: 80 GB of 96 free, 277 processes, 132 thousand handles, 4448 threads. For comparison, a healthy server under full load carried three times as many handles. No leaks, no kernel pool exhaustion. Every service in the Running state, all of them simply stuck.

There is one cause and it is pinpoint: a wait call with no timeout in the session teardown code.

The actual cause

The September cumulative security update KB5122882 for Windows Server 2022 (build 20348.5622) contains a regression in Remote Desktop Services. Microsoft has officially acknowledged the issue. It affects more than Windows Server 2022:

Reports came in simultaneously from many unrelated organisations worldwide.

The fix: out-of-band update

On 14 September Microsoft released out-of-band updates that address the regression:

Important. These updates are cumulative and already include everything from the September package. Removing the faulty update beforehand is neither necessary nor advisable: a rollback would also strip the security patches.

The fix usually does not arrive through Windows Update. Download it manually from the Microsoft Update Catalog.

Installation, step by step

1. Check your current build

(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').UBR

If Server 2022 reports 5622, you are on the faulty version.

2. Install via DISM, not the standard installer

This is a practical tip from our experience. On an affected server, the standard wusa.exe installer can hang at the preparation stage and sit there for hours. That is exactly what happened to us: the processes idled at zero CPU and the CBS log stopped growing.

The reliable route is to expand the package and install the .cab through DISM:

mkdir C:\INSTALL\kb5129237
expand -F:* "C:\INSTALL\windows10.0-kb5129237-x64_HASH.msu" C:\INSTALL\kb5129237
dism /Online /Add-Package /PackagePath:"C:\INSTALL\kb5129237\Windows10.0-KB5129237-x64.cab" /NoRestart

Gotcha. DISM will not take a .msu file directly and returns error 0x80070032. It needs the .cab extracted from it with the expand command. One more quirk: the progress bar may freeze at a few percent and then jump straight to a success message. That is normal.

3. Reboot and verify

Confirm the system is waiting for a restart:

Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'

After boot the system finishes installing the package on the loading screen, which can take 10 to 20 minutes. Do not interrupt it. Then verify:

(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').UBR
Get-HotFix -Id KB5129237

The build should now read 5631. Most importantly, test new logons rather than reconnections to existing sessions. The failure only showed up on new sign-ins.

Temporary workaround if you cannot patch right now

Microsoft also published a Known Issue Rollback deployed through Group Policy. For Windows Server 2022 it is policy 260911_18471, applied under Computer Configuration, Administrative Templates. In effect it turns off the very feature flag we saw in the disassembly.

This is a workaround, not a fix. If you can install the out-of-band update, do that instead: it is more reliable. Anyone who already applied the policy can install the update on top of it with no extra steps.

What we took away from this

A symptom that migrates between services is a reason to suspect a common denominator. When one subsystem hangs, then another, and each is healthy on its own, the answer is not in any of them.

A second identical failure on an independent system beats a dozen tested theories. That is what moved us from guesswork to the right answer.

Check recent updates before you take the configuration apart. We got there on day two, when we could have on hour one. All it took was comparing the time of the first failure against the update installation log.

Automatic dump capture at the moment of failure is worth half an hour of setup. A simple script that checks responsiveness every minute and grabs dumps at the first sign of a hang gave us a definitive answer where two days of manual investigation produced only theories.

FAQ

How do I quickly tell whether this is my problem?

Two checks. Look at your build number: for Server 2022 the faulty one is 20348.5622. Then check the System log for event 7011 from NlaSvc and iphlpsvc arriving in pairs 30 seconds apart. If both match, it is the same case.

Can I just uninstall the faulty update?

Technically yes, but you should not. A rollback removes every September security patch, including fixes for critical vulnerabilities. The out-of-band update is cumulative: it installs on top and contains everything you need.

Does this affect ordinary workstations?

The symptom shows up on servers with the Remote Desktop Services role. Microsoft released out-of-band updates for client versions of Windows as well, but there were no widespread reports of workstations hanging.

How long does installing the fix take?

The DISM installation itself takes 20 to 40 minutes, plus a reboot with post-install processing of another 10 to 20 minutes. Plan for roughly an hour and warn users in advance.

Why did rebooting only help for a while?

Because the defect triggers during session teardown. After a reboot the server runs fine until the first session fails to close. The more users, the sooner that happens. In our case the interval shrank from a day to a few minutes.

Can I reproduce this analysis myself?

Yes. You need procdump from the Sysinternals suite and the cdb console debugger from the Debugging Tools for Windows component. Capture a dump with procdump64.exe -accepteula -ma dump.dmp, open it with cdb.exe -z dump.dmp -y "srv*C:\symbols*https://msdl.microsoft.com/download/symbols", then run ~*k to list every thread stack. The graphical WinDbg from the Microsoft Store does not ship cdb, you need the SDK component.

If you are seeing the same thing

We support terminal servers, virtual infrastructure and business networks in Odesa and across Ukraine. If your RDS host behaves the way described here, get in touch: we will point you in the right direction or take the work on.

The check takes a minute. Look at your build number and the 7011 events in the log. If the symptoms match, you have the same case, and the fix already exists.

Sources

• Microsoft Support, KB5122882 (OS Build 20348.5622), known issues section

• Microsoft Support, KB5129237 (OS Build 20348.5631), out-of-band update of 14.09.2026

• Microsoft Learn, Windows Server 2022 known issues and notifications

• Our own analysis of TermService, SessionEnv and UmRdpService dumps captured on 16.09.2026 at 11:03