Windows 11 24H2 and 25H2 black screen on first logon in non-persistent VDI, root cause and fix.

Question

Windows 11 24H2 and 25H2 black screen on first logon in non-persistent VDI, root cause and fix.

Durai, Arunkumar 0

On Citrix MCS-provisioned non-persistent virtual desktops, Windows 11 24H2 and 25H2 both show a black screen on first logon following catalog updates, caused by AppX packages failing to initialize after the MCS generalization process. Sharing the same FSLogix profile container path between 23H2 and 25H2 desktop pools appears to trigger this consistently. Creating a separate, dedicated FSLogix profile path for 24H2 or 25H2 desktops resolves the issue entirely in our testing. Since Windows 11 23H2 support ends November 30, 2026, organizations upgrading to 25H2 on non-persistent VDI are likely to hit this same issue. Requesting this be documented as a known issue and workaround, or incorporated into an official fix. "If others are seeing this on their non-persistent VDI fleets, please comment below, and if a Microsoft engineer can confirm this as the official workaround, it would help a lot of organizations migrating off 23H2 before support ends."

0 comments

2 answers

Your answer

Answer 1

Microsoft has documented a closely related known issue for Windows 11 24H2 and 25H2 in enterprise and managed environments after provisioning, especially when updates are installed before first user logon on persisted installations or before each user logon on non-persistent installations such as VDI. The documented symptom is that XAML-dependent apps such as Explorer, Start, Settings, Taskbar, and Windows Search might not start or might close unexpectedly. That aligns with black screen or shell-load failures at first sign-in.

The documented root cause is missing package registration for required system AppX components after provisioning or Sysprep-like preparation. Microsoft’s published fix is to manually register the missing packages in the user session, then restart SiHost or restart the device:

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

For non-persistent OS installations, Microsoft states that the best approach is a logon script that registers these packages synchronously before explorer.exe launches, so the required packages are provisioned before the desktop loads.

Based on the available documentation, the supported explanation is:

The issue affects non-persistent VDI and similar environments.
It is triggered when required app packages are not registered before shell components load.
The supported workaround/fix is package registration, ideally through a synchronous pre-Explorer logon script in non-persistent environments.

The specific claim that sharing the same FSLogix profile container path between 23H2 and 24H2/25H2 pools is the root cause, and that separating FSLogix profile paths is the official workaround, is not documented in the available Microsoft content.

If this is being operationalized in a Citrix MCS non-persistent fleet, the supported path from Microsoft documentation is:

Validate the issue is occurring on Windows 11 24H2 or 25H2 non-persistent desktops after provisioning or catalog update.
Implement the published AppX registration commands.
In non-persistent images, deploy them through a synchronous logon script that runs before explorer.exe.
Restart SiHost or restart the VM after registration when testing interactively.

Answer 2

Thanks for the pointer to KB5072911 and the Sysprep troubleshooting article. We actually tested that exact approach already, the Add-AppxPackage re-registration script run at logon, but found it problematic in our non-persistent fleet, since it shows a visible PowerShell window to end users and adds noticeable delay to logon time. Separating the FSLogix profile container path for 24H2 and 25H2 pools from the shared 23H2 path resolved the black screen for us without any of those side effects, and it isn't something we've seen documented elsewhere. Flagging this in case it's a useful complementary fix for others hitting the same issue in Citrix or similar non-persistent VDI environments.