DEV Community

MilkyWay008
MilkyWay008

Posted on Originally published at github.com

Claude Desktop bricked after an update on Windows? The MSIX process-kill fix

#ai #windows #devops

Claude Desktop bricked after an update on Windows? The MSIX process-kill fix

I keep seeing the same Windows failure across AI desktop apps lately, and Claude Desktop is the worst offender. The app updates itself silently, and the next time you click the icon...... nothing. Or a blue dialog: "There's a problem with Claude. Reinstall." Try the reinstall and it dies with codes like 0x80073D02, 0x80073CF6, or 0x80070020. Plain chat was working an hour ago. What broke?

If this sounds familiar, don't do what I did the first time: uninstall, reinstall, reboot, and repeat for an entire afternoon. The problem usually isn't the download. It's that something from the old install is still running, and Windows refuses to touch the package while it is.

The short version

Open an elevated PowerShell and run this:

# kill everything from the app, hidden children included
Get-Process claude, "cowork-svc", "chrome-native-host" -ErrorAction SilentlyContinue |
  Stop-Process -Force

# find stragglers still executing out of the packaged install
Get-CimInstance Win32_Process |
  Where-Object { $_.ExecutablePath -like "*WindowsApps\Claude_*" } |
  ForEach-Object { Stop-Process -Id $_.ProcessId -Force }

# stop and remove the packaged service
Stop-Service CoworkVMService -Force -ErrorAction SilentlyContinue
sc.exe delete CoworkVMService

# remove the stale package
Get-AppxPackage -AllUsers *Claude* | Remove-AppxPackage

# wipe leftover package data
Remove-Item "$env:LOCALAPPDATA\Packages\Claude_*" -Recurse -Force -ErrorAction SilentlyContinue
Enter fullscreen mode Exit fullscreen mode

Then grab a fresh installer from claude.ai/download, install it, and launch it once as Administrator. That gets most people back in business.

Why this happens

Claude Desktop ships as an MSIX package, and MSIX comes with two rules that bite here.

First rule: you can't update, repair, or remove a package while any process from it is alive. The updater quits the main window, but it doesn't always kill everything. An elevated Claude Code child from a terminal session, a native messaging host, a background helper...... any survivor keeps the old version's container alive. Servicing then fails with 0x80070020, which Windows cheerfully reports as "Another program is currently using this file." It was never about a file. It's a zombie process holding the container hostage.

Second rule: packaged services pin the package too. Claude ships one called CoworkVMService, set to AUTO_START. An update or repair has two steps: stop the package's bits, then register the new version. Between those steps the service sees AUTO_START and starts itself again. Package still in use. Registration aborts with 0x80073D02, which is Microsoft for "close the apps, all of them." Related stops on the way down: 0x80073D28 (a packaged service needs elevation to register) and 0x80073CF6/CF9 (deployment failed).

These threads are all over the tracker: #73107, #88500, #88962, #89108, #89599. Different builds, different entry points, identical story. A service that can't stay stopped plus child processes that won't die.

If the quick fix doesn't stick

  1. Reboot before anything else. A reboot clears most orphaned container state, and sometimes the app just works afterward. Skip the surgery if it does.
  2. sc delete says Access denied even elevated? The service DACL only grants change rights to AppXSvc. Reboot into Safe Mode with Networking and delete it there, or reset the DACL with sc sdset CoworkVMService and retry.
  3. Read the AppModel-Runtime event log. Events 208/215 naming a stale Container_Claude_ job tell you exactly which PID is pinning the package. Kill those PIDs alone and you can often skip the reinstall entirely.
  4. On the fresh install, run the installer elevated and launch once elevated. First-run service registration needs it.

The part that applies to everything

This isn't Claude-specific. Any MSIX app with a packaged service can wedge this way, and I've seen the same 0x80070020 silo pattern reported for other AI desktops. The general lesson: when a Windows app dies after an auto-update, assume the old version is still half-alive before you blame the new one. Check for surviving processes, check the packaged service state, then reinstall.

And if the app in question has an auto-update toggle, consider flipping it off and updating on your own schedule. A silent update that can't finish cleanly is worse than no update at all.

Top comments (0)