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

Durai, Arunkumar 0 Reputation points
2026-09-13T03:06:28.6433333+00:00

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."

Windows for business | Windows Client for IT Pros | User experience | FSLogix
0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Daphne Huynh (WICLOUD CORPORATION) 1,305 Reputation points Microsoft External Staff Moderator
    2026-09-14T06:19:20.39+00:00

    Welcome to Microsoft Q&A!

    Thank you for taking the time to share such detailed findings and testing results.

    Based on the information provided, the behavior appears consistent with a known Windows 11 24H2 and 25H2 issue involving AppX/XAML package registration during provisioning and user sign-in.

    Microsoft has documented in KB5072911 that XAML-dependent components may not initialize correctly when Windows updates are installed before the first user sign-in on a persistent installation, or before user sign-ins in a non-persistent VDI environment. In these scenarios, required application packages might not register in time.

    When this occurs, users may encounter symptoms such as:

    • A black screen after sign-in
    • Explorer.exe crashing or failing to start
    • The Start menu or Taskbar not appearing
    • Settings and Windows Search failing to open
    • Other XAML-dependent applications closing unexpectedly

    Microsoft's documented workaround for affected non-persistent environments is to register the missing AppX packages synchronously before Explorer starts. However, your concern about the operational impact is understandable. A logon script may introduce additional sign-in time, and an improperly hidden PowerShell process could also affect the end-user experience.

    Microsoft has stated that this issue is addressed beginning with Windows updates released on June 23, 2026, with KB5095093, and recommends installing the latest available Windows updates.

    There is also a separate, related scenario involving Sysprep. Running Sysprep under the Local System account is unsupported on Windows 11 24H2 and 25H2. This process can skip the registration of certain AppX/XAML packages, resulting in Explorer crashes, missing interface elements, or a black screen after deployment.

    Regarding your FSLogix profile-container findings, I was unable to locate public Microsoft documentation that currently identifies sharing the same FSLogix profile-container path between Windows 11 23H2 and 24H2 or 25H2 pools as an officially confirmed root cause.

    Nevertheless, the results of your testing are significant:

    • The issue reproduced consistently when the 23H2 and 24H2 or 25H2 pools shared the same FSLogix profile location.
    • The black-screen behavior stopped after a dedicated profile-container path was assigned to the 24H2 or 25H2 pools.
    • This approach avoided the visible PowerShell window and additional logon delay associated with the package re-registration script.

    Based on these observations, using a separate FSLogix profile-container path for each major Windows release appears to be a reasonable and practical mitigation for the environment described.

    At this time, however, it would be most accurate to describe this as a customer-validated workaround rather than an official Microsoft fix. The available Microsoft documentation confirms the underlying AppX/XAML registration issue, but it does not currently confirm that cross-version reuse of an FSLogix profile container is the root cause.

    Thank you again for documenting your findings so thoroughly. This information may be very helpful to other organizations experiencing similar behavior in Citrix MCS, Azure Virtual Desktop, VMware Horizon, or other non-persistent VDI environments. Additional reports through Microsoft Support and feedback channels may also help Microsoft investigate whether the FSLogix profile-path behavior should be included in future product documentation.

    References: KB5072911: Explorer, the Start menu, and other XAML-dependent apps might not start or close unexpectedly on some enterprise devices | Microsoft Support

    Fix Black Screen After Running Sysprep as System on Windows 11 or Windows Server 2025 - Windows Client | Microsoft Learn

    Known Issues - FSLogix | Microsoft Learn

    If you find this information helpful, please click Accept Answer. 

    Thank you for using Microsoft Q&A.

    Was this answer helpful?

    0 comments
  2. Durai, Arunkumar 0 Reputation points
    2026-09-13T03:15:19.44+00:00

    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.

    Was this answer helpful?

    0 comments

  3. AI answer

    2026-09-13T03:06:48.7933333+00:00

    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:

    1. The issue affects non-persistent VDI and similar environments.
    2. It is triggered when required app packages are not registered before shell components load.
    3. 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:

    1. Validate the issue is occurring on Windows 11 24H2 or 25H2 non-persistent desktops after provisioning or catalog update.
    2. Implement the published AppX registration commands.
    3. In non-persistent images, deploy them through a synchronous logon script that runs before explorer.exe.
    4. Restart SiHost or restart the VM after registration when testing interactively.
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.