[BUG] Windows auto-update deploys into running claude.exe + CoworkVMService (0x80073CF9/0x80073D02), app left unlaunchable (NeedsRemediation); recovery churn incl. dev-only PreserveApplicationData (0x80073CFA) — twice in one day

Status Open

Maintainer reply None cached

Activity 16 comments · opened Aug 4, 2026

Summary

Windows auto-update deployments run while the app (claude.exe) and the packaged service CoworkVMService (cowork-svc.exe) are still running, and fail: 0x80073CF9 with inner 0x80070020 (ERROR_SHARING_VIOLATION) on cowork-svc.exe, or 0x80073D02 ("the following apps must be closed"). To the user this looks like Claude suddenly crashed mid-session, after which the app never launches again (no window, no error). What follows in the log is recovery churn: register attempts that "succeed" at the AppX layer without producing a launchable app, repair attempts that race the very processes they're repairing, and — in both incidents — an identical removal attempt with PreserveApplicationData, which is dev-mode-only and guaranteed to fail with 0x80073CFA on a store-signed package.

This hit the same machine twice within one day (2026-08-04, ~01:14 and ~22:52 local). Both times the app was down for 10+ minutes and needed assisted recovery.

Environment

Windows 10 Pro 10.0.19045 x64, Russian locale (log excerpts translated; codes/paths/options verbatim)
Claude Desktop MSIX, package family Claude_pzs8sxrjxfjjc
Update path: 1.24012.11.0 → 1.25927.0.0, payload https://downloads.claude.ai/releases/win32/x64/1.25927.0/Claude-003700efafbc2ccb4b1177a5e637b14da381799e.msix

All excerpts are from Microsoft-Windows-AppXDeploymentServer/Operational, times local. The log records operations, options and outcomes but not the initiating process, so per-attempt attribution (updater retry logic vs. Windows repair vs. our assisted recovery) is inference; your updater telemetry can correlate.

Incident 1 — 2026-08-04 01:14–01:26: repair/re-add of the running version

01:14:10 #603/#638/#401/#404  RegisterByPackageFullName (RepairAppRegistration) of 1.24012.11.0
                              → 0x80073D02 — blocked by the running app it is repairing
01:15:16 #603/#717/#404 (x2)  Remove 1.24012.11.0, first with PreserveApplicationData,RemoveForAllUsers,
                              then PreserveApplicationData alone → 0x80073CFA both times
                              ("flag allowed only for packages deployed in development mode")
01:15:16 #603  Add of 1.24012.11.0 (Claude-2908984492.msix), options:
               ForceApplicationShutdownOption,ForceUpdateFromAnyVersion
01:15:18 #462  Error 0x80070020: failed to create file
               \\?\C:\Program Files\WindowsApps\Claude_1.24012.11.0_...\app\resources\cowork-svc.exe
01:15:18 #605  Last successful state: PreStagePackagesInUseClosed. Failed before reaching: Staged.
01:15:18 #404  → 0x80073CF9 (inner 0x80070020)
01:19:49       identical Add failure, payload Claude-279551963.msix
01:25:23 #404  Add retry → 0x80070005 (failed to open package location)
01:26:03 #603  Add of 1.24012.11.0 (same Force options) — after lingering processes/service
               were stopped out-of-band
01:26:19 #646/#400  running app terminated for servicing; Add completed successfully (16 s)

Sharp edge here: the failing Adds at 01:15/01:19 did request ForceApplicationShutdownOption, yet still died on a sharing violation — same-version re-staging writes into the live package folder (#605: between PreStagePackagesInUseClosed and Staged) before the shutdown machinery terminates the service that holds cowork-svc.exe.

Incident 2 — 2026-08-04 22:08–23:12: deferred update commits into lingering processes, then churn

22:08:28–42 #603/#638/#400  Add 1.25927.0.0 (DeferRegistrationWhenPackagesAreInUse) → staged OK,
                            registration deferred, app still running   [normal designed flow]
22:18:37–38                 same deferred Add again (cached, 734 ms)
22:52:59 #638/#401/#404     deferred Register fires → 0x80073D02 — blocked by running 1.24012.11.0
22:58:48–59:19 #603/#646/#9648/#400  RegisterByPackageFamilyName (ForceApplicationShutdownOption):
                            app terminated, CoworkVMService terminated → Register SUCCESS (31 s)
                            — but no durably working app followed; churn continues:
23:06:21–22 #603/#638/#404  RegisterByPackageFullName (RepairAppRegistration) → 0x80073D02 —
                            blocked by the now-running 1.25927.0.0 itself
23:08:20 #400               Register SUCCESS (219 ms)
23:09:11 #603/#9648/#400    RepairAppRegistration + TerminateSingleService(CoworkVMService) →
                            Register SUCCESS (203 ms) — still no working app
23:10:44 #603/#717/#404(x2) Remove 1.25927.0.0 with PreserveApplicationData(,RemoveForAllUsers) →
                            0x80073CFA — same dev-mode-only dead end as incident 1
23:10:44–51 #603/#9648/#400 Add of OLD 1.24012.11.0 (Claude-817307799.msix, Force options) →
                            SUCCESS — temporary downgrade to the previous version
23:11:30–39 #603/#638/#400  Add 1.25927.0.0 fetched fresh from downloads.claude.ai (Defer...InUse)
                            → staged OK, deferred (blocker: 1.24012.11.0 now running again)
23:12:13–44 #603/#646/#9648/#400  RegisterByPackageFamilyName (ForceApplicationShutdownOption):
                            app + CoworkVMService terminated → Register 1.25927.0.0 SUCCESS (31 s),
                            1.24012.11.0 moved to \WindowsApps\Deleted

The 23:12:44 result held: Get-AppxPackage now reports 1.25927.0.0, Status: Ok, CoworkVMService runs from the new package folder, app healthy. During the broken window Get-AppxPackage showed the package as Modified, NeedsRemediation (observed live during recovery, not preserved in a transcript; identical signature to #83893).

Observations

The deferred-registration flow commits into lingering processes. The designed path (Add + DeferRegistrationWhenPackagesAreInUse) staged fine at 22:08, but the deferred Register at 22:52:59 ran while claude.exe/cowork-svc.exe still lived → 0x80073D02. Window closed ≠ processes exited.
Same-version repair Add races its own service at staging time, before force-shutdown applies → 0x80073CF9/0x80070020 on cowork-svc.exe (incident 1). Force flags don't help there.
RepairAppRegistration is blocked by the app it repairs (01:14:10, 23:06:21) → 0x80073D02.
AppX-layer "success" ≠ working app. Three registrations reported #400 completed successfully (22:59:19, 23:08:20, 23:09:11) with no launchable app afterwards — churn continued for another ~13 minutes. Nothing verifies end-to-end health before declaring the update done.
PreserveApplicationData removal is a scripted-looking dead end that fired in both incidents (01:15:16 and 23:10:44, both times as a pair: with RemoveForAllUsers, then without). The flag is dev-mode-only, so it fails with 0x80073CFA on the store-signed package every time. Whatever issues it (updater rollback logic or recovery tooling — the log doesn't name the caller), "remove but keep user data" is not available as a rollback path for this package.
No automatic recovery to a working state. The package sat in Modified, NeedsRemediation until an out-of-band sequence (temporary downgrade to 1.24012.11.0, fresh payload re-download, defer-Add + force-shutdown Register) landed the update. Why the 23:12:44 attempt held while the 22:59:19 one (same options, same duration) did not is not decidable from this log — flagging for whoever owns the updater's state machine.

Suggested fix

Before the deferred Register commits: enumerate active AUMIDs, gracefully close the GUI, stop CoworkVMService, and wait for cowork-svc.exe/claude.exe to actually exit (no open handles into the package folder) — don't rely on window-close as a proxy.
Treat 0x80070020 / 0x80073D02 as retryable: re-stop processes, retry registration; don't abandon the package in NeedsRemediation.
After Register reports success, verify end-to-end (app activates, service starts from the new folder, package Status == Ok) before considering the update finished — that's the gap behind observation 4.
Drop PreserveApplicationData from any removal path for the store-signed package (0x80073CFA is unconditional there); user data survives normal in-place update anyway.
If the new version can't reach a verified-working state, roll back to the previous version automatically — the 23:10:51 downgrade shows the mechanics work.
Start CoworkVMService / relaunch the app only after the AppX operation has committed.

User impact

The failed update presents as an out-of-the-blue crash; afterwards the app simply never opens — no window, no error, shortcut present. Messages typed into the dead window are lost. User data survives on disk, but recovery requires AppX/service surgery far beyond a typical user. Twice in one day on this machine.

Same lock/race cluster: #73694, #81756, #80502, #82494, #81267, #83893, #78873. This report adds a detailed two-incident same-day timeline from AppXDeploymentServer/Operational, the repeated dev-mode-only PreserveApplicationData rollback dead end (0x80073CFA), and the "AppX success without a working app" churn pattern.

View original on GitHub ↗

6 Comments

DonSmirelo · 26 days ago

Update — root cause on this machine identified: every AppX/update failure above was preceded by the same Electron GPU-process crash. The package corruption is a cascade, not the origin.

main.log (survived the recovery reinstalls) shows the identical GPU crash immediately before all three incidents:

2026-08-04 01:12:35  GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }  → AppX churn from 01:14:10 (incident 1)
2026-08-04 23:06:06  GPU process gone: { …same, exitCode: 101457950 }                           → repair churn from 23:06:21 (incident 2)
2026-08-05 00:06:00  GPU process gone: { …same, exitCode: 101457950 }                           → repair churn from 00:08:50 (incident 3, new)

Same exitCode 101457950 (0x060C201E) every time — deterministic. Crashpad minidump from the 00:06:00 crash (fields extracted before the recovery reinstall cleaned the report): exception 0x80000003 (breakpoint/assertion, not an access violation), crash module claude.exe, module offset 0x6DD36F9, Electron 42.7.0. Not OOM (~12.5 GB system RAM free; GPU process RSS ~142 MB). Dual-GPU machine: NVIDIA RTX 4070 (driver 32.0.16.1047) + Intel UHD 770 (32.0.101.6129).

Trigger: reopening/continuing one specific local session whose agent uses the in-app Browser Preview on nexusmods.com. The session recreates its preview context → GPU process dies ~5 s later (00:05:55 Created browser preview → 00:06:00 GPU process gone). Reproduced twice on different days with that session; other sessions run 30+ min without issues. Per the session transcript, at crash time the preview was sitting on the Cloudflare challenge interstitial in front of nexusmods.com (the agent's last message: waiting for the check to pass), so the challenge page (Turnstile/canvas fingerprinting) — not necessarily Nexus content itself — is the likely crashing content.

Corrected sequence for this machine:

GPU crash takes down the window; background claude.exe utility processes + CoworkVMService survive.
~2–3 min later RegisterByPackageFullName (RepairAppRegistration) fires → 0x80073D02 (blocked by the survivors) → Modified, NeedsRemediation → the churn documented above — including the dev-mode-only PreserveApplicationData removal (0x80073CFA) for the third time at 00:18:29, same double pattern.
The 04.08 evening incident interleaves both bugs: the deferred 1.25927 update force-registered at 22:59:19 (AppX "success"), the app relaunched, restored the poisoned session, GPU-crashed at 23:06:06 → repair churn. That is why AppX-layer register "success" never produced a working app (observation 4 in the original report).

So suggested-fix items 1 and 3–6 stand, and the operative additions are: isolate Browser Preview / GPU-process crashes so they can't take down the main window, and after child-process-gone, don't start AppX repair until every package process (incl. CoworkVMService) has actually exited.

Mitigation applied here: "isHardwareAccelerationDisabled": true (maps to app.disableHardwareAcceleration()). Machine restored to 1.24012.11.0, Status: Ok; 1.25927.0.0 is staged with DeferRegistrationWhenPackagesAreInUse and should complete on a later restart. Will report whether the crash reproduces with HW acceleration off. (The built-in auto-disable after 3 GPU crashes per session presumably never engages because each crash ends the session.)

Likely related: #81123 (browser preview GPU crash → Modified/NeedsRemediation), #83016 (WebFetch content crash corrupting install), #83028 (Intel iGPU browser-pane crash).

yadonpapa · 23 days ago

Another reproduction on Windows 11 Pro (26200) — with a recovery sequence that worked first try

I hit what appears to be the same bug. Adding my timeline and the recovery
sequence that worked, in case it helps.

Environment

Windows 11 Pro 10.0.26200 x64, Japanese locale
Claude Desktop MSIX, package family Claude_pzs8sxrjxfjjc
Versions involved: 1.25927.0.0 (initially broken) → 1.26832.0.0
Windows Defender only (no third-party EDR). Reproduced on two different

networks (corporate guest Wi-Fi and phone tethering), so network
interception is ruled out on my side.

Symptoms

App suddenly stopped launching around Aug 4–5. Windows showed the generic

"repair this app from advanced options" dialog; Settings → Repair failed
("Couldn't repair this app").

Get-AppxPackage showed Status: Modified, NeedsRemediation for

1.25927.0.0.

Clean reinstall attempts: the installer log showed

MSIX package installed successfully / exit code 0, then on first
launch the app window (at the human-verification step) silently
disappeared — no error dialog, no Event ID 1000 crash record — and the
freshly installed 1.26832.0.0 package was immediately back in
Modified, NeedsRemediation. Matches the "AppX success without a working
app" churn pattern in the OP.

Re-running the installer against the broken package then failed with

0x80073CF9. The installer also logged
WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied. (even elevated), and
0x80073CFA (requires developer mode) on the data-preserving removal —
same dev-mode dead end as the OP.

During the broken state, cowork-svc.exe (CoworkVMService) was still

RUNNING from inside the broken package folder, holding files.

What did NOT work

Settings → Repair
Add-AppxPackage -Register <AppxManifest.xml> -DisableDevelopmentMode

(both with the service running and after stopping it) — command succeeds,
Status stays Modified, NeedsRemediation

Recovery sequence that worked (first try), elevated PowerShell

sc.exe stop CoworkVMService and confirm no processes remain under

C:\Program Files\WindowsApps\Claude*

Get-AppxPackage -AllUsers -Name Claude | Remove-AppxPackage -AllUsers
Verify both Get-AppxPackage -AllUsers -Name Claude and the

WindowsApps\Claude* folder are gone

Run the downloaded installer as administrator immediately
Complete the human-verification/login promptly on first launch
Get-AppxPackage -Name Claude → Status: Ok, app healthy since

Happy to provide ClaudeSetup.log excerpts or
AppXDeploymentServer/Operational events if useful.

KieranPhang · 23 days ago

Confirming this on another machine, with two additions: the terminal failure mode was the MSIX activation error ("There's a problem with Claude. Reinstall the application from its original install location or contact your administrator."), and the trigger was the outgoing version hanging on quit (MoAppHang) while the updater retried registration against it.

Environment: Windows 10 Pro 10.0.19045 x64, en-US, Windows Defender only. Package family Claude_pzs8sxrjxfjjc, SignatureKind Developer. Update path 1.25927.0.0 -> 1.26832.0.0.

Timeline, 2026-08-06 (Microsoft-Windows-AppXDeploymentServer/Operational + WER):

21:34:41 - Event 658: 1.26832.0.0 marked for deferred registration because 1.25927.0.0 is running
22:26:46 - Events 404/658: deployment of 1.26832.0.0 fails 0x80073D02 ("apps need to be closed"), deferred again
23:38:48-23:39:37 - Events 401/404 repeating: Register operation for 1.25927.0.0 fails 0x80073D02 multiple times within one minute
23:42:19 - WER MoAppHang: claude.exe 1.25927.0.0, hang type Quiesce (unresponsive during close), hang signature 4185
Next launch: "There's a problem with Claude. Reinstall the application..." Full reinstall required.

Prior incidents, same machine: 2026-07-09 (0x80073D02, 1.20186.0.0 over running 1.19367.0.0), 2026-07-14 (0x8007001F, 1.21459.0.0), 2026-07-30 (0x80070020 creating app\resources\cowork-svc.exe in the 1.24012.9.0 package, plus 0x80073CFA PreserveApplicationData rejected outside dev mode, matching the cowork-svc.exe locking above).

Crashpad/reports was empty after each incident, so no minidumps; the AppX event log is the only surviving evidence. Second unlaunchable-after-update in two weeks on this machine, both resolved only by full reinstall.

yadonpapa · 23 days ago

Follow-up: event log confirms the identical sequence to Incident 1

Following up on my earlier comment — I've since pulled AppXDeploymentServer/Operational from the affected machine. The initial break on my side is 2026-08-05 18:04–18:09 JST, and the event-ID / error-code sequence matches Incident 1 in the OP exactly (log excerpts translated from Japanese; codes/paths/options verbatim):

18:04:03–09  #603 → ... → #400  Add of 1.25927.0.0 completed successfully —
                                but no durably working app followed (same
                                "AppX success without a working app" as
                                observation 4)
18:06:24  #603/#717/#404 (x2)   Remove 1.25927.0.0 with
                                PreserveApplicationData,RemoveForAllUsers then
                                PreserveApplicationData alone → 0x80073CFA
                                both times (dev-mode-only) — same
                                scripted-looking pair as both incidents in
                                the OP
18:06:24  #603  Add of 1.25927.0.0 (Claude-2472190688.msix), options:
                ForceApplicationShutdownOption,ForceUpdateFromAnyVersion
18:06:24  #462  Error 0x80070020: failed to create file
                \\?\C:\Program Files\WindowsApps\Claude_1.25927.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe
18:06:24  #605  0x80070020 in Staged state handler;
          #613  "Failed to reach state Staged"
18:06:24  #404  → 0x80073CF9 (inner 0x80070020)
18:08:48        identical failure sequence repeated (2nd attempt)

Point-by-point match with Incident 1: the dev-mode-only PreserveApplicationData removal pair (0x80073CFA, with RemoveForAllUsers then without), the same-version force Add racing its own service, the sharing violation (0x80070020) on exactly cowork-svc.exe during staging, and the final 0x80073CF9. This is on Windows 11 Pro 10.0.26200, vs. Windows 10 Pro 19045 in the OP, so the race is not specific to a Windows version.

I have the exported .evtx and text extracts saved and can attach them if useful.

FFGCPA · 23 days ago

Same failure mode here, with two things this thread is missing: the 658 deferred-registration event that names the mechanism, and a recovery that actually holds without out-of-band intervention.

Environment: Windows 11 Pro 26200, Claude Desktop MSIX (Claude_..._x64__pzs8sxrjxfjjc), near-daily failures 2026-07-27 through 2026-08-07.

The event that names the mechanism

Microsoft-Windows-AppXDeploymentServer/Operational:

8/7 12:23:52 AM  ID 658   Marking package {Claude_1.26832.0.0_x64__pzs8sxrjxfjjc} for deferred
                          registration because {Claude_1.25927.0.0_x64__pzs8sxrjxfjjc} is still running.
8/6 11:00:01 AM  ID 419   error 0x80073D02: Unable to install because the following apps need
                          to be closed Claude_1.24012.9.0_x64__pzs8sxrjxfjjc.
8/6 11:00:01 AM  ID 666   For repair of package Claude_1.24012.9.0: Register operation finished
                          with result 0x80073D02 (step 2 of 2).
8/6 11:00:01 AM  ID 613   Performance summary ... Failed to reach state ResolvedDeferredRegistrations

Failure counts by day: 8/5 → 16, 8/6 → 8, 8/7 → 2.

`CoworkVMService` is not the blocker

This thread and adjacent ones point at cowork-svc.exe. In my logs the installer terminates it cleanly on every attempt:

ID 9650  0x0: Succesfully terminated service Claude_1.25927.0.0_x64__pzs8sxrjxfjjc in package CoworkVMService.
ID 9648  0x0: TerminateSingleService for update successful ... terminateService: true.

The process named in 419/658 is claude.exe itself. Stopping the service is not the load-bearing step — -ForceApplicationShutdown is. Worth separating, since "stop the service first" advice is circulating and doesn't address the actual lock holder.

User-visible impact is two symptoms, one event

The 12:23 AM timestamp lands mid-run on an unattended overnight job. The update terminated the running app, so the job died silently, and the package was left wedged by morning. These read as two unrelated bugs ("it crashed overnight" and "it won't open") but they are one deployment event. Anyone triaging the overnight-crash reports separately is chasing a ghost.

Recovery that holds (no manual intervention)

Scheduled task, AtLogOn, RunLevel Highest. Detached from the Claude process tree, so it isn't itself killed by the shutdown it triggers. Guarded so it no-ops on healthy days:

$p = (Get-AppxPackage *laude* -AllUsers | Where-Object Status -ne 'Ok').PackageFullName
$busy = Get-Process claude* -ErrorAction SilentlyContinue
if ($p -and -not $busy) {
    Add-AppxPackage -Register "C:\Program Files\WindowsApps\$p\AppxManifest.xml" -DisableDevelopmentMode
}

Pulls the wedged package name dynamically, so it survives whatever version breaks next. ~10 seconds, no reboot, no re-download, no downgrade. Contrast with the recovery in the original report (temp downgrade + fresh re-download + force Register).

Prevention, until this is fixed upstream

Disabling Microsoft Store auto-update removes the ambush window entirely:

New-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\WindowsStore' `
  -Name AutoDownload -Value 2 -PropertyType DWord -Force

Corroborating detail: the same 0x80073D02 hit an unrelated Store package on this machine the same morning (ID 20 Installation Failure ... 0x80073D02: 9WZDNCRD29V9-MICROSOFT.MICROSOFTOFFICEHUB). The collision is Store-auto-update-driven, not unique to Claude — but Claude's release cadence plus a long-running desktop session makes it a near-daily hit rather than an occasional one.

The ask

Reiterating the suggestion already in this thread, with the 658 evidence behind it: wait for actual process exit before committing the deferred registration, and verify Status -eq 'Ok' end-to-end after Register rather than trusting #400 completed successfully — I have three #400 ... finished successfully entries against packages that produced no launchable app.

Related: #63397 documents the identical 658 + 0x80073D02 sequence and was closed as invalid / out-of-scope. If Claude Desktop MSIX deployment isn't tracked in this repo, it would help to say where it is — the reports are going to keep arriving here otherwise.

Toddxiong · 23 days ago

I also encountered the same problem. Now it is completely impossible to start claude code desktop

Showing cached comments. Read the full discussion on GitHub ↗

[BUG] Windows auto-update deploys into running claude.exe + CoworkVMService (0x80073CF9/0x80073D02), app left unlaunchable (NeedsRemediation); recovery churn incl. dev-only PreserveApplicationData (0x80073CFA) — twice in one day

Summary

Environment

Incident 1 — 2026-08-04 01:14–01:26: repair/re-add of the running version

Incident 2 — 2026-08-04 22:08–23:12: deferred update commits into lingering processes, then churn

Observations

Suggested fix

User impact

Related

6 Comments

Another reproduction on Windows 11 Pro (26200) — with a recovery sequence that worked first try

Environment

Symptoms

What did NOT work

Recovery sequence that worked (first try), elevated PowerShell

Follow-up: event log confirms the identical sequence to Incident 1

The event that names the mechanism

CoworkVMService is not the blocker

User-visible impact is two symptoms, one event

Recovery that holds (no manual intervention)

Prevention, until this is fixed upstream

The ask

Related Claude Code issues

Browse by topic

`CoworkVMService` is not the blocker