Microsoft has shipped an optional cumulative update, KB5046714, to repair crashed Store app installs on Windows 10 version 22H2 after a faulty WinAppSDK 1.6.2 servicing release blocked package operations. The fix, which arrived as a non-security optional update on November 12, 2024, addresses a regression that left administrators and users grappling with cryptic “Something happened on our end” errors and error code 0x80073CFA when trying to update or remove packaged apps such as Microsoft Teams.

The breakdown: what went wrong
On affected systems, attempts to install, update, or uninstall Microsoft Store apps—including many enterprise-critical titles—suddenly failed. The Store displayed a generic “Something happened on our end” message, while PowerShell attempts returned the 0x80073CFA error code. In corporate environments, helpdesks reported a surge in tickets related to Teams update failures, with users unable to join meetings or access new features. The 0x80073CFA error code, which points to a package removal failure, became a frequent sight in administrative logs. Users of Windows 10 version 22H2 were the primary victims, particularly those whose machines had pulled in the problematic WinAppSDK 1.6.2 runtime, either via an app dependency or direct servicing update. Traditional Win32 applications were unaffected, highlighting the isolated but crippling nature of the bug.

Root cause: a single SDK servicing misstep
The culprit was WinAppSDK 1.6.2, a servicing update to the Windows App SDK that Microsoft published on November 12. The WinAppSDK acts as a bridge between modern Windows app models—WinUI, WinRT, and UWP packaging—and the platform’s update mechanisms. When that bridge breaks, every app relying on it sees installation and servicing operations fail. Microsoft’s analysis traced the regression to a change in this servicing update that corrupted package servicing operations. Realizing the scope, the company pulled the offending release and began work on a fix. The resulting patch, KB5046714, is a targeted optional cumulative update specifically for Windows 10 22H2, designed to untangle the servicing stack without altering other OS components.

Who needs to act
You’re at risk if you run Windows 10 version 22H2 and have any packaged apps built on the WinAppSDK. Organizations using Microsoft Store for Business or central deployment of Store-packaged applications may see widespread fallout, as the broken runtime can propagate merely by an app requesting the dependency. To confirm, run a quick detection check in PowerShell as administrator:
Get-AppxPackage WindowsAppRuntime.1.6 -AllUsers | Where { $_.Version -eq '6000.311.13.0' }
If the command returns a package entry, your system holds the problematic runtime and must be remediated. The detection is quick—run it across your device fleet to gauge exposure before planning remediation.

The fix: install KB5046714 or use PowerShell
Microsoft’s primary recommendation is to install KB5046714. This optional update resolves the servicing stack conflicts directly. Because it’s optional, it won’t download automatically; users must manually select it in Windows Update’s “Optional updates” section or grab the standalone package from the Microsoft Update Catalog. After installation and a reboot, Store app operations return to normal. IT admins can push the update via Intune, SCCM, or WSUS after adjusting optional update policies.
For immediate relief, Microsoft provided a PowerShell workaround. The script re-registers the Windows App Runtime packages for all users and forces repair of affected components. This method requires elevated privileges and precise execution. Microsoft’s official guidance details the exact commands, and administrators should test them on a single machine before broad rollout. However, for most home users, waiting for or manually initiating the KB is the safer path. A mistyped command can corrupt packages, turning a fix into a larger problem.

The curious case of triple-install
Among the remediation notes, some administrators received an unusual instruction: uninstall WinAppSDK 1.6.2 and install its replacement, WinAppSDK 1.6.3, three times consecutively. The rationale, per Microsoft’s internal communications, is that certain servicing entries require multiple install transitions to fully clear. This triple‑install step is far from standard and should be treated as a high‑risk workaround for deeply entangled systems. Before deploying it, IT teams must pilot and validate the procedure on a small device set. If you don’t fully understand why a triple installation is needed, skip this step and stick with the official KB or PowerShell path.

Risks and caveats
Neither path is entirely risk-free. Optional updates, though tested, can carry minor regressions—in rare cases, an optional patch has introduced new issues like performance hiccups or driver conflicts. The PowerShell workaround, if misapplied, can corrupt app packages or system state. Enterprises using WSUS or SCCM may face additional hurdles: optional updates often aren’t automatically approved, requiring manual catalog sync or policy changes. Moreover, devices that suffered repeated failed installs might retain partial package states that need deeper servicing stack repairs—running DISM or SFC scans—if the basic fixes don’t stick. Pilot each remediation method before mass deployment, and keep a rollback plan ready.

Strategic recommendations
For home users: Open Windows Update, check for optional updates, and install KB5046714. Reboot, then retry the stalled app operations. If you frequently rely on Store apps, don’t wait for a possible automatic rollout—proactively grab the update. The PowerShell route is only advisable for advanced users comfortable with command-line administration.
For IT administrators: Inventory your fleet with the detection script to map affected machines. Deploy KB5046714 to a pilot ring and monitor for side effects. Keep a tested PowerShell remediation script as a fallback. If you encounter the triple‑install guidance, pilot it rigorously and only deploy as a last resort. Communicate the fix and its schedule to your users to reduce confusion and support tickets.
For developers: Audit dependency management. Avoid implicit runtime upgrades in production environments. Pin your WinAppSDK version and test your app’s servicing resilience so a future dependency shift doesn’t silently break deployment. Add telemetry early in your app to catch servicing failures before they become user-facing.

Big-picture lessons
This incident underscores how a flaw in a shared runtime can cascade across the ecosystem. Microsoft’s decision to pull the bad release and ship a surgical optional update was sound, but the optional nature created friction for users who skip manual updates. Rapid, well-signaled patches—perhaps pushed as critical—would have reduced downtime. The episode also validates the need for detailed, pre‑tested PowerShell remediation scripts as a tier‑1 response tool for admins. Going forward, tighter integration testing for SDK servicing changes and clearer communication channels would prevent such disruptions from reaching production. The WinAppSDK regression serves as a case study for the importance of micro‑patching agility and cross‑team coordination.

What remains murky
The exact prevalence of affected systems is not publicly documented. Community reports suggest a meaningful user impact, but without official telemetry the scale remains fuzzy. Similarly, the triple‑install workaround, while circulated by Microsoft, is an outlier; its necessity appears limited to edge cases, and administrators should not apply it uniformly. Where official advisories are silent, test first and trust internal diagnostics. Until Microsoft publishes a root‑cause analysis postmortem, some details will remain speculation.

Recovery and beyond
The WinAppSDK 1.6.2 saga is a stark reminder that modern Windows relies on interlocking components, and a single servicing misstep can silently break critical capabilities. For Windows 10 22H2 users, relief is at hand with KB5046714 or the PowerShell toolkit. By marrying prompt patching with better dependency controls, both Microsoft and the community can harden the ecosystem against the next runtime regression. The immediate crisis is solvable; the longer‑term discipline is what will prevent a repeat.