Windows (MSIX): App fails to launch with "Another program is currently using this file" after update; persists through service stop, AppX re-registration; only reboot resolves

Related / possibly duplicate reports of the same underlying issue:

• #76357 - near-identical symptom and title, has repro
• #77421 - quit-for-update never completes; stale processes hang relaunch with the same error
• #77379 - same root-cause theory: stale AppContainer job (Container_Claude_...) held by svchost.exe, only reboot clears it
• #53247 - orphaned Silo/Job Object after crash, same HRESULT family (AppModel-Runtime EventID 215/208)
• #75337 - deferred-registration loop, same error text, resolved by sign-out or reboot
• #61635 - same symptom reported as ARM64-only and tagged invalid/stale; this report (x64) plus confirmation that manual Add-AppxPackage -Register succeeding still doesn't fix launch suggests that ARM64-only conclusion was incomplete

This report additionally confirms: (1) the bug reproduces on x64, not just ARM64, and (2) forcing a clean AppX re-registration does not resolve it, which narrows the cause toward a kernel-held object (AppInfo/UAC-owned container job) rather than a registration/ACL problem.

Same issue

Confirming this on ARM64 and on a much newer build — still completely unfixed.

Environment

• Claude_1.25927.0.0_arm64__pzs8sxrjxfjjc (in-app auto-update from 1.24012.11.0)
• Windows 11 Home 26200, Snapdragon X Plus (ARM64)
• Uptime at failure: ~26 h; failure began the moment the update was applied mid-session

Same symptom, same dead ends as your steps 2 and 4. But I think I found the piece your step 3 was missing, which upgrades your conclusion from inferred to confirmed.

The 0x80070020 is there — it's just in a different log

You checked AppXDeploymentServer/Operational and found no 0x80070020. It isn't logged there because this isn't a deployment failure — deployment succeeds (Get-AppxPackage reports Status: Ok). It's an activation failure, and it lands in Microsoft-Windows-AppModel-Runtime/Admin, which is readable unelevated:

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-AppModel-Runtime/Admin'; StartTime=(Get-Date).AddMinutes(-10); Level=2} |
  Select-Object @{n='T';e={$_.TimeCreated.ToString('HH:mm:ss.fff')}}, Id, Message

Every launch attempt produces:

Id 215  0x80070020: Cannot create the Desktop AppX container for package
                    Claude_1.25927.0.0_arm64__pzs8sxrjxfjjc because an error
                    was encountered converting the job.
Id 208  0x80070020: Cannot create the process for package
                    Claude_1.25927.0.0_arm64__pzs8sxrjxfjjc because an error
                    was encountered while configuring runtime. [LaunchProcess]

0x80070020 = ERROR_SHARING_VIOLATION, and "converting the job" is the container/silo conversion step — exactly the stale kernel object you inferred. The user-facing dialog is just that HRESULT rendered as a string, which is why its title bar shows the package path and misdirects everyone into hunting for a locked file in WindowsApps.

Occasionally one process does get through before the cascade fails, which I think is why this looks intermittent to some reporters:

Id 210  Created Desktop AppX container {B6542796-...} for package Claude_1.25927.0.0...
Id 211  Added process 20108 to Desktop AppX container b6542796-...
Id 215  0x80070020: Cannot create the Desktop AppX container ... converting the job.   <- subsequent processes

Also worth noting for triage: main.log never gets a single new line. It's frozen at the last pre-update write, because the app dies before logging initializes. Anyone debugging from app logs alone will find nothing.

CoworkVMService is not the cause — timestamps rule it out

Sibling reports (#83968, #84005) pin this on CoworkVMService, and it's an understandable suspect: it's Automatic, runs as SYSTEM, and its binary lives inside the package (...\Claude_<ver>_arm64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe). I chased it too. Sub-second timestamps clear it:

| Time | Event |
|---|---|
| 12:00:49.387 | Service stop requested (C:\ProgramData\Claude\Logs\cowork-service.log) |
| 12:00:50.372 | Event 215 — 0x80070020 container creation fails |
| 12:00:50.836 | Starting CoworkVMService as Windows service |

The container error fires ~460 ms before the service starts, and the service was fully stopped at that instant. Reproduced identically on the previous attempt (error 11:59:23.817, service start 11:59:24.380). The service is started by the failing launch — it's downstream, not causal. I also confirmed launching with the service stopped fails exactly the same way.

Corroborating your step 2: Stop-Service CoworkVMService -Force succeeds unelevated, but Set-Service -StartupType Disabled returns Access is denied — matching your TrustedInstaller-ACL observation.

Everything else ruled out

• Add-AppxPackage -DisableDevelopmentMode -Register "...\AppxManifest.xml" → returned OK, launch still failed. Independent confirmation of your step 4 on ARM64.
• No leftover package versions — 1.24012.11.0 and 1.24012.9.0 folders were already cleanly removed.
• No process holds package identity: swept all of Win32_Process for anything executing from or referencing the package path. Nothing.
• Killed a stale chrome-native-host.exe and verified the file unlocked — no effect (that's a real but separate bug, below).

Reboot is the only recovery, consistent with #53247, #61635, #73107, #76357, #77379.

Separate bug the same update flow exposes

While the app is wedged, main.log from the prior session shows the post-update refresh of the Chrome native host failing repeatedly:

[error] [Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked,
copyfile '...\WindowsApps\Claude_<ver>...\app\resources\chrome-native-host.exe'
      -> '...\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe'

38 occurrences across one 3-day log — Windows won't overwrite the running host EXE, so the binary silently stays versions behind (mine was two app versions stale) and the Chrome integration quietly degrades. Not the cause of the launch failure, but the same update flow leaving things half-finished. Worth killing the old host before the copy.

Ask

Seconding the requested fix. Given how many reports this now has (#53247, #61635, #73107, #75337, #76357, #77379, #77421, this one) across x64 and ARM64 and at least four package versions spanning months, a mitigation would help even before the root fix: the app could detect 0x80070020 from AppModel-Runtime on a failed relaunch and surface "Windows needs a restart to finish updating Claude" instead of a raw Win32 error string that sends people hunting for a nonexistent locked file.