[BUG] Claude Desktop (Windows): GPU process crash leaves CoworkVMService running, blocking AppX repair with 0x80073D02

Summary

Claude Desktop's GPU/Chromium process crashes when opening a live browser preview of a media-heavy external site (autoplay hero video). After that crash, CoworkVMService (the Cowork VM sandbox component, runs as LocalSystem) stays running even though every claude.exe process has died. While that service is still alive with zero app processes running, Windows' AppX repair/relaunch path fails with 0x80073D02 ("close the app first") — even though nothing is visibly open — so neither relaunching the app nor Settings → Apps → Claude → Advanced options → Repair can recover it. The only way out we found was to manually stop the service (as Administrator) before repairing.

This looks related to #63397 (closed as off-topic by automation, but the same 0x80073D02 / "app still running" AppX symptom applies here with a different root trigger: a crash, not the updater).

Environment

• Claude Desktop (Windows, MSIX/Store), package Claude_1.26832.0.0_x64__pzs8sxrjxfjjc
• Windows 11 Pro x64
• CoworkVMService present, StartMode: Auto, runs as LocalSystem, binary at ...\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

Steps to reproduce (reproduced twice, same pattern both times)

1. In a chat/Cowork session, ask Claude to reference a media-heavy external website (in our case, a hotel site with an autoplay hero video) for a design task.
2. Claude opens a live browser preview of that site ([Preview] Created browser preview in main.log).
3. ~15-22 seconds later, the GPU process dies:

``
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
``

1. The whole app goes down (all claude.exe processes exit), but CoworkVMService keeps running.
2. Attempting to relaunch Claude Desktop shows: "Не удается открыть это приложение… перейдите в раздел дополнительных параметров Claude и выберите 'Восстановить'" (generic Windows "app can't open, use Repair" dialog).
3. Clicking Repair in Settings → Apps → Claude → Advanced options fails: "Не удалось восстановить это приложение. Повторите попытку немного позже."

Root cause (confirmed via Microsoft-Windows-AppXDeploymentServer/Operational event log)

Event 419/404/401, HRESULT 0x80073D02:
"Unable to install because the following apps need to be closed: Claude_1.26832.0.0_x64__pzs8sxrjxfjjc."

Event 638:
"Packages were not updated because affected apps are still running.
Running apps: {Claude_pzs8sxrjxfjjc!Claude}"

At the time of this failure, Get-Process claude* returns zero results — the only thing still alive is CoworkVMService. Windows' AppX deployment logic apparently still considers the package "running" because of that service, even though no user-facing process exists.

Workaround we confirmed works

# Run as Administrator
Stop-Service -Name CoworkVMService -Force
# Then: Settings → Apps → Claude → Advanced options → Repair — now succeeds cleanly.

Confirmed via the same event log: after stopping the service first, the next repair attempt logs Deployment Register operation ... finished successfully with zero errors.

Impact

Without knowing this workaround, the only apparent recovery path is a full uninstall + fresh download/reinstall — which we did once before realizing the service was the blocker, and it discarded local app state. A user who hits the underlying GPU crash and doesn't know about CoworkVMService has no way to recover other than reinstalling.

Ask

1. Have CoworkVMService shut down cleanly (or be tolerant of being stopped) when the main app crashes, so it doesn't block AppX repair/relaunch.
2. Independently, the GPU-crash trigger itself (autoplay-video-heavy live preview → GPU process crash) seems worth investigating on its own.

Happy to provide the full main.log excerpt and AppX event log export if useful.