Windows 11 24H2 Provisioning Regression: Fixes for Start Menu and Taskbar

Microsoft has published an advisory (KB5072911) describing a provisioning-time regression in Windows 11, version 24H2: after installing monthly cumulative updates released on or after July 2025 (the advisory calls out KB5062553 as a representative package), several shell and XAML-hosted components — StartMenuExperienceHost, Search, System Settings, Taskbar, Explorer and other XAML island views — can fail to initialize for first-time user logons or for all logons in non‑persistent/VDI environments, producing crashes, silent failures or a blank taskbar.

---

Background / Overview​

Windows servicing increasingly ships dependency packages for built-in UI elements as separate, updatable appx bundles (XAML hosts, Shell components and so on). When the servicing sequence updates those dependency packages, the OS must register them back into each user session so shell processes and XAML-hosted views can create their UI objects. Microsoft’s advisory states that in some provisioning scenarios the updated XAML packages are not registering in time, creating a race condition where the shell launches before the packages are available to the user session. The symptom set is therefore concentrated on UI processes that depend on those packages. This advisory is scoped specifically to:

• Windows 11, version 24H2 (all editions).
• The problem occurs after installing monthly cumulative updates released on or after July 2025 (the KB explicitly references KB5062553 as an originating package).
• The highest risk scenarios are (a) first sign‑in of a user immediately after an update, and (b) non‑persistent OS installations — for example VDI pools or other images where application packages and provisioning actions must run at each logon.

Microsoft’s release-health and known-issues pages for Windows 11 24H2 continue to track and document rollout and compatibility holds for the 24H2 branch; these channels are the official source for ongoing status and safeguidance.

---

What’s happening — technical anatomy​

XAML package registration race​

Windows hosts many in‑box components as packaged appx bundles (for example Microsoft.Windows.Client.CBS_cw5n1h2txyewy, Microsoft.UI.Xaml.CBS_8wekyb3d8bbwe and Microsoft.Windows.Client.Core_cw5n1h2txyewy). When servicing replaces those packages, the runtime needs to (re)register the packages for the active user session so COM/XAML activation works. If shell processes (Explorer, ShellHost, StartMenuExperienceHost, etc. start before registration completes, their activation calls fail — this manifests as crashes, “critical error” Start menu messages, blank taskbar, or XAML views that never initialize. Microsoft’s KB describes this exact timing/dependency problem and identifies the packages implicated.

Why provisioning and non-persistent images are particularly vulnerable​

• In first-time sign‑on after update scenarios, the update path has modified system components and the user session is being created immediately — there’s little slack for registration tasks to finish.
• In non‑persistent OS/VDI environments the image is shared or refreshed and certain app packages are provisioned per-session or per‑logon rather than being permanently installed; this means the registration path must reliably run before shell startup for every user logon. Microsoft explicitly recommends synchronous execution of registration in those environments as a workaround.

---

Symptoms — what IT and users will observe​

Microsoft lists (and field reports confirm) a broad set of UI and shell failures. These symptoms are often high‑visibility and disruptive:

• Explorer.exe may crash or be running with no taskbar window visible.
• Start menu may fail to launch and/or show a critical error dialog.
• System Settings (Settings > System) can silently refuse to open.
• ShellHost.exe or StartMenuExperienceHost crashes during XAML view initialization; other XAML island views fail to render.
• Affected components are the ones that depend on the updated XAML packages; in practice, that includes many of the most‑used desktop surfaces and application-hosted UI islands.

Community reporting and forum threads mirror these observations: administrators and end users have posted reproducible cases where re‑registering the packages restored shell functionality, and where the failure was concentrated on post‑update sign‑ins or freshly provisioned VDI sessions. Those community reproductions corroborate the KB’s cause and the recommended workaround.

---

Official guidance and validated workarounds​

Microsoft’s advisory includes both a short-term manual workaround and a recommended scripted approach for non‑persistent environments:

• Manual registration (works for single machines or interactive troubleshooting):
  Run these PowerShell commands in the affected user session to register the packages and then restart SiHost/Explorer so the shell picks up the newly registered packages:
  

  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, restart the shell processes (for example, terminate/restart SiHost, explorer.exe, or sign out and back in). Microsoft documents these commands verbatim in the KB.
• Non‑persistent/VDI environments (recommended operational workaround):
  Microsoft recommends running a synchronous logon script that registers the required packages before Explorer is allowed to start. The KB supplies a sample batch wrapper that invokes PowerShell synchronously for each Add-AppxPackage registration; the idea is to block shell startup until registration completes, ensuring the packages are available to the session. This is the pragmatic mitigation for pooled desktop and similar non‑persistent stacks.

Independent community guidance mirrors the above — multiple administrators reported success by re‑registering a broader set of Shell and UI packages and by wrapping registration in logon scripts for VDI pools. Those community posts provide sample scripts and variants that automate the same registration sequence.

---

Reproductions, telemetry signals and prevalence (what we can verify)​

• Microsoft’s KB is clear about scope (24H2) and the update window (updates on or after July 2025, with KB5062553 cited as an example). This is authoritative.
• Community reproductions and forum posts show the phenomenon is real and that the Add-AppxPackage registration workaround fixes the immediate symptoms for many affected machines. Multiple independent reports on support forums, Microsoft Q&A and community threads corroborate the problem pattern and the effectiveness of re‑registering the packages.
• What remains not fully quantified is the scale of the impact across the installed base. Microsoft has not published high‑level telemetry figures for the number of devices impacted by KB5072911; estimating prevalence from forum volume is unreliable and likely biased toward cases where users were most affected. Treat public forum evidence as high‑fidelity proof-of‑concept but low‑quality for prevalence statistics. Use caution when extrapolating to fleet‑wide impact.

---

Operational recommendations — immediate, short‑term and long‑term​

Immediate actions for helpdesk and admins​

1. Apply the Microsoft KB remediation steps during user sessions to restore functionality, using the Add-AppxPackage commands documented in KB5072911. Restart SiHost/explorer or perform a sign‑out/sign‑in as required.
2. For users in non‑persistent or VDI pools, implement a synchronous logon script that registers the listed packages before letting the shell initialize. Microsoft provides a sample batch wrapper in the KB; adapt it to your environment’s orchestration.
3. If your support workflow expects remote fixes, prepare signed PowerShell scripts and remote execution plans — note that Add-AppxPackage requires appropriate privileges and that running these commands may be blocked by some app‑control policies or antivirus tools; test in a lab first.

Short‑term deployment guidance​

• Hold updates on images used for provisioning until you’ve validated the registration sequence on a test image. For managed fleets, use staged rings (pilot → broad deployment) and validate with users who represent non‑persistent/VDI scenarios. Microsoft’s release-health and safeguard holds are the authoritative channels for rollout status; watch those pages for when the vendor publishes a fix or KIR.
• If you operate golden images, apply the cumulative update, run the package registration once in the image, and capture the image after the registration is completed. This reduces the chance the race condition will appear for first-time logons from that image.

Long‑term and risk mitigation​

• Rework provisioning scripts so that package registration is explicit and synchronous: installation steps that assume the shell will wait for package registration are brittle.
• Add post‑update automated checks into your image pipeline that validate Start menu, Explorer and Settings startup at the first interactive logon. Automated smoke tests catch these regressions before wide rollouts.
• Maintain a documented rollback path for emergency scenarios (uninstall latest LCU from image or revert to previous snapshot) and keep a tested recovery image for remote repair tasks.

---

Analysis — strengths, weaknesses, and risk assessment​

Notable strengths​

• Microsoft documented the issue publicly and provided a concrete, actionable workaround (the Add-AppxPackage registration commands and a sample logon script). That allows rapid operational response and targeted mitigation rather than a blind rollback of security updates. The KB is explicit and prescriptive.
• The root cause is straightforward to reason about: a timing/ordering problem in package registration during a time‑sensitive provisioning path. Fixing the sequencing is tractable for administrators.

Practical weaknesses and risks​

• The workaround requires running Add-AppxPackage in the user session and, for pooled desktops, adding a synchronous registration step to the logon path. This can be operationally complex in large fleets and may increase logon time if not optimized. Microsoft’s recommended logon wrapper intentionally blocks Explorer to ensure registration — but any blocking step risks user‑perceived slowness.
• The KB’s remediation is procedural rather than binary: it fixes the symptoms by re‑registering packages, not by changing the underlying condition that allows the race to occur. Until an updated servicing package removes the race condition, the risk remains for new updates or different install orderings.
• Some enterprise policies or security tools may treat Add-AppxPackage activity as suspicious or may block execution; testing and policy exceptions may be required. Community posts note that Add-AppxPackage can fail with "resources in use" or other HRESULTs if other processes lock related files. This means the workaround may sometimes require multiple iterations or a careful order of operations.

Security trade-offs​

• Delaying security updates for the sake of stability is an unattractive general practice; the correct mitigation is to adopt workload‑aware rollout controls (pilot rings, targeted testing) and to implement Microsoft’s recommended workaround until the vendor ships a fix. Microsoft’s release-health guidance and KIR mechanisms are the appropriate channel to balance security and stability.

---

How to implement the non‑persistent (VDI) logon wrapper — practical example​

Microsoft’s sample batch wrapper demonstrates the required concept: synchronously run PowerShell commands to register packages before Explorer starts. Below is a distilled, practical example you can adapt and sign:

[USER=35331]@echo[/USER] off
REM Run these synchronously to ensure packages register before Explorer starts
powershell.exe -ExecutionPolicy Bypass -Command "Add-AppxPackage -Register 'C:\Windows\SystemApps\MicrosoftWindows.Client.CBS_cw5n1h2txyewy\AppxManifest.xml' -DisableDevelopmentMode"
powershell.exe -ExecutionPolicy Bypass -Command "Add-AppxPackage -Register 'C:\Windows\SystemApps\Microsoft.UI.Xaml.CBS_8wekyb3d8bbwe\AppxManifest.xml' -DisableDevelopmentMode"
powershell.exe -ExecutionPolicy Bypass -Command "Add-AppxPackage -Register 'C:\Windows\SystemApps\MicrosoftWindows.Client.Core_cw5n1h2txyewy\AppxManifest.xml' -DisableDevelopmentMode" REM Optionally log output / errors to a file for diagnostics

Notes when implementing:

• Test the wrapper in a lab VDI pool and measure logon times.
• Ensure the script runs under the correct user context and has permission to access the SystemApps manifest files.
• Add retry/backoff to handle transient file locks (community posts indicate Add-AppxPackage can fail when resources are in use).

---

What Microsoft should (and likely will) do next​

Microsoft’s KB states “We are working on a resolution and will provide more information when it is available,” which matches the vendor’s typical cadence: publish the known‑issue advisory and short‑term mitigations, then ship a patch or Known Issue Rollback (KIR) that avoids the need for manual registration. Administrators should monitor Microsoft’s release‑health/Windows 11 24H2 status pages for an updated KB or KIR and the normal update channels for a subsequent LCU that removes the race condition.

---

Practical checklist for support teams (quick reference)​

• Triage: Confirm affected machines are Windows 11, version 24H2 and recently applied an LCU released on or after July 2025.
• Repair: Re‑register the three named packages in the user session (Add-AppxPackage lines in the KB), restart SiHost/explorer, confirm Start/Menu/Settings restored.
• VDI: Implement the synchronous logon wrapper to register packages before Explorer launches; test for logon performance impact.
• Monitoring: Track Microsoft’s release-health page and KB updates for a permanent fix or KIR.
• Documentation: Record the occurrence, the remediation steps used, and the time-to-repair for future RCA and post‑mortem work.

---

Caveats, unknowns and flagged claims​

• The KB is explicit about the packages and the workaround; those technical facts are verified on Microsoft’s support page.
• The scale of the problem (how many devices in the wild are affected) is not published by Microsoft; community thread volume and anecdotal reports indicate multiple occurrences but cannot be used to estimate fleet-wide prevalence. This remains unverified and should be treated as such.
• Some community workarounds register a broader set of Shell/Appx packages (for example Microsoft.Windows.ShellExperienceHost and others). These variants have been used successfully in field repairs, but they are community‑provided; validate them against your environment before mass deployment.

---

Conclusion​

KB5072911 documents a clear, actionable provisioning-time regression in Windows 11, version 24H2 where updated XAML dependency packages can fail to register quickly enough to support shell startup. Microsoft’s guidance — manual package registration for individual remediation and a synchronous logon script for non‑persistent images — is practical and effective in the short term. Administrators must balance timely security patching with robust update-validation for images and VDI pools: adopt staged deployments, add automated post‑update smoke tests for the shell, and implement the documented registration script where necessary until Microsoft issues a permanent servicing fix or Known Issue Rollback. The KB and community reproductions give support teams the tools to restore affected endpoints quickly, but the operational burden of doing so at scale remains the central risk until Microsoft ships an update that removes the underlying race condition.

---

Source: Microsoft Support KB5072911: Multiple symptoms occur after provisioning a PC with a Windows 11, version 24H2 update - Microsoft Support

 

[ChatGPT]

Microsoft has acknowledged a provisioning-time regression in Windows 11, version 24H2 that can leave core shell components — Start Menu, Taskbar, File Explorer and Settings — unable to initialize after cumulative updates released since July 2025, and it has published temporary workarounds while a permanent fix is developed.

---

Background / Overview​

Windows 11’s modern shell is increasingly modular: many built-in UI surfaces are shipped as updatable AppX/MSIX containers and XAML-hosted packages rather than being statically compiled into a single monolithic shell binary. That modularity lets Microsoft deliver fixes and feature changes more frequently, but it also adds lifecycle steps during servicing: when an update replaces those packages, the servicing stack must write files to disk and register those packages into the user session before XAML-backed shell processes attempt to create UI objects.
Microsoft’s support bulletin KB5072911 explains that, starting with the July 2025 cumulative update tracked as KB5062553, certain updated XAML dependency packages may not be registering in time during provisioning or at first sign‑in. When the shell (Explorer.exe, StartMenuExperienceHost, ShellHost.exe and related XAML-hosting processes) starts before registration completes, XAML activation calls fail and the UI either crashes, shows “critical error” dialogs, or renders nothing. This is a classic timing/race condition: the OS attempts to instantiate UI objects before the packages those objects depend on are available to the newly created user session. Because the shell is central to day-to-day interaction, the result is a highly visible and immediately disruptive user experience.

---

What’s breaking — symptoms you’ll see​

When this provisioning regression manifests, affected systems can display one or more of the following symptoms:

• Start menu fails to launch or shows a “critical error” message.
• Taskbar is missing or blank even though Explorer.exe is running.
• File Explorer crashes or becomes unstable.
• System Settings silently fails to open (Start → Settings → System produces no UI).
• ShellHost.exe / StartMenuExperienceHost crashes during XAML view initialization.
• Other XAML-island views (embedded UI in apps) fail to render or crash.

Microsoft’s advisory lists these exact symptoms and explicitly ties them to XAML-package registration failures after cumulative updates released on or after July 2025. The vendor’s guidance also makes clear that two scenarios are highest risk: (1) the first interactive sign‑in after a cumulative update has been applied, and (2) non‑persistent environments (VDI, instant-clone pools, Windows 365 Cloud PCs) where packages are installed/provisioned per-logon. Independent community reports and technical outlets have reproduced and documented the same symptom set, confirming that the issue is broad and reproducible in affected topologies.

---

The root technical cause — a concise deep dive​

At its core the issue is ordering: modern Windows servicing will

• Replace package binaries on disk (AppX/XAML payloads),
• Re-register those packages into the OS and the user session so COM/XAML activations succeed,
• Allow shell processes (Explorer, ShellHost, StartMenuExperienceHost) to start.

If step (2) hasn’t completed before step (3) begins for a new user session, shell activation calls fail. The packages Microsoft named in the advisory include:

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

When those packages aren’t registered in time, XAML activation throws errors or exceptions, causing the shell to crash or render blank UI surfaces. Microsoft explicitly describes this registration timing problem in KB5072911. This is not a file-corruption issue in most instances; it’s a provisioning-time sequencing issue that becomes visible when the first interactive session starts immediately after servicing or when sessions are provisioned on-demand (non-persistent VDI).

---

Official response and temporary workarounds​

Microsoft has stated it is "working on a resolution" and published KB5072911 with two practical mitigations: a manual, interactive re-registration routine for single machines and a synchronous logon sample script for non‑persistent environments that forces package registration to complete before the shell launches. The manual in-session re-registration commands that Microsoft published are:

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

Run these commands in an affected user session (PowerShell launched in the user context). After running them, restart SiHost (Shell Infrastructure Host) or sign out and sign back in to allow the Immersive Shell components to pick up the registrations. Microsoft’s KB records the same commands and sequence. Bleeping Computer and other outlets have reproduced the fix in many cases and reported that re-registering those package manifests often restores shell functionality. However, this is a manual and user-session-bound recovery; it is not a permanent servicing correction.

---

Operational playbook for IT administrators​

For organisations that manage images, VDI farms, or large device fleets the incident requires a measured operational response. The following ordered playbook reflects Microsoft’s guidance, community experience, and practical trade-offs.

• Assess exposure
• Identify images and deployed devices that received cumulative updates on or after July 8, 2025 (the community-tracked initiating package is KB5062553). Pay special attention to golden images and non‑persistent VDI pools.
• Stop mass deployment to vulnerable topologies
• Do not push July‑and‑later cumulative updates to golden images used for provisioning until a permanent fix arrives and is validated in lab. Use pilot rings to limit exposure.
• Test and validate
• Reproduce the provisioning flow in a lab that mirrors production. Confirm whether registration completes before Explorer launches. Validate Microsoft’s synchronous logon wrapper in a controlled environment and measure login latency impacts.
• Implement Microsoft mitigations where necessary
• For single, affected endpoints: use the manual Add‑AppxPackage re-registration in the interactive session as a triage step.
• For non‑persistent pools: implement a synchronous logon script (Microsoft provides a sample) that registers the packages at logon and blocks Explorer from starting until registration completes. This enforces the required ordering, but it will increase first‑login time.
• Communicate and prepare support scripts
• Prepare helpdesk runbooks (the three Add‑AppxPackage commands and a restart/sign-out procedure). Inform users and stakeholders about expected longer first-logon times if synchronous registration is used.
• Track Microsoft fixes and rollback options
• Monitor Microsoft release health and update channels for the permanent fix or a Known Issue Rollback. If a fix is published, validate in lab then deploy through staged rings.
• Consider temporary workarounds carefully
• Blocking cumulative updates or scripting registration en masse introduces its own risk. Test any automation thoroughly before production rollout.

This structured approach reduces operational chaos and helps prevent large-scale provisioning disruptions that would otherwise produce helpdesk surges and reimage storms.

---

Trade-offs and risks of the published mitigations​

The published mitigations are useful but not without cost. Key trade-offs:

• Increased login time: Synchronous registration forces registration to complete before Explorer launches; this can lengthen first-logon time significantly in VDI and Cloud PC scenarios. Test the latency impact before deploying wide-scale.
• Operational complexity: Adding logon-time scripts or automations increases the configuration surface and can interact unpredictably with environment-specific login hooks (profile managers, FSLogix, UEM tools).
• Potential security posture decisions: Some administrators may be tempted to delay or block monthly cumulative updates to avoid the regression, but postponing security updates increases exposure to known vulnerabilities. The right balance must be found between stability and security.
• No public ETA: Microsoft’s bulletin states it is "working on a resolution" but does not provide a clear ETA or fleet telemetry in the advisory, making planning harder for large IT shops. The lack of public telemetry about prevalence means administrators must assume conservative exposure.
• Manual fixes aren’t scalable: The Add‑AppxPackage commands are effective for single-user remediation but impractical for tens of thousands of endpoints without careful automation.

These trade-offs make it imperative for organizations to test thoroughly and to rely on staged deployments and pilot rings rather than broad, immediate rollouts.

---

Broader implications — servicing model vs. operational stability​

This incident lays bare a tension in modern Windows servicing: modularizing the shell as updatable packages improves agility but also increases the number of moving parts in the servicing lifecycle. When ordering and registration matter, even a small timing regression can cascade into broad functional failures.
The problem is especially acute in educational and enterprise provisioning workflows where devices are imaged en masse or where non‑persistent VDI pools provision user sessions on-demand. In such topologies, a registration timing slip is reproducible and costly at scale. The episode is one in a string of servicing incidents that have placed increased operational burden on IT teams to pilot updates more conservatively and script around vendor regressions.

---

Practical guidance for home users and power users​

• If your personal PC is unaffected: consider pausing automatic updates briefly until Microsoft’s fix is available if you are risk-averse, but be aware of the security trade-offs of delaying patches.
• If you encounter the broken shell symptoms after an update:
• Try signing in, opening an elevated PowerShell in the affected user context, and running the three Add‑AppxPackage registration commands shown in KB5072911. Sign out and sign back in or restart the machine afterward.
• If you cannot access Settings and prefer not to run commands manually, use another account (if available) or boot to a recovery environment to perform administration tasks.
• Consider using System Restore or the “Go back” recovery options if they are available and applicable, but note Microsoft’s changes to System Restore retention windows in recent servicing may have altered retention behavior (test and confirm on your systems).

Always back up important data before applying major updates or performing image rollbacks.

---

What we still don’t know (and what to watch)​

• Prevalence: Microsoft has not published fleet-level telemetry in KB5072911, so exact numbers of affected devices are not public. That leaves admins to estimate exposure via pilots and aggregated helpdesk reports. This absence of telemetry complicates risk assessment. Caution: any prevalence estimates you see in community threads are anecdotal until validated at scale.
• ETA for a permanent fix: Microsoft’s advisory offers no firm delivery date. Track Microsoft’s official channels for a Known Issue Rollback or a servicing patch that corrects the registration sequencing.
• Whether other cumulative updates or servicing flows will trigger similar regressions: the modular model improves agility but increases systemic interdependence; it’s possible other servicing edge cases will surface if registration ordering is not tightly controlled.

---

Bottom line — immediate steps for readers​

• If you are an IT administrator: stop pushing July‑and‑later cumulative updates to golden images used for provisioning until you can validate the fix; implement Microsoft’s synchronous registration for non‑persistent pools if necessary; prepare helpdesk scripts for manual re-registration; and monitor Microsoft release channels for a permanent fix.
• If you are a home or power user seeing broken Start / Taskbar / Settings: run the three Add‑AppxPackage commands in an affected user session and restart (or wait for Microsoft’s permanent fix). Use System Restore or rollback only if you are comfortable with those recovery operations.
• If you are undecided about updating: pilot updates first and use update rings; do not assume every device will behave the same — non‑persistent provisioning topologies are highest risk.

---

Windows 11’s 24H2 provisioning regression is a reminder that the speed and modularity of modern OS servicing come with new operational responsibilities. Microsoft’s KB5072911 lays out the problem, the temporary mitigations, and the packages involved; third‑party reporting and community reproductions confirm the same symptom set and the effectiveness of re‑registration in many instances. Administrators must balance security patching with careful testing and, where necessary, scripted mitigations until a permanent servicing correction arrives.

---

Source: How-To Geek Windows 11 24H2 is breaking a lot of stuff