Nach einem aktuellen Windows-Patching bin ich in einer Windows-11-VDI-Umgebung auf ein interessantes Problem gestoßen.
Die Anmeldung am Citrix VDA funktionierte zunächst völlig normal. Die Session wurde aufgebaut, der Benutzer authentifiziert – doch statt des Desktops erschien anschließend nur ein permanenter schwarzer Bildschirm.
Was zunächst wie ein klassisches Citrix-, HDX- oder Profilproblem aussah, führte bei der Analyse schließlich in eine ganz andere Richtung: Windows Shell, AppX und XAML.
Und besonders interessant: Selbst das Entfernen des Windows-Updates beseitigte das Problem nicht.
Das Fehlerbild
Betroffen waren Windows-11-VDI-Systeme. Nach der Benutzeranmeldung blieb der Bildschirm schwarz.
Die Session selbst war allerdings keineswegs hängen geblieben.
Über den Task Manager ließ sich einfach explorer.exe manuell starten.
Unmittelbar danach erschienen Desktop, Taskleiste und Startmenü und die Session konnte ganz normal verwendet werden.
Das ist für die weitere Analyse ein entscheidender Hinweis.
Wenn explorer.exe manuell gestartet werden kann und anschließend ein vollständig funktionierender Desktop erscheint, funktionieren wesentliche Teile der Session offensichtlich bereits.
Damit stellt sich weniger die Frage:
Warum funktioniert die Citrix-Session nicht?
Sondern vielmehr:
Warum wird die Windows Shell während des normalen Logons nicht korrekt initialisiert?
Erst einmal die üblichen Verdächtigen
Bei einem Black Screen auf einem Citrix VDA denkt man verständlicherweise zunächst an Dinge wie VDA, HDX, Profile Management, FSLogix, GPOs oder Shell Extensions.
Insbesondere das Benutzerprofil gerät schnell unter Verdacht, wenn bestehende Benutzer betroffen sind, während ein Benutzer mit einem neuen Profil problemlos funktioniert.
Genau hier sollte man allerdings vorsichtig sein.
Ein Profil kann einen fehlerhaften Zustand persistieren, ohne selbst die ursprüngliche Ursache des Problems zu sein.
Gerade in einer non-persistent VDI-Umgebung ist diese Unterscheidung wichtig.
Die Maschine kommt beim nächsten Reboot wieder aus dem Golden Image. Der Benutzer bringt jedoch seinen persistierten User State wieder mit.
Damit kann ein Problem innerhalb der Windows-Shell beziehungsweise ihrer benutzerspezifischen Registrierung einen Reboot, Recompose oder sogar andere Änderungen am Maschinenzustand überleben. Genau diese Möglichkeit beschreibst du auch in deiner Analyse.
Update entfernen? Hat bei mir nichts gebracht
Natürlich lag nach dem zeitlichen Zusammenhang mit dem Windows-Patching ein Test nahe:
Update deinstallieren und erneut testen.
Das Ergebnis war allerdings ernüchternd.
Der Black Screen blieb bestehen.
Das ist technisch durchaus interessant, denn offenbar reicht es in diesem Fall nicht aus, einfach die Windows-Binaries auf den vorherigen Stand zurückzubringen.
Wenn durch das Update bereits ein inkonsistenter Zustand innerhalb des Benutzerkontexts oder der Shell-/AppX-Registrierung entstanden ist, kann dieser Zustand möglicherweise erhalten bleiben.
Ein einfaches:
Update weg = Problem weg
funktionierte hier jedenfalls nicht.
Die entscheidende Spur: Windows AppX und Shell
Der entscheidende Test war schließlich die erneute Registrierung einiger Windows-Shell-Komponenten.
Konkret ging es um:
|
|
MicrosoftWindows.Client.CBS Microsoft.UI.Xaml.CBS MicrosoftWindows.Client.Core |
Diese Komponenten stehen im Zusammenhang mit modernen Bestandteilen der Windows-Shell und der zugrunde liegenden XAML-Infrastruktur.
Für einen manuellen Test können die Pakete beispielsweise mit PowerShell erneut registriert werden:
|
|
Add-AppxPackage -Register -Path ` "C:\Windows\SystemApps\MicrosoftWindows.Client.CBS_cw5n1h2txyewy\appxmanifest.xml" ` -DisableDevelopmentMode Add-AppxPackage -Register -Path ` "C:\Windows\SystemApps\Microsoft.UI.Xaml.CBS_8wekyb3d8bbwe\appxmanifest.xml" ` -DisableDevelopmentMode Add-AppxPackage -Register -Path ` "C:\Windows\SystemApps\MicrosoftWindows.Client.Core_cw5n1h2txyewy\appxmanifest.xml" ` -DisableDevelopmentMode |
Und genau das brachte in meinem Fall den entscheidenden Unterschied.
Nach der erneuten Registrierung funktionierte der nächste Logon wieder.
explorer.exe wurde automatisch gestartet und der Desktop erschien wie erwartet.
Was bedeutet das?
Eine endgültige Root Cause ist damit natürlich noch nicht bewiesen.
Das Verhalten grenzt das Problem aber ziemlich deutlich ein.
Wir haben:
Windows Logon
↓
User Profile
↓
AppX / XAML / Shell State
↓
Shell-Initialisierung schlägt fehl
↓
explorer.exe startet nicht
↓
Black Screen
Nach der erneuten Registrierung der betroffenen Komponenten funktioniert die Initialisierung wieder und Explorer startet regulär.
Damit würde ich bei diesem konkreten Fehlerbild nicht als Erstes den Citrix VDA auseinandernehmen.
Der funktionierende manuelle Start von explorer.exe ist dafür schlicht ein zu deutlicher Hinweis.
Bestehendes gegen neues Profil testen
Ein weiterer sinnvoller Test ist ein komplett neuer Benutzer beziehungsweise ein neues Profil.
Wenn sich beispielsweise folgendes Bild ergibt:
Bestehendes Profil → Black Screen
Neues Profil → funktioniert
würde ich das bestehende Profil trotzdem nicht sofort löschen.
Ganz im Gegenteil: Für eine Root-Cause-Analyse ist genau dieses Profil interessant.
Bei UPM oder FSLogix würde ich deshalb zunächst eine Kopie des betroffenen Profils beziehungsweise Containers sichern.
Ein Profile Reset kann das Problem möglicherweise beseitigen – gleichzeitig vernichtet man damit aber unter Umständen genau den Zustand, den man eigentlich untersuchen möchte.
Workaround für mehrere Benutzer
Wenn sich das Verhalten reproduzieren lässt, kann die Registrierung beispielsweise über ein synchron ausgeführtes User-Logon-Script erfolgen:
|
|
@echo off REM MicrosoftWindows.Client.CBS powershell.exe -ExecutionPolicy Bypass -Command "Add-AppxPackage -Register -Path 'C:\Windows\SystemApps\MicrosoftWindows.Client.CBS_cw5n1h2txyewy\appxmanifest.xml' -DisableDevelopmentMode" REM Microsoft.UI.Xaml.CBS powershell.exe -ExecutionPolicy Bypass -Command "Add-AppxPackage -Register -Path 'C:\Windows\SystemApps\Microsoft.UI.Xaml.CBS_8wekyb3d8bbwe\appxmanifest.xml' -DisableDevelopmentMode" REM MicrosoftWindows.Client.Core powershell.exe -ExecutionPolicy Bypass -Command "Add-AppxPackage -Register -Path 'C:\Windows\SystemApps\MicrosoftWindows.Client.Core_cw5n1h2txyewy\appxmanifest.xml' -DisableDevelopmentMode" |
Das Timing ist hierbei relevant. Die Komponenten sollen während der Logon-Sequenz korrekt registriert werden, bevor die Shell vollständig initialisiert wird.
Ich würde so einen Workaround deshalb zunächst gezielt mit einer kleinen Pilotgruppe testen und nicht blind auf sämtliche Benutzer loslassen. Dein bisheriger Test sieht gut aus, aber ein Workaround ist noch kein Root-Cause-Fix.
Finding in the Wild
Das Interessante an diesem Fall ist für mich weniger der Black Screen selbst.
Black Screens gibt es in VDI-Umgebungen schließlich in ausreichend vielen Geschmacksrichtungen.
Interessant ist vielmehr die Fehlerkette:
Citrix-Session funktioniert → Explorer startet manuell → Update-Rollback hilft nicht → AppX-/Shell-Komponenten neu registrieren → normaler Logon funktioniert wieder.
Das spricht deutlich dafür, die Ursache nicht ausschließlich innerhalb des Citrix-Stacks zu suchen.
Citrix sitzt schließlich auf einem ziemlich großen Windows-Unterbau:
Citrix HDX
↓
Windows Session
↓
User Profile
↓
AppX / XAML
↓
Windows Shell
↓
Explorer
Für den Benutzer sieht ein Fehler an fast jeder Stelle dieser Kette gleich aus:
Black Screen.
Für uns als Administratoren ist deshalb die wichtigere Frage nicht:
Warum zeigt Citrix einen schwarzen Bildschirm?
Sondern:
Welcher Teil der Windows-Logon-Sequenz ist tatsächlich fehlgeschlagen?
In diesem Fall war explorer.exe der Hinweis, der letztendlich in die richtige Richtung geführt hat.
Fazit
Finding in the Wild: Ein Black Screen nach dem Windows-Logon muss auch auf einem Citrix VDA nicht zwangsläufig ein Citrix-Problem sein.
In meinem Fall waren vor allem drei Beobachtungen entscheidend:
explorer.exe ließ sich manuell starten und erzeugte anschließend einen vollständig funktionierenden Desktop.- Das Entfernen des zuvor installierten Windows-Updates beseitigte das Problem nicht.
- Die erneute Registrierung von
MicrosoftWindows.Client.CBS, Microsoft.UI.Xaml.CBS und MicrosoftWindows.Client.Core stellte den normalen Logon wieder her.
Eine endgültige Root Cause ist damit noch nicht bewiesen. Das Verhalten liefert aber einen ziemlich starken Fingerzeig in Richtung Windows Shell/AppX/XAML und benutzerspezifischer Shell-State.
Und genau deshalb mag ich solche Finding-in-the-Wild-Fälle:
Der schwarze Bildschirm ist nur das sichtbare Symptom. Das eigentliche Problem sitzt ein paar Schichten tiefer.
