Windows Desktop: Cowork VM Service crashes repeatedly (HcsShutdownComputeSystem 0x80070032) and fails to auto-restart
Description
Claude Code Desktop's backend service ("Cowork VM Service" / cowork-svc.exe) repeatedly crashes on this machine. The Windows service terminates unexpectedly and, because of a secondary permissions issue, does not auto-restart — the app becomes unusable until the backend process is manually killed and restarted.
Environment
- Windows 11 Pro, build 10.0.26200.9278
- Claude Desktop package:
Claude_1.40609.0.0_x64__pzs8sxrjxfjjc - Service runs as
LocalSystem, backed by a Hyper-V Linux VM (HcsCreateComputeSystem,LinuxKernelDirectboot mode) - Docker Desktop (WSL2 backend) is also installed and in active use on this machine, if relevant to Hyper-V/VM resource contention
Root cause (from C:\ProgramData\Claude\Logs\cowork-service.log)
Every crash in the log (recurring across at least 5 separate days, not a one-off) follows the identical sequence:
[VM] Graceful shutdown failed, forcing termination: HcsShutdownComputeSystem failed with HRESULT 0x0/0x80070032: {"Error":-2147024846,"ErrorMessage":""}
[RPC] Read error: failed to read length: An established connection was aborted by the software in your host machine.
[Console] Daemon console read error: No process is on the other end of the pipe.
Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.
- Primary failure:
HcsShutdownComputeSystemreturns0x80070032(ERROR_NOT_SUPPORTED) when the service attempts a graceful shutdown of its Hyper-V VM. This forces a hard kill of the VM instead of a clean shutdown, which cascades into the RPC connection drop and named-pipe read errors that surface as an app crash. - Compounding issue: the service is unable to reconfigure its own Windows Service Control Manager recovery actions (
open service: Access is denied), so once it does crash, Windows does not automatically restart it -- it stays down until the user manually intervenes (killscowork-svc.exeand restarts the app) or reboots the machine.
Corresponding Windows Event Log entries (System log, Service Control Manager):
- Event ID 7034: "The Claude service terminated unexpectedly."
- Event ID 7040: "The start type of the Claude service was changed from auto start to disabled."
- Event ID 7045: "A service was installed in the system." (re-registration on next launch)
Frequency
This exact failure signature recurred on 2026-08-26, 2026-08-28, 2026-08-29 (x2), and 2026-08-30 (x3, most recently while the desktop app itself became unresponsive and had to be recovered by manually terminating the service).
Impact
When this happens, the Claude Code Desktop app becomes unresponsive/unusable, and recovery requires the user to manually locate and terminate the cowork-svc.exe process before the app will come back up -- there's no automatic recovery due to issue #2 above.
Request
- Root-causing why
HcsShutdownComputeSystemreturnsERROR_NOT_SUPPORTEDon this VM configuration would fix the underlying instability. - Independently, the service should be able to configure its own SCM recovery actions (or ship with sane defaults set at install time) so a crash doesn't require manual intervention to recover from.