If you manage Windows 11 machines, a pair of cumulative updates from July 2025 can trigger a catastrophic failure in the user interface after provisioning, leaving the Start menu, Taskbar, File Explorer, and Settings completely inaccessible. Microsoft has acknowledged the bug and released temporary workarounds, but a permanent patch is still on the way. Here’s what every administrator needs to know right now.

What exactly goes wrong?

After applying updates KB5062553 (July 8) or KB5065789 (released later in July) to Windows 11 version 24H2 or 25H2, freshly provisioned PCs may exhibit a constellation of failures that bring daily work to a halt. The Start menu either refuses to open or shows a “critical error” message. The Taskbar vanishes, even though explorer.exe remains running in Task Manager. File Explorer crashes on launch, hangs, or displays no folder UI. The Settings app silently fails to open, and ShellHost.exe or StartMenuExperienceHost may crash during initialization. For anyone sitting down at a newly imaged machine, the result is a desktop that looks intact but behaves like a hollow shell.

Microsoft’s own advisory (tracked as KB5072911) states the problem appears “after provisioning a PC” with those specific monthly rollups. That word — provisioning — is key; it’s the act of preparing a device for a new user, typically in corporate imaging, virtual desktop pools, or Cloud PC deployments. The company adds that the bug is “unlikely” to strike personal, individually owned devices, but that is cold comfort for IT operations that provision thousands of endpoints.

The underlying cause: a timing race in package registration

Windows 11 delivers much of its modern shell — Start, Taskbar, notification center, Settings — as modular AppX/MSIX packages that rely on XAML for rendering. When a cumulative update replaces these packages on disk, the system must register them anew so that user sessions can find and activate the XAML components. Normally that registration happens asynchronously and finishes before the interactive shell starts. The July 2025 updates introduced a timing defect: the registration tasks sometimes lag behind, and if the shell processes launch first, they cannot instantiate the required XAML views. The result is a cascade of failures across every UI surface that depends on those packages.

Three specific in-box packages are cited in the advisory:

  • MicrosoftWindows.Client.CBS_cw5n1h2txyewy
  • Microsoft.UI.Xaml.CBS_8wekyb3d8bbwe
  • MicrosoftWindows.Client.Core_cw5n1h2txyewy

When these packages are present on disk but not registered for the active session, Start, Taskbar, File Explorer, and Settings simply break. It is a classic race condition — not corrupted files, but a mismatch between the speed of registration and the speed of user logon. The design of modular Windows makes the OS more nimble for feature updates, but it also introduces a new dependency: every update must leave enough time for package registration before the shell appears.

Who is vulnerable?

Enterprise administrators bear the brunt of this bug, particularly those running:

  • Non-persistent VDI pools and instant clones — where user sessions are built fresh at each logon, and packages must be registered every time a new session starts.
  • Cloud PC deployments that rely on automated provisioning with the latest patches baked into the golden image.
  • Physical device provisioning floors where IT staff image a PC, apply cumulative updates, and immediately hand it over to an employee for first sign-in.

In these scenarios, the window for registration is narrow, and the race condition becomes highly reproducible. On the other hand, a typical home user who installs the update on an already-functioning machine and then restarts will almost never see the failure, because package registration has ample time to complete during the reboot cycle before anyone logs on.

That said, a single affected virtual desktop pool can trigger a mass outage: every user logging in after an image refresh will encounter a broken shell, generating a flood of help desk tickets. For organizations that measure uptime in five-nines, the operational risk is material.

How to fix it now: Microsoft’s workarounds

Microsoft has not yet released a code-level patch that eliminates the race condition, but it has published two practical mitigations that restore functionality immediately. Both work by forcing the registration of the missing XAML packages before the user’s shell fully starts.

For persistent machines (physical desktops, persistent VDI)

Open an elevated PowerShell console (Run as Administrator) and run these three commands in sequence:

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

After registration completes, restart the SiHost process by signing out and back in, or by running taskkill /f /im sihost.exe (which will restart automatically). The shell should then initialize correctly. This approach works well for a handful of affected endpoints, but it is not scalable for large fleets.

For non-persistent environments (pooled VDI, Cloud PC, instant clones)

In environments where user sessions are freshly composed at each logon, the best approach is a synchronous logon script that runs before Explorer.exe launches. Microsoft provides this batch wrapper:

@echo off
REM Register MicrosoftWindows.Client.CBS
powershell.exe -ExecutionPolicy Bypass -Command "Add-AppxPackage -Register -Path 'C:\Windows\SystemApps\MicrosoftWindows.Client.CBS_cw5n1h2txyewy\appxmanifest.xml' -DisableDevelopmentMode"

REM Register 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 Register MicrosoftWindows.Client.Core
powershell.exe -ExecutionPolicy Bypass -Command "Add-AppxPackage -Register -Path 'C:\Windows\SystemApps\MicrosoftWindows.Client.Core_cw5n1h2txyewy\appxmanifest.xml' -DisableDevelopmentMode"

Deploy this as part of the user logon sequence within your provisioning tool (Group Policy logon script, VMware DEM, Citrix WEM, or as a scheduled task triggered at logon). The key is that it must execute synchronously and finish before Explorer starts. Some environments may need to rename or delay Explorer.exe launch to ensure the script completes.

Important caveats for both workarounds:

  • Elevated rights are required; the script or commands must run in the user’s context with appropriate privileges.
  • Verify the exact package names and paths on your build, as they can vary with Windows editions or custom images.
  • Test thoroughly in a pilot ring before broad rollout; a misapplied registration can cause other side effects.
  • In locked-down environments, coordinate with security and change management teams before introducing new logon scripts.

These mitigations are operational stopgaps, not permanent solutions. They impose a small logon performance penalty and require ongoing maintenance until Microsoft publishes a servicing fix.

Preparing your deployment pipeline: longer-term advice

While the immediate workaround gets users back to work, smart IT practices will reduce exposure to similar regressions in the future. Consider these steps now:

  1. Pause broad deployment of the suspect updates. If you have not yet rolled out the July 2025 cumulative updates to production, hold them in your pilot rings until you can validate the workaround or until the permanent fix ships. Use the “pause updates” feature in Windows Update for Business or delay the rollout via your management tool.

  2. Add automated shell smoke tests to your imaging pipeline. After applying cumulative updates to a golden image or during provisioning, script a check that launches StartMenuExperienceHost.exe, opens a test Start menu, and verifies that Explorer and Settings respond. Tools like Microsoft’s own Pester framework or simple PowerShell UI automation can catch failures before users see them.

  3. Maintain a rollback plan. Know how to remove an offending LCU via DISM (DISM /Remove-Package) or how to quickly revert to a pre-update snapshot. In virtual environments, that may mean keeping a known-good master image online so you can cut over in minutes.

  4. Monitor Microsoft’s advisory KB5072911. The company will update this article when a permanent fix is ready. Bookmark the Windows release health dashboard and subscribe to notifications for your product version.

For non-persistent environments already impacted, deploying the logon script is the lowest-friction path to restore service. Pair it with an aggressive communication plan so help desk staff know how to triage calls — many tickets can be closed with a simple “run the registration script and sign out/in” instruction.

What Microsoft owes us next

The July 2025 bug is not an isolated incident. It follows a string of high-visibility patch regressions that have eroded IT confidence in the predictability of cumulative updates. The modular shell architecture that enables fast UX innovation also introduces subtle ordering dependencies that, when broken, yield spectacular failures. Microsoft’s engineering response will need to address both the specific timing race and the systemic QA gaps that allowed a provisioning-only defect to escape notice.

A servicing fix is in development, but no timeline has been announced. When it arrives, it will likely be part of a future cumulative update that restructures how package registration and shell startup are sequenced. In the meantime, every administrator who provisions Windows 11 at scale should treat the July updates as a “hold unless mitigated” item, implement the workaround where needed, and strengthen their own validation pipelines to catch the next race condition before it reaches users.

This incident is a reminder that in the modern Windows servicing model, enterprise provisioning scenarios are not an edge case — they’re a mainstream use case. Microsoft would do well to elevate them in its test matrix, and IT teams would do well to assume that no cumulative update is perfectly safe until proven otherwise.