Nach der Anmeldung bleibt die Sitzung schwarz, der Mauszeiger ist eventuell sichtbar und der Windows-Desktop erscheint nicht? Seit dem 24. September 2026 führt Microsoft dafür einen neuen bekannten Fehler. Er betrifft vor allem Azure-Virtual-Desktop-Hosts (AVD) mit FSLogix und tritt nach KB5120998 beziehungsweise nachfolgenden Windows-Updates auf.
Recherchestand: 25. September 2026. Microsoft hat derzeit eine temporäre Umgehung und einen Known Issue Rollback (KIR) bereitgestellt. Eine reguläre dauerhafte Korrektur soll mit einem zukünftigen Windows-Update folgen.
Was genau ist der bestätigte Fehler?
Der Fehler wurde durch die nicht sicherheitsrelevante Vorschauaktualisierung KB5120998 vom 27. August 2026 beziehungsweise durch spätere Updates ausgelöst. Microsoft nennt folgende Symptome:
- Nach der Anmeldung erscheint ein schwarzer Bildschirm und der Desktop startet nicht automatisch.
- Die Sitzung bleibt unbenutzbar, bis der Windows-Desktop manuell gestartet wird.
- Im Anwendungsprotokoll können Abstürze von
explorer.exeauftauchen.
Beobachtet wird das Problem hauptsächlich auf AVD-Sitzungshosts mit FSLogix und häufiger bei bestimmten bereits vorhandenen Benutzerprofilen. Betroffen sind Windows 11 24H2, 25H2 und 26H1. Windows Server nennt Microsoft ausdrücklich nicht als betroffene Plattform. Die aktuelle Primärquelle ist Windows Release Health.
Wichtig: Nicht mit einem schwarzen Hintergrund verwechseln
Microsoft dokumentierte zuvor einen anderen Fehler aus KB5120998: Dabei wurde nur das Desktop-Hintergrundbild durch eine schwarze Fläche ersetzt, während Taskleiste und Desktop weiterhin funktionierten. Dieser Personalisierungsfehler wurde bereits mit KB5124008 vom 8. September 2026 behoben.
Der hier behandelte Fehler ist anders: Die Windows-Shell beziehungsweise der Desktop wird nach der Anmeldung nicht automatisch geladen. Ein schwarzes Bild auf einem normalen Einzelplatz-PC, ein Grafiktreiberproblem oder ein schwarzer Bildschirm schon vor der Anmeldung können wiederum andere Ursachen haben.
Schnelltest: explorer.exe manuell starten
Wenn Du Dich noch anmelden kannst und der schwarze Bildschirm erscheint, drücke Strg + Umschalt + Esc. Öffnet sich der Task-Manager, wähle Neuen Task ausführen, gib explorer.exe ein und bestätige.
Erscheinen danach Taskleiste, Startmenü und Desktop, passt das Verhalten zum von Microsoft beschriebenen Fehler. Dieser Schritt ist jedoch nur eine temporäre Hilfe für die aktuelle Sitzung. Er beseitigt die auslösende Windows-Änderung nicht.
Auf einem Mehrbenutzersystem solltest Du Explorer nicht pauschal für andere Sitzungen beenden. Ein erzwungenes Abmelden kann ungespeicherte Arbeit des betroffenen Benutzers verlieren.
Patchstand und betroffene Hosts prüfen
Führe die folgenden Abfragen in einer erhöhten PowerShell auf dem Sitzungshost aus. Sie verändern nichts am System:
Get-ComputerInfo |
Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
Get-CimInstance Win32_QuickFixEngineering |
Sort-Object InstalledOn -Descending |
Select-Object -First 15 HotFixID, InstalledOn, Description
Suche im Updateverlauf nach KB5120998 vom 27. August 2026 oder nach einer späteren kumulativen Aktualisierung. Dass KB5120998 nicht mehr separat erscheint, schließt den Fehler nicht aus: Kumulative Updates ersetzen frühere Pakete, können deren Änderungen aber enthalten.
Prüfe anschließend, ob das Problem tatsächlich an einzelne Profile oder an den gesamten Host gebunden ist:
- Tritt es bei jedem Benutzer oder nur bei bestehenden Profilen auf?
- Funktioniert ein kontrolliert angelegtes Testprofil?
- Welche Hosts im Pool sind betroffen, und haben sie denselben Build?
- Startet
explorer.exemanuell zuverlässig?
Ein Profil darf nicht vorschnell gelöscht oder sein VHD/VHDX-Container umbenannt werden. Das kann Benutzerdaten und Einstellungen unzugänglich machen und ist für den bestätigten Windows-Fehler keine dokumentierte Lösung.
FSLogix und Explorer gezielt diagnostizieren
FSLogix ist in den beobachteten Umgebungen ein gemeinsamer Kontext, aber Microsoft bezeichnet FSLogix nicht pauschal als alleinige Ursache. Prüfe deshalb sowohl den Shell-Absturz als auch die Profilanmeldung.
Explorer-Abstürze der letzten vier Stunden lassen sich auf dem Host mit Administratorrechten eingrenzen:
$start = (Get-Date).AddHours(-4)
Get-WinEvent -FilterHashtable @{
LogName = 'Application'
StartTime = $start
} -ErrorAction SilentlyContinue |
Where-Object {
$_.ProviderName -in @('Application Error','Windows Error Reporting') -and
$_.Message -match 'explorer\.exe'
} |
Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message
Microsoft nennt für diesen Fehler keine allgemeingültige Event-ID. Deshalb ist die Kombination aus Zeitpunkt, Prozessname und betroffener Benutzersitzung aussagekräftiger als die Suche nach einer einzelnen Ereignisnummer.
Die FSLogix-Ereignisse findest Du in der Ereignisanzeige unter Anwendungs- und Dienstprotokolle → FSLogix. Zusätzlich liegen die Textprotokolle standardmäßig in C:\ProgramData\FSLogix\Logs. Besonders relevant ist C:\ProgramData\FSLogix\Logs\Profile\Profile_%date%.log. Suche dort nach LoadProfile: BENUTZERNAME und gleiche Zeitstempel sowie Prozess-ID mit der betroffenen Anmeldung ab. Microsoft beschreibt dieses Vorgehen in der FSLogix-Diagnosedokumentation.
Dauerhafte Zwischenlösung: Known Issue Rollback einsetzen
Für verwaltete Geräte hat Microsoft einen Known Issue Rollback bereitgestellt. Ein KIR deaktiviert gezielt die nicht sicherheitsrelevante Änderung, die den Fehler verursacht, ohne das gesamte kumulative Sicherheitsupdate zu entfernen.
Verwende ausschließlich die zu Deiner Windows-Version passende Richtlinie:
- Windows 11 24H2 und 25H2: KB5124010 260924_20021 Known Issue Rollback
- Windows 11 26H1: KB5124006 260924_20071 Known Issue Rollback
Die offiziellen Downloads sind direkt im Eintrag von Windows Release Health verlinkt. Installiere das jeweilige MSI-Paket auf dem Rechner, mit dem Du die Gruppenrichtlinien verwaltest. Dadurch werden die benötigten ADMX- und ADML-Dateien unter C:\Windows\PolicyDefinitions abgelegt. Bei einem zentralen ADMX-Speicher müssen diese Dateien dorthin übernommen werden.
Erstelle anschließend ein gezielt gefiltertes GPO und konfiguriere die installierte KIR-Richtlinie unter Computerkonfiguration → Administrative Vorlagen auf Deaktiviert. Diese zunächst widersprüchlich wirkende Einstellung aktiviert den Rollback, indem sie die problematische Windows-Änderung deaktiviert. Nach der Richtlinienübernahme ist ein Neustart des Sitzungshosts erforderlich. Das vollständige Verfahren dokumentiert Microsoft unter KIR per Gruppenrichtlinie bereitstellen.
gpupdate /target:computer /force
gpresult /scope computer /h C:\Temp\KIR-Computer.html
Der erste Befehl stößt die Computerrichtlinien-Aktualisierung an. Der zweite schreibt einen Ergebnisbericht. Lege den Zielordner vorher an und öffne den Bericht nur in einer administrativ vertrauenswürdigen Umgebung, da er Richtlinien- und Systeminformationen enthält.
Wichtige Hinweise für AVD-Umgebungen
- Teste den KIR zuerst auf einem kleinen, kontrollierten Host-Ring.
- Versetze Sitzungshosts vor dem Neustart in den Drain-Modus und lasse aktive Benutzer geordnet abmelden.
- Mische die KIR-Pakete für 24H2/25H2 und 26H1 nicht.
- Entferne KB5120998 oder spätere Sicherheitsupdates nicht pauschal.
- Dokumentiere GPO, Zielgruppe und Rollback, damit die Übergangslösung nach Microsofts endgültigem Fix kontrolliert zurückgenommen werden kann.
Erfolgskontrolle
Nach Richtlinienübernahme und Neustart sollte eine neue Anmeldung den Desktop automatisch laden. Prüfe mindestens:
- mehrere zuvor betroffene Benutzerprofile,
- einen neu erstellten Testbenutzer,
- die Anwendungsprotokolle auf neue Explorer-Abstürze,
- FSLogix-Profile-Logs auf Fehler und ungewöhnlich lange Ladezeiten,
- den tatsächlichen GPO-Status mit
gpresult.
Bleibt der Bildschirm schwarz, sichere Zeitstempel, Hostname, Windows-Build, Benutzer-SID in geschützter Form, Explorer-Ereignisse sowie die passenden FSLogix-Protokolle. Prüfe außerdem Shell-GPOs, AppLocker beziehungsweise WDAC, Profilcontainer-Zugriff und Drittsoftware, bevor Du den Fehler Microsoft oder Deinem AVD-Support eskalierst.
Fazit
Der seit 24. September 2026 bestätigte Anmeldefehler betrifft vor allem AVD-Hosts mit FSLogix nach KB5120998 und nachfolgenden Updates. explorer.exe manuell zu starten, stellt die aktuelle Sitzung oft vorübergehend wieder her. Für verwaltete Umgebungen ist der versionspassende Known Issue Rollback die von Microsoft dokumentierte Zwischenlösung. Eine reguläre Behebung per Windows-Update steht zum Recherchestand noch aus.
0 Kommentare