Claude Desktop (MSIX, x64) unlaunchable after update: AppInfo holds a stale AppContainer Job; killing all processes is not sufficient

Summary

Claude Desktop (Store/MSIX, x64) becomes completely unlaunchable after a Store update, with a Windows dialog reading "Another program is currently using this file." — 0x80070020, ERROR_SHARING_VIOLATION.

The cause is captured directly rather than inferred: the AppInfo service holds a stale AppContainer Job handle naming a package version that is no longer registered. Creating the new version's container collides with it.

Two things here are not in the existing reports:

1. A handle capture on x64. #61635 proposed the AppInfo mechanism but was ARM64-only. This is the same mechanism, observed on x64, with the dump attached.
2. Killing every process does not clear it. All package processes were killed and CoworkVMService stopped at 04:39; a launch attempt at 04:41 produced fresh 208/215 with nothing of the package alive. Only a reboot released the handle. The "close it and retry" guidance in the other issues therefore does not apply to this path.

Environment

| | |
|---|---|
| OS | Windows 11 Pro 25H2, build 26200.9168 |
| Arch | x64 |
| Install source | Microsoft Store (MSIX) |
| Registered package at failure | Claude_1.34493.0.0_x64__pzs8sxrjxfjjc, Status Ok |
| Version that had been running | 1.32885.1.0 |
| Boot at time of failure | 2026-08-18 14:25:03 (the machine was deliberately not rebooted, to preserve the state) |

Timeline (2026-08-21, local)

| Time | Event |
|---|---|
| 03:05:00 | AppXDeploymentServer 1230 — hardlinks from Claude_1.32352.0.0 have no packages in repository |
| 03:05:12 | AppXDeploymentServer 658 — registration of 1.34493.0.0 deferred because 1.32885.1.0 is still running |
| 04:20 | Launch fails. Dialog titled C:\Program Files\WindowsApps\Claude_1.34493.0.0_… |
| 04:28:17 | AppModel-Runtime 208 / 215 / 217 ×N — create Desktop AppX container → 0x80070020 → rollback |
| 04:39:35 | Elevated sweep: CoworkVMService stopped; chrome-native-host.exe and claude.exe killed; cowork-svc.exe exited with the service |
| 04:41:51 | Launch still fails — fresh 208/215 with no package process alive |
| 05:00 | Evidence collected, including the handle dump |
| ~05:05 | Reboot |
| 05:08–05:10 | Launch succeeds. Only 210/211 (activation requested → succeeded), 201, 217. No 208/215 |

33 AppModel-Runtime 208/215 failures in the preceding 14 days; 24 container-leak signatures during this incident.

Direct evidence — the stale Job handle

handle64.exe -a -p <AppInfo PID> while the failure was live:

660: Job   \Container_Claude_1.32885.1.0_x64__pzs8sxrjxfjjc-S-1-5-21-<redacted>

At that moment Get-AppxPackage reported only Claude_1.34493.0.0_x64__pzs8sxrjxfjjc, Status Ok.

So AppInfo was pinning a Job object named for a version that no longer existed in the package repository. That is precisely why creating the new version's container returned a sharing violation.

Post-reboot control

Nothing was reinstalled, repaired, or re-registered — only rebooted.

• Registered: Claude_1.34493.0.0_x64__pzs8sxrjxfjjc, Status Ok
• All 10 running Claude.exe execute from that same version's folder (verified via ExecutablePath)
• Launch produces 210/211 only; no 208/215 since boot

This rules out package corruption. The stale handle was the whole of it.

Root cause, as far as the evidence goes

Helper processes from the previous package version survive app shutdown, so the Store update is deferred (event 658 names which version deferred it). The AppInfo service retains a handle to that version's AppContainer Job and does not release it when the processes die. When the new version is finally registered, container creation collides with the stale Job and fails with ERROR_SHARING_VIOLATION, surfacing as the generic "file in use" dialog.

The obvious fix is insufficient. Terminating the application's whole process tree is a reasonable first instinct — it is what one would propose from the deferral evidence alone — but the 04:39 → 04:41 sequence shows the handle outlives every process of the package, because it is held by a system service outside the application. Any fix has to release or invalidate that Job, not merely close the app.

Prior chapter, kept separate

This incident did not arise from nowhere; the precondition — an older version still running at the moment a new one is registered — has its own history on this machine, reported separately to Anthropic support on 2026-08-14 and 2026-08-18 with a five-week log analysis. In short: every staged update on this machine is deferred at staging time and registers only later, or not at all; two versions never registered before being superseded.

That is a different failure (updates not applying) and is deliberately not merged into this report. It is mentioned only because it explains why version 1.32885.1.0 was still alive at 03:05:12 to defer 1.34493.0.0 — the two chapters meet exactly at event 658 and nowhere else.

Worth noting

The release notes for 1.32885.1.0 — the version that was live when this failed — claim "fixed update installs repeatedly failing after a newer update replaced one already staged." Whatever that fix addressed, it does not cover this path.

Reproduction

1. Have Claude Desktop (Store/MSIX) running.
2. Let a Store update stage while helper processes are alive → event 658, registration deferred.
3. Attempt to launch. The dialog appears; AppModel-Runtime logs 215/208 + 217.
4. Kill every package process and stop CoworkVMService, then launch again → still fails.
5. Reboot → launches normally.

Recurs on this machine at essentially every update.

Impact

The desktop app is unlaunchable until a reboot. Because killing processes does not help, the workaround suggested in the related issues does not resolve it, and a user with no diagnosis available is left with an app that simply will not start.

Related

#76357 (open, x64, no maintainer response) · #61635 (AppInfo mechanism, ARM64) · #46179 (closed, no fix) · #42776 · #51847 · #53247

Attached

All artifacts below are in this gist (redacted; verified free of SIDs, usernames, addresses and tokens before publishing): https://gist.github.com/qraveh/6c5d4055717043b3cca03a7b26326498

| File | Contents |
|---|---|
| 08-handles-appinfo.txt | the AppInfo handle dump — the decisive artifact |
| 04-appmodel-runtime-events.txt | full 208/215/217 messages |
| 05-appx-deployment-events.txt | deployment events including 658 |
| 01-packages.txt / 02-processes.txt | registered packages, live processes with paths |
| 03-service.txt / 06-appxlog.txt / 07-windowsapps-dirs.txt / 10-system.txt | supporting state |
| FILTERED-main.log, FILTERED-cowork_vm_node.log | app logs, filtered to the update/exit/lock lines |

A post-reboot control bundle was collected the same way and is available if useful. All artifacts are redacted (SIDs removed).