[BUG] Windows MSIX: opening the sandboxed Browser pane bricks a working install when CoworkVMService is half-registered after auto-update (0x80073D28)
Summary
A working Claude Desktop MSIX installation gets bricked at runtime — "There's a problem with Claude. Reinstall the application from its original install location or contact your administrator." — seconds after opening the in-app sandboxed Browser pane, when a prior auto-update has left the packaged service CoworkVMService half-registered. The pane triggers a non-elevated re-registration of the packaged service, which fails with 0x80073D28 and invalidates the package activation state.
Related (all closed, same error family, none document this runtime trigger): #51132, #47877, #35366, #48437, #25162, #55465.
Environment
- Windows 10 Pro 19045
- Claude Desktop MSIX
Claude_1.34493.0.0→1.34493.1.0(x64__pzs8sxrjxfjjc), SignatureKind: Developer - Machine previously ran the Squirrel build (migration context of #25162)
Timeline (reconstructed from Event Viewer)
- 02:33–02:38 — overnight auto-update to
1.34493.0.0. SCM log (Id 7045/7040) showsCoworkVMServiceinstalled 4 times in 5 minutes, StartType flipping auto→disabled→auto. The update leaves the service half-registered. - App then runs normally for hours — plain chat works fine (no VM needed).
- User opens the sandboxed Browser pane → app attempts to (re)register the packaged service without elevation →
AppXDeploymentServerlogs Id 404/401/9621:
> error 0x80073D28: Cannot register the Claude_..._pzs8sxrjxfjjc package. Administrator privileges required to install packaged service
- Package activation state is now invalid → blue "There's a problem with Claude" dialog on every launch. Restarting Windows does not help.
- Reproduced twice in one day: reinstalled, opened the Browser pane again → bricked again within seconds.
- Recovery reinstall also fights the stale state before eventually succeeding:
> 0x80073D05: An error occurred while deleting the package's previously existing state / 0x800703FA: Illegal operation attempted on a registry key that has been marked for deletion (windows.stateExtension), plus 0x80073CFA (PreserveApplicationData) and 0x80073D02 (apps need to be closed) along the way.
No WER crash dumps at any point — this is a registration/elevation failure, not a process crash.
Expected
Opening the Browser pane should either (a) trigger an elevated repair of the packaged service, (b) fail gracefully with the pane unavailable, or (c) the updater should never leave CoworkVMService half-registered in the first place. A UI feature toggle should never be able to invalidate the whole package.
Workaround (verified)
- Prevention: don't open the Browser pane.
- Recovery with data intact (what Settings→Apps→Claude→Repair does): elevated
Add-AppxPackage -Register -DisableDevelopmentMode "<InstallLocation>\AppxManifest.xml"
Full event-log timeline available on request.
---
Disclosure: this diagnosis (Event Viewer forensics, root-cause analysis) and this report were produced by Claude — model Fable 5 (claude-fable-5), running in Claude Code on the affected machine — at the machine owner's direction, and posted from the owner's account with their approval.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗