[Bug]: KB5094127 breaks all MSIX/AppX deployment inside Windows Sandbox (Windows 10)

[generalmimon]

Windows Sandbox version

10.0.19041.7417 (from running ver in the Sandbox)

Windows build number

10.0.19045.7417

Other software

winget / App Installer (Microsoft.DesktopAppInstaller) v1.28.240, installed via the Microsoft.WinGet.Client PowerShell module (latest on PSGallery) using Microsoft's documented bootstrap. The same v1.28.240 works fine on the host; it only fails to deploy inside Sandbox.

Steps to reproduce the bug

Disclosure: this report was drafted largely by an AI assistant — Anthropic's Claude Opus 4.8 (model ID: claude-opus-4-8) with high effort, running in the Claude Code CLI — from a hands-on troubleshooting session, then reviewed by me before submitting.

1. Host has cumulative update KB5094127 installed.
2. Launch Windows Sandbox (the .wsb configuration is in the "Included System Information" section).
3. In an elevated PowerShell inside the Sandbox, run Microsoft's documented winget bootstrap (https://learn.microsoft.com/windows/package-manager/winget/#install-winget-on-windows-sandbox):

   Set-ExecutionPolicy RemoteSigned -Force
   Install-PackageProvider -Name NuGet -Force | Out-Null
   Install-Module -Name Microsoft.WinGet.Client -Force -Repository PSGallery | Out-Null
   Repair-WinGetPackageManager -AllUsers -Verbose

4. The dependencies (VCLibs, WindowsAppRuntime 1.8) install fine; the final Microsoft.DesktopAppInstaller bundle registration fails.

Confirmed to be caused by KB5094127 (toggled both ways, 100% reproducible):

• Uninstall KB5094127 on the host -> reboot -> problem gone, winget installs normally in Sandbox.
• Let Windows Update reinstall KB5094127 -> reboot -> problem returns.

Expected result

App Installer (winget) deploys successfully inside Windows Sandbox, as it did before KB5094127.

Actual result

Repair-WinGetPackageManager (and any direct Add-AppxPackage of a .msix/.msixbundle) fails during the AppX deployment Indexed -> Resolved stage:

Add-AppxPackage : Deployment failed with HRESULT: 0x80073CF0, Balíček nelze otevřít.
error 0x80070002: Opening file from location: AppxManifest.xml failed with error: Systém nemůže nalézt uvedený soubor.

6/17/2026 8:51:20 AM      854          Successfully added the following uri(s) to be processed:  C:\Program
                                       Files\WindowsApps\Microsoft.DesktopAppInstaller_2026.409.2145.0_neutral_~_8wekyb3d8bbwe\AppxMetadata\AppxBundleManifest.xml C:\Program
                                       Files\WindowsApps\Microsoft.DesktopAppInstaller_1.28.240.0_x64__8wekyb3d8bbwe\AppxManifest.xml C:\Program
                                       Files\WindowsApps\Microsoft.DesktopAppInstaller_1.28.240.0_neutral_split.scale-100_8wekyb3d8bbwe\AppxManifest.xml C:\Program
                                       Files\WindowsApps\Microsoft.DesktopAppInstaller_1.28.240.0_neutral_split.language-cs_8wekyb3d8bbwe\AppxManifest.xml.
6/17/2026 8:51:20 AM      405          error 0x80070002: Opening file from location: AppxManifest.xml failed with error: Systém nemůže nalézt uvedený soubor.
                                       .
6/17/2026 8:51:20 AM      402          error 0x80070002: Reading manifest from location: AppxManifest.xml failed with error: Systém nemůže nalézt uvedený soubor.
                                       .
6/17/2026 8:51:20 AM      605          The last successful state reached was Indexed. Failure occurred before reaching the next state Resolved. hr: 0x80073CF0

(see the install-winget-in-windows-sandbox-error.txt attachment for the full transcript; this is only an excerpt)

Note: unfortunately, some parts of the messages are localized into Czech - here's the translation:

• Balíček nelze otevřít. = Package could not be opened.
• Systém nemůže nalézt uvedený soubor. = The system cannot find the file specified.

I don't know which AppxManifest.xml cannot be found. The Get-AppPackageLog output lists exactly four manifests being processed, and all four exist on disk (verified with Get-ItemProperty in the attached transcript):

File	Size (bytes)
...DesktopAppInstaller_1.28.240.0_x64...\AppxManifest.xml	18801
...split.scale-100...\AppxManifest.xml	842
...split.language-cs...\AppxManifest.xml	845
...2026.409.2145.0_neutral_~...\AppxMetadata\AppxBundleManifest.xml	36156

Key discriminator — host is fine, only Sandbox is broken:

• On the host, winget --version prints v1.28.240 — the exact same version that fails to deploy inside Sandbox. So winget is not at fault; AppX deployment inside Sandbox is. (Sandbox builds each session from a base derived from the host, so the KB5094127 regression rides in from the host but only manifests in Sandbox.)

Additional isolation findings:

• Not winget- or version-specific: an older App Installer (v1.12.470) and even a single bare AppInstaller_x64.msix fail identically — so ANY package-file deployment is broken.
• Package files/archives are valid; file ACLs, framework dependencies, signatures and disk space are all fine.
• Re-registering an ALREADY-EXTRACTED package from a folder works (Add-AppxPackage -Register <folder>\AppxManifest.xml of an existing app succeeds). Only staging from a .msix/.msixbundle FILE fails. The broken capability is reading the manifest while staging a package from a package file.

Workaround: uninstall KB5094127 and pause Windows Update, then reboot. Not viable long-term (it is a security update and reinstalls automatically).

Impact: with KB5094127, winget and any MSIX-packaged app can no longer be installed in Windows Sandbox.

Full transcript attached: install-winget-in-windows-sandbox-error.txt (PowerShell session + Get-AppPackageLog + the Get-ItemProperty proof that the manifests exist).

Included System Information

Sandbox configuration (.wsb file):

<Configuration>
  <VGpu>Disable</VGpu>
  <Networking>Enable</Networking>
  <AudioInput>Disable</AudioInput>
  <VideoInput>Disable</VideoInput>
  <ProtectedClient>Enable</ProtectedClient>
  <PrinterRedirection>Disable</PrinterRedirection>
  <ClipboardRedirection>Disable</ClipboardRedirection>
  <MemoryInMB>4096</MemoryInMB>
</Configuration>