Microsoft has confirmed a significant issue affecting Windows 11 enterprise and virtualized environments, where core shell components, including File Explorer, the Start menu, and Windows Search, may fail to launch or crash unexpectedly after provisioning.
The bug, tracked under KB5072911, stems from a timing flaw in how XAML-dependent packages register during system provisioning, and it’s causing headaches for IT administrators managing large fleets of managed devices and VDI deployments.
While Microsoft stresses that personal, unmanaged devices are “very unlikely” to encounter this problem, the impact on enterprise environments, particularly non-persistent virtual desktop infrastructure, has been substantial enough to warrant a dedicated advisory and a set of interim workarounds.
The root cause traces back to a race condition involving three critical system packages that host XAML UI components:
- MicrosoftWindows.Client.CBS_cw5n1h2txyewy
- Microsoft.UI.Xaml.CBS_8wekyb3d8bbwe
- MicrosoftWindows.Client.Core_cw5n1h2txyewy
These packages provide the underlying XAML framework that modern Windows shell elements depend on. According to Microsoft, “the applications have a dependency on XAML packages that are not registering in time after installing Windows updates.
In other words, Explorer and its related components try to start before the OS has finished registering the UI framework; they need a sequencing failure rather than a corruption or security flaw.
The issue affects devices running Windows 11 version 24H2 or 25H2 that received a monthly cumulative update starting in July 2025, including KB5062553 and KB5065789.
It surfaces specifically when updates are applied before a device’s first user logon on persistent installations, or before every logon on non-persistent setups like VDIs, where application packages must be reinstalled each session.
The practical symptoms read like a shell administrator’s worst nightmare. Explorer.exe crashes on startup or leaves users staring at a black screen. The Start menu refuses to open, sometimes throwing a critical error instead. The taskbar simply doesn’t render.
StartMenuExperienceHost and ShellHost.exe both crash outright, and even Consent.exe, the binary responsible for User Account Control prompts, fails silently.
System Settings is no longer accessible via Start > Settings > System, and any application that relies on XAML views or XAML Islands for its UI risks crashing during initialization.
For IT teams running large-scale VDI deployments, where every user session effectively re-provisions the OS, this bug has the potential to disrupt logons at scale rather than affecting isolated machines.
Microsoft has addressed the underlying issue starting with updates released June 23, 2026, via KB5095093. The company notes that this fix is rolling out gradually and won’t reach full availability until the following month’s cumulative update cycle, meaning organizations may not see complete resolution until late July 2026 patches land across all supported channels.
Until then, Microsoft is directing affected organizations toward manual mitigation. For persisted OS installations, IT administrators can manually re-register the affected packages and restart the Immersive Shell host to force recognition.
This requires running Add-AppxPackage with the -Register flag against each package’s appxmanifest.xml file, followed by a SiHost restart so the shell can pick up the newly registered components.
For non-persistent environments like VDI, where this fix would need to run on every single logon, Microsoft recommends a more robust approach: a logon script wrapped in a batch file that executes the PowerShell registration commands synchronously before Explorer launches.
This effectively blocks Explorer from starting prematurely until all three XAML packages are fully provisioned, closing the race condition that triggers the crash in the first place.
Administrators managing Citrix, VMware Horizon, or Azure Virtual Desktop environments should prioritize testing this logon script against their golden images before wider deployment, given how disruptive a failed shell launch can be at scale.
This incident underscores a recurring theme in modern Windows servicing: as Microsoft leans further into XAML and WinUI frameworks for core shell experiences, the interdependencies between update sequencing and component registration grow more fragile, especially in environments that don’t follow a simple, linear provisioning path.
Enterprise and VDI administrators should treat this as a reminder to validate golden images and provisioning scripts against each monthly cumulative update before broad rollout, rather than assuming shell stability is guaranteed by default.
Organizations still running affected builds should apply the appropriate workaround now and plan to move to KB5095093 or later once it’s fully available in their update channel.
About the Author
