[BUG] Claude Desktop install fails with 0x80073D28 because DACL-locked CoworkVMService cannot be removed

[OasisSaber]

Summary

Claude Desktop could not be updated or reinstalled on Windows 11 because an orphaned and DACL-locked CoworkVMService remained registered.

The installer was successfully elevated, but it could not open or remove the existing service. It then failed to remove the previous Claude MSIX package with 0x80073CFA, attempted an in-place current-user AddPackage, and finally failed with 0x80073D28.

The installer subsequently displayed a misleading message stating that administrator access was required, even though the elevated installer process was already running with a full administrator token.

Environment

• OS: Windows 11 Professional
• Windows build: 10.0.26200
• Architecture: x64
• Claude package previously installed: Claude_1.22209.0.0_x64__pzs8sxrjxfjjc
• Package family: Claude_pzs8sxrjxfjjc
• Installer: Latest official Claude Desktop Windows installer
• Sideloading enabled: true
• S Mode: false

Relevant installer sequence

The installer log confirms successful elevation:

Elevation type: Full
Is elevated: true
Running in elevated context

It then detects the conflicting service:

WARNING: CoworkVMService already exists (potential conflict)
Removing conflicting CoworkVMService...
WARNING: failed to remove conflicting service:
could not open CoworkVMService: Access is denied.

It attempts to remove the previous package:

Removing: Claude_1.22209.0.0_x64__pzs8sxrjxfjjc
Windows rejected data-preserving removal
(0x80073CFA, requires developer mode);
relying on in-place update

It then uses the current-user AddPackage path:

Standard install (not split-account), using AddPackage
Installing via AddPackage (current-user)...

The final error is:

MSIX installation failed:
AddPackage failed with HRESULT 0x80073D28

The installer then incorrectly reports:

Administrator access is required to install Claude with full features.

Service ACL

sc.exe sdshow CoworkVMService returned:

D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604)
S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

The service could not be deleted or have its DACL changed:

sc.exe delete CoworkVMService
[SC] OpenService FAILED 5:
Access is denied.

sc.exe sdset CoworkVMService ...
[SC] OpenService FAILED 5:
Access is denied.

This remained true even when attempting service operations from a SYSTEM shell.

Troubleshooting attempted

The following did not resolve the issue:

• Running Claude Setup as Administrator
• Stopping CoworkVMService
• sc.exe delete CoworkVMService
• sc.exe sdset CoworkVMService
• Running the same service commands from a PsExec SYSTEM shell
• Remove-AppxPackage
• Add-AppxProvisionedPackage
• Repeated reboots
• Re-downloading the latest signed MSIX installer

Working workaround

The issue was resolved using the workaround documented by GitHub user ByteJuggler in issue #74170.

Instead of using sc.exe, the service registry entry was deleted directly from a PsExec SYSTEM process:

psexec -s reg delete "HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService" /f

After deleting the registry entry, rebooting Windows, and rerunning the official Claude Desktop installer, installation completed successfully.

This worked because it bypassed the locked Service Control Manager object ACL and removed the orphaned service registration directly.

Credit: The successful workaround was based on the recovery procedure documented by ByteJuggler in #74170.

Expected behavior

The Claude Desktop installer should:

1. Detect an existing packaged CoworkVMService.
2. Reliably stop and remove or replace the service during upgrades.
3. Avoid leaving a DACL-locked orphaned service after a failed update.
4. Avoid using a current-user AddPackage path that cannot correctly recover the service-containing MSIX.
5. Avoid using an unsupported data-preserving removal path on a non-development package.
6. Detect and repair the orphaned service registration automatically.
7. Display the real deployment error instead of incorrectly blaming missing administrator privileges.
8. Offer a supported cleanup or recovery tool for affected installations.

Impact

The bug completely blocks installation, update, and reinstallation of Claude Desktop. Standard Administrator and SYSTEM-level service-management commands are insufficient because the service object itself cannot be opened. Users may be forced to perform unsupported registry surgery or reinstall/repair Windows unless they discover the direct SYSTEM registry deletion workaround.

Special thanks to @ByteJuggler for documenting the workaround in #74170. It saved my day.

[figgiee]

Additional Reproduction & Root-Cause Breakdown

We encountered this exact failure (CoworkVMService DACL lock -> installer warning -> 0x80073CF9 sharing violation) on Windows 11 Pro 26200 (x64) with Claude Desktop 1.24012.9.0 (Claude_pzs8sxrjxfjjc).

Here is the exact diagnostic breakdown of why this happens, why elevation fails to remove the service, and a non-destructive workaround that does not require registry editing or psexec.

---

1. Why DeleteService fails even under Administrator elevation

Running sc sdshow CoworkVMService shows the service security descriptor:

D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)
  (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604)

• Authenticated Users (AU) are granted RP/WP (start/stop) but not SD (DELETE) or DC (CHANGE_CONFIG).
• Only the service's own NT Service SID (S-1-5-80-...) has SD.
• There is no ACE for Administrators (BA) or SYSTEM (SY) at all.

Consequently, Claude Setup.exe calling DeleteService CoworkVMService will always fail with Access is Denied (error 5), regardless of elevation:

Removing conflicting CoworkVMService...
WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied.

---

2. Why AddPackage fails with 0x80073CF9 (Sharing Violation)

The installer logs the Access is denied warning as non-fatal and immediately proceeds to AddPackage.

Because CoworkVMService is still running, its process (cowork-svc.exe) holds an exclusive open file handle on:
C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

Microsoft-Windows-AppXDeploymentServer/Operational logs Event ID 404:

AppX Deployment operation failed for package Claude_1.24012.9.0_x64__pzs8sxrjxfjjc
with error 0x80073CF9. The specific error text for this failure is:
error 0x80070020: Creating file \\?\C:\Program Files\WindowsApps\
Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe failed.

0x80070020 is ERROR_SHARING_VIOLATION. This leaves the package state set to Modified, NeedsRemediation in AppX.

---

3. Secondary Installer Bug: Legacy Squirrel Process Check

In ClaudeSetup.log:

Squirrel process prefix: c:\users\<user>\appdata\local\anthropicclaude\
Checking for running Squirrel Claude processes...
No Squirrel Claude processes found

The installer checks the legacy Squirrel directory %LOCALAPPDATA%\AnthropicClaude\ instead of C:\Program Files\WindowsApps\. It reports "No processes found" even when claude.exe and cowork-svc.exe are actively running from the MSIX package directory.

---

4. Verified Workaround (No Registry Deletion Required)

Because Authenticated Users do have SERVICE_STOP (WP) rights, stopping the service (or killing the process) before running setup is sufficient to release the file lock. Bypassing SCM deletion or registry removal is not required:

1. Stop the process / service:

   Stop-Service CoworkVMService -Force
   Get-Process cowork-svc, claude -ErrorAction SilentlyContinue | Stop-Process -Force

2. Re-run Claude Setup.exe.

Test Result: Once cowork-svc.exe is stopped, AddPackage completes in ~30s with Status: Ok and zero 0x80073CF9 errors.

---

5. Suggested Fixes for the Claude Installer

1. Use Stop-Service instead of DeleteService: SERVICE_STOP is granted to Authenticated Users on CoworkVMService.
2. Pass ForceTargetApplicationShutdown to AddPackage: Windows AppX deployment natively terminates packaged services when this flag is present.
3. Fix Process Detection Path: Update installer process detection to check C:\Program Files\WindowsApps\Claude_* rather than %LOCALAPPDATA%\AnthropicClaude\.