[BUG] Orphaned cowork-svc.exe locks the MSIX package → app won't launch until Windows "Repair" (AppX error 0x80073D02)

Adding a data point that extends this issue: in my case cowork-svc.exe was not just an orphaned process — it is registered as an auto-start Windows service (CoworkVMService) whose binary lives inside the MSIX package:

Service:   CoworkVMService (StartMode: Auto, State: Running)
PathName:  C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

Consequence: even after every claude.exe process is terminated (verified 0 processes in the package family via GetPackageFamilyName enumeration), the package stays "in use", so every repair attempt fails with 0x80073D02 (ERROR_PACKAGES_IN_USE). AppXDeploymentServer Event 9641 reports:

Deployment aborted due to active service Claude_pzs8sxrjxfjjc!Claude

Because the service is auto-start, a reboot alone does not help — the service re-locks the package at boot before any repair can run.

Environment:

• Claude Desktop 1.24012.9.0 (MSIX, Claude_1.24012.9.0_x64__pzs8sxrjxfjjc), Windows 10 Pro 19045
• Symptom chain identical to #81745: GPU process crash (exitCode: 101457950) → Crashpad dump → CodeIntegrity Event 3010 (AppxMetadata\CodeIntegrity.cat missing, status 0xC000003A) + Event 3033 (vk_swiftshader.dll) → package status Modified, NeedsRemediation → app can no longer launch ("There's a problem with Claude, reinstall from the original install location" dialog)

What worked / didn't work (all verified via AppXDeploymentServer events):

| Step | Result |
|---|---|
| Kill all claude.exe, retry activation | ❌ 0x80073D02 — blocked by CoworkVMService |
| Stop-Service CoworkVMService, retry activation | ✅ Register (RepairAppRegistrationOption) completes 0x0 — but status stays Modified, NeedsRemediation |
| Settings → Apps → Claude → Advanced options → Repair | ✅ completes (checkmark) — but it only re-runs RegisterByPackageFullName with RepairAppRegistrationOption against the local AppxManifest.xml; missing payload files are NOT restored, so status stays Modified, NeedsRemediation and launch still fails |
| Over-the-top reinstall of official MSIX (Add-AppxPackage -ForceUpdateFromAnyVersion, elevated) | ✅ FIXED — status Ok, app launches normally, app data preserved |

Reinstall details: downloaded the official MSIX (246MB, Authenticode-valid, Anthropic, PBC) from https://api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect and applied it over the top from an elevated PowerShell — no uninstall, no Reset. Sign-in state and app data survived.

Interesting correction: after the fresh official MSIX install, AppxMetadata\CodeIntegrity.cat is still absent — so its absence appears to be normal for this package, and CodeIntegrity Event 3010 referencing it is likely noise rather than evidence of corruption. Whatever made the package Modified was elsewhere in the payload.

Three takeaways for anyone hitting this:

1. If repair keeps failing with 0x80073D02 even with zero Claude processes, check Get-Service CoworkVMService and stop it first (Stop-Service CoworkVMService -Force).
2. Neither activation-triggered auto-repair nor the Settings "Repair" button re-stages payload files — both only re-run registration. If the package stays Modified, NeedsRemediation after they "succeed", go straight to an over-the-top Add-AppxPackage of the official MSIX (elevated, -ForceUpdateFromAnyVersion). This preserves app data.
3. Don't treat Event 3033 (vk_swiftshader.dll) as the root cause — Chromium-based apps intentionally enable a Microsoft-signed-only DLL mitigation on GPU processes, and the same event fires routinely for Chrome itself on the same machine.

Follow-up: the same brick recurred twice more (29h later, and then ~15 min after recovery — the second one was a deliberate reproduction). Trigger identified via main.log: opening the in-app browser pane kills the GPU process within 6–12 seconds (controlled repro details posted in #81840). The recovery procedure from my previous comment reproduced cleanly both times (~15 min each).

One note: after the over-the-top reinstall, CoworkVMService came back as StartType: Automatic the first time but DISABLED the second time — if Cowork stops working after a reinstall, check that service's start type.

Still present on 1.26832.0.0, ARM64 — plus the manifest-level root cause and a reboot-free recovery.

Hit this today (2026-08-09) on Windows 11 ARM64 (Snapdragon X Plus), package Claude_1.26832.0.0_arm64__pzs8sxrjxfjjc. Same signature as @labolabo's comment, so it is neither architecture- nor version-specific — this is ~6 weeks and many releases later, on a different arch.

The manifest is the root cause

AppxManifest.xml declares the service nested inside <Application>, with StartupType="auto":

<Application Id="Claude" ...>
  <Extensions>
    ...
    <desktop6:Extension Category="windows.service"
                        Executable="app\resources\cowork-svc.exe"
                        EntryPoint="Windows.FullTrustApplication">
      <desktop6:Service Name="CoworkVMService" StartupType="auto" StartAccount="localSystem">
        <desktop6:TriggerEvents>
          <desktop6:TriggerCustom Action="ActionStart" Subtype="1f81d131-3e60-4c76-9860-37334e4ffce3">
            <desktop6:StringData>
              <desktop6:DataItem Value="\pipe\cowork-vm-service" />
            </desktop6:StringData>
          </desktop6:TriggerCustom>
        </desktop6:TriggerEvents>
      </desktop6:Service>
    </desktop6:Extension>
  </Extensions>
</Application>

Two consequences follow directly from those two attributes:

1. Nested under <Application>, the service inherits the app's AUMID. That is why deployment reports the app as running when only the service is alive: Running apps: {Claude_pzs8sxrjxfjjc!Claude}. The user is instructed to close an app that is already closed, and no amount of closing windows or killing claude.exe helps.
2. StartupType="auto" pins the package "in use" from boot onward — but the manifest already declares a named-pipe start trigger (\pipe\cowork-vm-service). Trigger-start is precisely what StartupType="demand" is for. The auto looks gratuitous: with demand plus the trigger that is already there, the service would start on first Cowork use and idle-stop afterwards, instead of holding the package hostage 24/7.

Settings → Repair can never succeed, while a plain Register can

This asymmetry is what turns an annoyance into a hard brick, and I have both paths in one log minutes apart (Microsoft-Windows-AppXDeploymentServer/Operational).

Plain Register — succeeds, because it force-terminates the service:

15:33:33.805  9648  0x0: TerminateSingleService for update successful for service ... CoworkVMService
15:33:33.805  9650  0x0: Succesfully terminated service ... in package CoworkVMService.
15:33:33.988   400  Deployment Register operation ... finished successfully.

Settings → Repair — aborts, because it refuses to:

15:34:40.270  9645  GetActiveAumidsInPackage successful for package Claude_1.26832.0.0_arm64__pzs8sxrjxfjjc
15:34:40.270  9641  0x80004004: Deployment aborts due to active service Claude_pzs8sxrjxfjjc!Claude.
15:34:40.272   638  Packages were not updated because affected apps are still running.
                    Running apps: {Claude_pzs8sxrjxfjjc!Claude}
15:34:40.278   419  error 0x80073D02: Unable to install because the following apps need to be closed
15:34:40.301   666  For repair ...: Register operation finished with result 0x80073D02 (step 2 of 2)

Worth highlighting: Repair's step 1 succeeded — it re-downloaded the full MSIX from downloads.claude.ai and staged it (44.9 s) — and then step 2 discarded that work. So the dialog steers users into a path that costs a full package download and then structurally cannot complete while an auto-start service from inside the package is running. The accompanying Windows text ("We couldn't repair this app because it's currently running. Close the app and try again.") is unactionable: the thing that is running is an invisible LocalSystem service, not the app.

Recovery needs neither elevation nor a reboot

Contrary to what the thread suggests, no reboot or reinstall is required. Stop-Service on CoworkVMService works unelevated, and re-registering is exactly what Repair's failing step 2 attempts:

Stop-Service -Name CoworkVMService -Force
Add-AppxPackage -DisableDevelopmentMode -Register `
  "C:\Program Files\WindowsApps\Claude_<version>_arm64__pzs8sxrjxfjjc\AppxManifest.xml"
Start-Process "shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude"

Verified end to end on my machine: register succeeded at 15:39:35 (event 400), app launched at 15:39:59, main.log resumed writing normally. About 30 seconds, versus the reboot and reinstall cycles reported upthread. The service comes back on its own afterwards, so nothing is left disabled.

Ask

Please consider (a) StartupType="demand", since the start trigger is already declared and appears sufficient, and/or (b) moving the windows.service extension out of <Application> so a background service stops presenting itself to the deployment stack as a running app.

As shipped, an app with auto-update enabled can put itself into a state where the only remediation Windows offers is the one remediation that is guaranteed to fail. This is my second occurrence.