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.	Ja, Oktober-Updates vom 13.10.2026 (Nachtrag 14.10.)

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:

1. 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.
2. 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

Nachtrag vom 14.10.2026: Fehler B ist behoben. Microsoft führt das bekannte Problem seit dem 13.10. als „Resolved“: Die Oktober-Updates beheben es, KB5127648 für Windows 11 24H2, 25H2 und 26H2 (Builds 26100.9711, 26200.9711, 26300.9711) und KB5127646 für 26H1 (Build 28000.3231). Mit diesen Updates ist der Known Issue Rollback aus dem Nachtrag vom 27.09. nicht mehr nötig. Wer ihn eingesetzt hat, nimmt die Einstellung im Abbild wieder zurück und verteilt das Abbild mit dem Oktober-Update neu. Citrix hat CTX697101 seit dem 25.09. nicht aktualisiert und verweist weiter auf den Eintrag bei Microsoft.

Nachtrag vom 27.09.2026: Behoben ist Fehler B weiterhin nicht. Aber Microsoft führt ihn seit dem 24.09. offiziell als bekanntes Problem für Windows 11 24H2, 25H2 und 26H1, Status „Mitigated“, und liefert dafür einen Known Issue Rollback per Gruppenrichtlinie. Damit gibt es einen Weg vom Hersteller, und er schlägt die Behelfe weiter unten.

Windows 11	Richtlinie
24H2 / 25H2 / 26H2	KB5124010 260924_20021 Known Issue Rollback
26H1	KB5124006 260924_20071 Known Issue Rollback

Das MSI bringt die Vorlage für die Gruppenrichtlinie mit. Aktivieren unter Computerkonfiguration > Administrative Vorlagen, danach braucht der Rechner einen Neustart. Genau da liegt die Falle bei nicht persistenten VDAs: Eine Richtlinie, die erst beim Start ankommt, wirkt erst nach dem nächsten Neustart, und den erlebt ein zurückgesetzter Desktop nie. Die Einstellung gehört deshalb ins Abbild, danach das Abbild neu verteilen.

Microsoft nennt als Umfeld Azure Virtual Desktop mit FSLogix, Citrix verweist in CTX697101 auf genau diesen Eintrag. Server-OS führt Microsoft ausdrücklich als nicht betroffen, das deckt sich mit der Tabelle oben. Und wie jeder KIR ist auch dieser befristet gedacht: Kommt die eigentliche Korrektur mit einem späteren Update, gehört die Richtlinie wieder heraus.

Nachtrag vom 15.10.2026: Die Kennung KB5124010 steht auch beim RDP-Fehler 0xC000000D, der seit dem Update vom 22.09. auf Windows-11-Rechnern mit Administrator protection auftritt. Gegen diesen Fehler hilft der KIR oben nicht. Prüfweg und Workaround stehen im Beitrag RDP-Fehler 0xC000000D unter Windows 11: Administrator protection prüfen und gezielt abschalten.

---

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 die Shell nachstartet, wenn sie nach der Anmeldung fehlt. Behandelt das Symptom zuverlässig. Wichtig dabei: erst ein paar Sekunden warten, denn meist kommt der Explorer von allein, nur verzögert. Wer sofort eingreift, startet eine zweite Shell.
• AppX-Pakete neu registrieren: nicht empfehlenswert. Wirkt uneinheitlich und zieht weitere Probleme nach sich.

Das sind Behelfe, keine Lösungen. Sie behandeln das Symptom. Sobald Microsoft oder Citrix liefert, gehören sie wieder weg, sonst stehen sie in fünf Jahren noch in der Gruppenrichtlinie und niemand weiß, wofür.

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!

Nachtrag 07.10.2026: Warum ein üblicher Patchtest diesen Fehler nicht findet und welcher Test ihn findet, steht im Beitrag Dein Patchtest hat die Sitzung offen gelassen.

Quellen

• CTX697101: Issues with Microsoft Windows September 2026 Update, Citrix
• Windows 11 24H2: bekannte Probleme, Microsoft Release Health
• KB5129195: Out-of-Band-Update vom 14.09.2026, Microsoft
• KB5124008: Sicherheitsupdate vom 08.09.2026, Microsoft
• CVE-2026-69525, Microsoft Security Response Center

---

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.

Nachtrag 27.09.2026: Fehler B weiterhin offen, seit 24.09. per Known Issue Rollback gemindert. Siehe Kopf des Abschnitts zu Fehler B.

Nachtrag 14.10.2026: Fehler B mit den Oktober-Updates vom 13.10. behoben, Known Issue Rollback wieder entfernen. Siehe Kopf des Abschnitts zu Fehler B.