Windows-Update September 2026: RDS hängt, "Citrix bleibt schwarz"

Ein Terminalserver startet neu, läuft ein paar Stunden völlig unauffällig und bleibt dann stehen. Neue Verbindungen hängen bei „Verbinden…“. Angemeldete Nutzer kommen nicht mehr raus. Der Explorer reagiert nicht, die MMC reagiert nicht, Windows Update reagiert nicht. Was hilft, ist ein harter Reset. Ein paar Stunden später steht der Server wieder.

Das ist kein Zufall und kein Kapazitätsproblem. Das sind die Sicherheitsupdates vom 8. September 2026.

Microsoft hat am 14. September außer der Reihe nachgeliefert. Und damit fängt der eigentlich interessante Teil an: Das Out-of-Band-Update behebt einen der beiden Fehler, nicht beide. Wer es einspielt, den Haken setzt und weitergeht, hat in Citrix-Umgebungen gute Chancen, am nächsten Morgen wieder am Telefon zu sitzen.

Zwei Fehler, die ständig verwechselt werden

Es kursieren zwei völlig verschiedene Störungsbilder unter derselben Überschrift „September-Update kaputt“. Sie haben unterschiedliche Ursachen, unterschiedliche Symptome und unterschiedliche Lösungen. Wer sie nicht auseinanderhält, spielt das falsche Update ein.

	Fehler A: der RDS-Hänger	Fehler B: der schwarze Bildschirm
Wo	Session-Hosts, Server-OS	Desktop-OS-VDAs, Windows 11 24H2/25H2
Wann	Stunden nach dem Neustart	sofort bei jeder Anmeldung
Bild	hängt bei „Verbinden…“, keiner kommt raus	Anmeldung klappt, dann nur schwarz
Spur	`TermService` steht auf `StopPending`	`explorer.exe` fehlt im Prozesslisting
Behoben?	Ja, Out-of-Band vom 14.09.	Nein, Stand 16.09.2026 offen

Merke dir die letzte Zeile. Sie ist der Grund, warum dieser Beitrag existiert.

Fehler A: Der RDS-Hänger

Das Symptom

Der Server läuft nach dem Neustart normal. Nach einigen Stunden verschlechtert sich der Zustand nicht langsam, sondern schlagartig:

Neue RDP-Sitzungen bleiben bei „Verbinden…“ stehen, teilweise bei „Warten auf die Remotedesktopkonfiguration“
Angemeldete Nutzer können sich nicht abmelden und nicht trennen
Explorer, Task-Manager, Einstellungen und MMC hängen
Der Dienst TermService steht auf StopPending statt auf Running
Ein sauberer Neustart schlägt fehl, weil der Dienst nicht beendet werden kann

Im Protokoll stehen zwei Signaturen:

Protokoll	ID	Bedeutung
`TerminalServices-RemoteConnectionManager`	20498	„Remote Desktop Services has taken too long to complete the client connection“
`Winlogon`	6005	„The winlogon notification subscriber SessionEnv is taking long time to handle the notification event (Disconnect)“

Das Ereignis 6005 mit SessionEnv und Disconnect ist der eigentliche Fingerabdruck. Es steht zeitlich vor dem Vollbild, nicht danach.

Warum es passiert

Die technische Analyse, die derzeit die Runde macht, beschreibt Folgendes: Beim Abbau einer Sitzung ruft die Routine WDLIB_Close in RDPSERVERBASE die Funktion RtlWaitOnAddress auf, und zwar ohne Zeitüberschreitung, sobald ein internes Funktionsmerkmal mit der Nummer 3802373433 aktiv ist. Der Thread wartet damit unbegrenzt.

Der entscheidende Punkt kommt danach.

Der Local Session Manager serialisiert alle Änderungen am Sitzungszustand über einen einzigen kritischen Abschnitt.

Ein Thread, der dort unbegrenzt wartet, hält also nicht nur seine eigene Sitzung auf. Er blockiert jede weitere Zustandsänderung auf dem Host: jede neue Anmeldung, jede Abmeldung, jede Anfrage des Brokers.

Und genau das erklärt das Zeitverhalten, über das sich alle wundern. Der Server ist nicht „langsam geworden“. Er hatte irgendwann die erste Sitzung, die getrennt wurde, und ab diesem Moment war er hinter einer Tür, die nie wieder aufgeht. Bis dahin lief alles, weil noch niemand an dieser Tür stand.

Der Ausfall beginnt nicht beim Neustart. Er beginnt bei der ersten getrennten Sitzung.

Das ist auch der Grund, warum es Testumgebungen so zuverlässig überlebt: Wer nach dem Patchen einmal verbindet, kurz schaut und die Sitzung offen lässt, sieht nichts. Der Fehler braucht eine beendete Sitzung.

Diese Ursachenbeschreibung stammt aus externer Analyse und ist von Microsoft nicht in dieser Form bestätigt. Das beobachtete Verhalten deckt sich damit. Unbestätigt bleibt die Zuordnung zur Funktionsnummer.

Welche Updates es auslösen

Ausgeliefert am 8. September 2026:

Betriebssystem	KB	Build
Windows Server 2016	KB5123099
Windows Server 2019	KB5122876
Windows Server 2022	KB5122882	20348.5622
Windows Server 2025	KB5122871	26100.33438
Windows 11 24H2 / 25H2	KB5124008
Windows 11 22H2 / 23H2	KB5122880
Windows 10 21H2 / 22H2 (ESU)	KB5122878	19044.7725 / 19045.7725

Wie du prüfst, ob es dich betrifft

Drei Abfragen, dreißig Sekunden. Die erste ist die wichtigste, weil sie vor dem Vollbild anschlägt:

# 1. Der Fingerabdruck im Protokoll: Winlogon 6005 mit SessionEnv
Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Microsoft-Windows-Winlogon'
    Id           = 6005
    StartTime    = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Where-Object { $_.Message -match 'SessionEnv' } |
    Select-Object TimeCreated, Id, Message -First 20

# 2. Der Dienstzustand: 'StopPending' ist der Beweis
Get-CimInstance Win32_Service -Filter "Name='TermService'" |
    Select-Object Name, State, Status, ProcessId

# 3. Welches Kumulativupdate liegt auf dem Host?
Get-HotFix | Where-Object { $_.HotFixID -match 'KB512(2871|2876|2882|3099|4008|2880|2878)' } |
    Select-Object HotFixID, InstalledOn

Ereignis 20498 allein sagt wenig, denn es tritt auch bei ganz normaler Überlast auf. Die Kombination 6005/SessionEnv/Disconnect plus StopPending ist eindeutig.

Wie du es löst

Der Weg, der zählt: das Out-of-Band-Update vom 14. September 2026. Es behebt die Ursache dauerhaft, ohne Registry-Bastelei und ohne Rücknahmeverfahren.

Betriebssystem	Out-of-Band-KB	Build
Windows Server 2025	KB5129235	26100.33451
Windows Server 2022	KB5129237	20348.5631
Windows Server 2019	KB5129238	17763.9247
Windows Server 2016	KB5129239	14393.9514
Windows Server 2012 R2 / 2012	KB5129243 / KB5129244
Windows 11 26H1	KB5129194
Windows 11 24H2 / 25H2	KB5129195 (Hotpatch: KB5129241)
Windows 11 23H2	KB5129242
Windows 10 21H2 / 22H2	KB5129236

Die Pakete liegen im Microsoft Update Catalog und werden mit wusa.exe eingespielt. Danach neu starten und die Protokolle 24 bis 48 Stunden weiter beobachten. Der Fehler braucht Zeit, um sich zu zeigen; ein Host, der eine Stunde nach dem Patchen ruhig ist, beweist gar nichts.

Wenn du nicht sofort patchen kannst, gibt es zwei Behelfe, beide schlechter:

Known Issue Rollback per Gruppenrichtlinie. Microsoft hat den KIR (Known Issue Rollback) am 13. September bereitgestellt und den Fehler damit als „gemindert“ markiert. Setzt passende Lizenzierung voraus und braucht auf den Zielsystemen ebenfalls einen Neustart.
Das Funktionsmerkmal per Registry abschalten, unter HKLM:\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\4\3802373433 den Wert EnabledState (DWORD) auf 1. Dieser Weg war der erste, der kursierte, und er hat sich als unzuverlässig erwiesen. Er wirkte nicht auf allen Builds. Nimm ihn nur, wenn die beiden anderen Wege ausscheiden.

Was du nicht tun solltest: das September-Update deinstallieren.

Der September-Patchday hat CVE-2026-69525 geschlossen, eine Use-after-free-Lücke in genau diesen Remotedesktopdiensten, CVSS 9.8, Codeausführung über das Netz, ohne Anmeldung und ohne Zutun eines Nutzers. Microsoft stuft die Ausnutzung als „Exploitation More Likely“ ein. Im selben Paket stecken zwei Zero-Days, die bereits aktiv ausgenutzt wurden.

Wer das Update entfernt, tauscht einen Dienstausfall gegen eine offene Lücke im selben Dienst. Der Rückbau per DISM ist ein Notnagel für einen bereits verklemmten Host, den du nicht mehr erreichst. Für den Bestand ist er kein Verfahren.

Fehler B: Der schwarze Bildschirm in Citrix-Umgebungen

Das Symptom

Die Anmeldung läuft durch. Die Sitzung wird aufgebaut, die Authentifizierung ist erfolgreich, und dann kommt nichts. Kein Desktop, keine Taskleiste, keine Symbole. Nur schwarz.

Der Task-Manager lässt sich öffnen. Und dort sieht man es: explorer.exe läuft nicht. Startet man den Prozess von Hand, ist der Desktop sofort da.

Die Sitzung ist also gesund. Es fehlt nur die Shell.

Wen es trifft

Desktop-OS-VDAs unter Windows 11 24H2 und 25H2
Ausgelöst durch KB5120998 (Vorschau vom 27.08.) und KB5124008 (Patchday, 08.09.)
Berichtet aus Umgebungen mit Citrix UPM, FSLogix, ProfileUnity ProfileDisks und VMware Horizon. Die Profilcontainer-Technik ist also wohl nicht die Ursache, sondern nur das gemeinsame Merkmal der betroffenen Umgebungen
Auch frisch angelegte Profile sind betroffen. Das räumt die naheliegendste Erklärung ab: Es ist kein kaputtes Profil

Und jetzt der Punkt

KB5129195 behebt das nicht.

Das Out-of-Band-Update vom 14. September ist für Fehler A gemacht: Remotedesktopdienste, Audio, Hyper-V. Der schwarze Bildschirm in virtualisierten Desktops ist zum Stand 16.09.2026 weder von Microsoft noch von Citrix behoben.

Citrix führt beide Störungen unter CTX697101 und verweist für Fehler A auf dieselben Out-of-Band-Pakete. Für Fehler B steht dort bislang kein Lösungsweg.

Was bleibt, sind Behelfe, und man sollte sie auch so nennen:

Das Golden Image nicht weiterreichen. Der wirksamste Schritt. Solange die Updates nicht im produktiven Abbild sind, hast du das Problem nicht.
Ein Anmeldeskript, das prüft, ob explorer.exe in der Sitzung läuft, und es andernfalls startet. Behandelt das Symptom zuverlässig, bleibt aber ein Pflaster.
AppX-Pakete neu registrieren. Wird berichtet, wirkt uneinheitlich und kann weitere Probleme nach sich ziehen. Würde ich lassen.

Wichtig für die Erwartungshaltung im eigenen Haus: Fehler B trifft Desktop-OS-VDAs. Wer seine veröffentlichten Anwendungen auf Server-OS betreibt, ist von A betroffen und von B nicht. Wer beides fährt, braucht zwei getrennte Maßnahmen, und das ist der Fall, in dem die meiste Zeit verloren geht.

Was du dir merken solltest

Die September-Updates 2026 erzeugen zwei verschiedene Fehler. Der RDS-Hänger auf Server-OS beginnt nicht beim Neustart, sondern bei der ersten getrennten Sitzung, und er ist seit dem 14. September behoben. Der schwarze Bildschirm auf Desktop-OS-VDAs ist es nicht. Ein Haken hinter dem Out-of-Band-Update bedeutet also nicht, dass du durch bist. Er gibt dir maximal in Teilbereichen Entwarnung. Ausführliches Testen ist unerlässlich!

Stand dieses Beitrags: 16.09.2026. Fehler B war zu diesem Zeitpunkt offen. Änderungen an der Lage trage ich datiert am Kopf des betroffenen Abschnitts nach, statt den Text still zu korrigieren.