Microsoft spent about a week undoing damage its own security team had shipped. On September 14, it pushed out six separate out-of-band updates to fix a Remote Desktop Services deadlock that its regular September patches had quietly introduced days earlier, one bad enough that IT teams were hard-resetting production terminal servers to get logins working again.

  • Six emergency fixes landed the same day: KB5129195 and KB5129194 for Windows 11, KB5129236 for Windows 10, and KB5129235, KB5129237, KB5129238 for Windows Server 2025, 2022 and 2019.
  • The bug is a deadlock, not a crash: a sign-out call inside the Remote Desktop session host hangs waiting on the Local Session Manager, which is waiting right back, so the server never finishes tearing down the old session and can't start new ones.
  • Microsoft's own fix notes confirm the blast radius went beyond RDP: the Microsoft Management Console, the RDS Licensing Diagnoser, File Explorer, and even the Windows Update page itself could freeze on an affected box.
  • Server admins don't get this one through routine Windows Update. The Server 2019, 2022 and 2025 fixes ship through the Microsoft Update Catalog only, so somebody has to go find and install them by hand.
How the September patch turned a sign-out into a deadlockA sign-out call inside the Remote Desktop session host, RDPSERVERBASE calling WDLIB_Close, hangs waiting on the Local Session Manager. The Local Session Manager is waiting on the same call. Neither finishes, so new sign-in attempts queue up and fail until the server is rebooted.THE DEADLOCKUser signsout of RDPRDPSERVERBASE callsWDLIB_Close()Local SessionManager (LSM)waits, foreverNew sign-inattempts arriveHang, then failuntil a hard resetFix: out-of-band KB5129195 / KB5129237 / KB5129238 (Sept 14) breaks the lock.genztech.blog
Fig 1 The sign-out call and the session manager end up waiting on each other. Nothing crashes, the server just stops answering.

What actually broke on September 8?

Microsoft's regular monthly security updates for that Tuesday, KB5122871 on Windows Server 2025 and KB5122882 on Windows Server 2022 among them, shipped with a regression in how Remote Desktop Services tears down a session. Nothing failed immediately. Reports started surfacing around September 10, and they read the same way across different environments: RDP works fine right after the patch, then gets worse over hours or days as sessions pile up. One admin summed it up on a support forum: it works initially, but after the first log-off, the service crashes and no further users can sign in. Another described every terminal server in their environment failing within a day, with a hard reset as the only way back in.

RelatedMicrosoft Fixes Teams and Outlook Crashes on ARM Windows PCs

Why does a security patch turn into a login deadlock?

Because the bug sits in a lock, not in a crash path. Community debugging traced the hang to RDPSERVERBASE!WDLIB_Close, a call the session host makes while a user disconnects. Instead of releasing cleanly, that call blocks on the Local Session Manager, the Windows component that actually owns sign-ins and sign-outs. LSM, in turn, is waiting on the same handle the session host is holding. Neither side backs off. That is a textbook deadlock, and it explains why the failure mode looks so strange from the outside: the server is technically running, Task Manager shows nothing on fire, but the one thing a terminal server exists to do, accept a new remote session, quietly stops working. Related tools that also touch session state, the RDS Licensing Diagnoser, MMC snap-ins, even File Explorer, can freeze the same way because they're waiting on the same locked resource.

Which systems are hit, and how do you actually get the fix?

SystemBroke onFixHow to get it
Windows Server 2025KB5122871KB5129235Microsoft Update Catalog
Windows Server 2022KB5122882KB5129237Microsoft Update Catalog
Windows Server 2019KB5122876KB5129238Microsoft Update Catalog
Windows 11 24H2 / 25H2Sept. cumulative updateKB5129195Windows Update, WSUS, Catalog
Windows 11 26H1Sept. cumulative updateKB5129194Windows Update, WSUS, Catalog
Windows 10 21H2 / 22H2Sept. cumulative updateKB5129236Windows Update, WSUS, Catalog

The split matters in practice. Windows 11 machines will pick up their fix through normal Windows Update or WSUS without anyone lifting a finger. Every affected Windows Server SKU, the exact machines running the terminal servers people were rebooting by hand, only gets the patch if an admin pulls it from the Catalog themselves. If nobody on the team owns that task this week, the deadlock is still sitting there waiting for the next reboot cycle to trigger it again.

  1. Sep 8Routine monthly security updates ship for Windows Server 2019/2022/2025 and Windows 10/11.Introduces the RDS regression
  2. Sep 10Admins start reporting RDP sign-in failures and unresponsive terminal servers.First public reports
  3. Sep 11-12Microsoft acknowledges the issue, says it's investigating, offers no workaround.No fix yet
  4. Sep 14Six out-of-band updates ship across every affected OS, fixing the deadlock.Emergency patch

Why did this take six days to fix?

Coordinating six separate out-of-band builds across three server releases and three client releases isn't a same-day job even once engineering has a root cause, and Microsoft still had to reproduce a bug that only shows up after a session has been open and torn down under real load, not in a quick smoke test. That's the harder problem for any monthly patch cycle: a deadlock like this one doesn't announce itself in the hours after release. It shows up after the update has already reached fleets of production servers, which is exactly what happened here. Six days from first reports to a coordinated six-KB release is fast by the standards of a cross-SKU regression, even if it never should have shipped in the first place.

RelatedWindows 10 KB5099539 ESU Update Has a Networking Catch

What should IT teams do now?

Check Windows Update history on every affected server rather than assuming the fix arrived on its own. For Server 2019, 2022 and 2025, that means pulling the specific KB for that SKU from the Microsoft Update Catalog and testing a sign-out on a low-priority session before pushing it fleet-wide; confirming the session actually closes cleanly is the real test here, not just that the installer finished. Anyone who already rolled back September's original update to stop the bleeding should reinstall the September baseline and the out-of-band fix together, not skip straight to October, since the out-of-band builds are cumulative on top of the update they're patching.

Our take

Remote Desktop Services is not a fringe feature. It's the thing enterprise IT, healthcare systems and no small number of government agencies use to let staff work at all, and a patch that quietly deadlocks it under real load is a serious regression test gap, not a minor rough edge. Microsoft's six-day, six-KB turnaround shows the incident response machinery works once a bug like this is confirmed. The bigger question is why a change to session teardown logic didn't get caught against a realistic sign-out-under-load scenario before it shipped to every supported Windows Server release at once. That's a testing question, not a triage question, and it's the one worth watching for whether it actually changes anything before October's updates go out.

What to watch · Sept-Oct 2026
  • Manual installs lag. Catalog-only distribution to servers means a meaningful share of affected machines will still be running the broken update weeks from now.
  • October's cumulative baseline. Whether Microsoft folds this fix cleanly into next month's regular update or admins have to keep tracking a separate out-of-band chain.
  • Any similar deadlock reports elsewhere. Session-teardown code is shared across other Windows session-hosting paths; a second report in a different subsystem would suggest the regression is broader than RDS alone.
Primary sources

Original analysis by GenZTech. Source: BleepingComputer.