[BUG] Windows/MSIX: update installs successfully, then Claude launch fails with AppModel-Runtime 215/208 (0x80070020)
Summary
After an in-place Claude Desktop update on this Windows x64 machine, the new
package registers successfully but Desktop does not reopen. Clicking its icon
does not recover it and no error dialog appears. Restarting Windows restores
launch.
New evidence collected August 28: the failure is not silent in every Windows
log. Microsoft-Windows-AppModel-Runtime/Admin records 215/208 with
0x80070020 during the failed launches. This closely matches
#53247, including its
update-triggered reproductions.
This revision corrects the earlier conclusions that no Windows error existed,
that every possible file lock was excluded, and that a particular leaked Job
object or damaged ACL had been proven responsible. None of those broader claims
is established by the evidence.
Environment
- Windows 11 Home 25H2, build 26200.9168, x64.
- Claude Desktop MSIX, package family
Claude_pzs8sxrjxfjjc. - Latest captured failing transition:
1.37937.1.0to1.37937.3.0. CoworkVMServiceis installed and configured for automatic startup.- All timestamps below are America/Chicago, CDT (UTC-05:00).
Reproduction and impact
- Use the MSIX Desktop build normally and allow an in-place update, including an
idle-triggered update.
- The app quits and package registration completes.
- Desktop does not return; a subsequent manual launch also fails.
- Restart Windows; the installed version then launches.
The earlier investigation recorded 9 reboot-associated recoveries among the
last 12 updates, including the last 8 consecutively and all 7 identified idle
updates. These are historical counts from that investigation, not 12 controlled
trials repeated for this revision. Three updates recovered without reboot,
including two approximately 32–33-second relaunches. The problem is recurrent,
not universal across every update.
Directly verified failure and recovery
Channel: Microsoft-Windows-AppModel-Runtime/Admin.
2026-08-27 20:22:09.473 Event 215, record 47314
0x80070020: Cannot create the Desktop AppX container for package
Claude_1.37937.3.0_x64__pzs8sxrjxfjjc because an error was encountered
converting the job.
2026-08-27 20:22:09.473 Event 208, record 47315
0x80070020: Cannot create the process for package
Claude_1.37937.3.0_x64__pzs8sxrjxfjjc because an error was encountered
while configuring runtime. [LaunchProcess]The same pair recurs at 23:09:46.551 during the previously captured manual
launch, and again through 23:10:10. The prior live capture counted zero Desktop
processes before the launch and again 12 seconds later. Those two snapshots
alone cannot exclude a very short-lived process between them.
After Windows booted at 23:11:23 (CIM boot time), the same runtime channel recorded:
2026-08-27 23:12:33.804 Event 210, record 47426
Created Desktop AppX container for Claude_1.37937.3.0_x64__pzs8sxrjxfjjc.
2026-08-27 23:12:33.806 Event 201, record 47428
Created process 24908 for application Claude_pzs8sxrjxfjjc!Claude
in package Claude_1.37937.3.0_x64__pzs8sxrjxfjjc. [LaunchProcess]The success excerpts omit the container identifier. Earlier timeline boot values
used System event 6005 (event-log service startup); that is not exactly the same
measurement as CIM boot time.
The retained runtime log also contains this signature on August 26 for version
1.37937.1.0. Across August 26–27 there are 16 event-215 and 8 event-208 records:
24 error records, not 24 failed updates.
<details>
<summary>Historical update/return timeline retained from the earlier investigation</summary>
The earlier investigation supplied these times. They have not all been
independently remeasured for this revision. The final app-return time is now
confirmed by the runtime event above. Boot-column values use System event 6005,
not CIM boot time. Delays include time before the user chose to reboot/relaunch;
they are not controlled measurements of how long the app would take to self-recover.
| App quit | App returned | Event 6005 in between |
| --- | --- | --- |
| July 24 14:07:05 | July 24 14:09:36 | None |
| August 3 17:31:50 | August 3 17:32:22 | None |
| August 4 23:42:48 | August 5 00:03:32 | August 5 00:02:27 |
| August 7 23:35:21 | August 7 23:35:54 | None |
| August 11 18:20:49 | August 11 18:23:50 | August 11 18:22:43 |
| August 13 18:52:21 | August 13 22:54:11 | August 13 22:46:06 |
| August 15 04:33:46 | August 15 17:40:45 | August 15 17:39:39 |
| August 18 01:24:24 | August 18 10:08:35 | August 18 10:06:48 |
| August 18 17:19:01 | August 19 04:29:14 | August 19 04:27:59 |
| August 20 19:59:30 | August 20 21:48:46 | August 20 21:09:56 |
| August 26 approximately 01:01 | August 26 05:17:43 | August 26 05:17:02 |
| August 27 20:22:08 | August 27 23:12:33 | August 27 23:11:44 |
All dates are 2026. The August 26 quit time came from package-servicing events,
not an application quit record. The original investigation's wider app-start
comparison found that post-boot launch was unusual outside these failed updates;
that is supporting observational evidence, not proof of a particular mechanism.
</details>
Why the earlier checks were misleading
- TWinUI event 1621 says the activation attempt completed successfully on both
failed and successful launches. It is not proof of application launch success.
- AppXDeploymentServer records successful registration and ACL-repair events,
while AppModel-Runtime records the later container/launch failure. These results
are compatible. ACL repair messages do not prove the original causal defect.
- The previous elevated Handle scan found no matching handles under the
WindowsApps install directory. That does not exclude locks on package registry
hives elsewhere or other object types. 0x80070020 is a sharing violation, but
does not identify its owner or the particular locked object.
- The inspected MSIX LocalCache main logs last changed August 20. This is a
logging-location observation; it does not establish that all application
logging stopped or that server-side telemetry missed the failure.
Recovery attempts and limits
- Earlier investigation: stopping/starting CoworkVMService and terminating
package-owned Claude processes did not restore launch on this machine.
- Reboot restored launch. Windows sign-out alone has not been tested here.
- Manual re-registration, clean reinstall and SYSTEM hive unloading have not
been tested here. Reports of their results on other machines are not local tests.
- No stale Job owner, leaked hive, or exact service/updater race was captured on
this machine before the reboot. Those remain hypotheses.
- A useful healthy control: after boot, CoworkVMService joined one package
container before Desktop successfully launched in another. Service presence
or being first in time is therefore not sufficient evidence of failure.
Requested engineering investigation
- Correlate successful MSIX servicing with the failing runtime job/container
conversion, including service startup and package hive/silo lifetimes.
- Provide a supported, data-preserving recovery for this signature, preferably
without ending the Windows session.
- Verify actual relaunch, not just successful package registration, and surface
a useful error when relaunch fails instead of leaving Desktop absent.
Related evidence: #53247,
#67911, and
#80286.
The original #61635 author later revised the Job-only explanation;
its opening theory should not be treated as confirmed causation here.