Windows Desktop: Cowork VM Service crashes repeatedly (HcsShutdownComputeSystem 0x80070032) and fails to auto-restart

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 30, 2026

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, LinuxKernelDirect boot 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.
  1. Primary failure: HcsShutdownComputeSystem returns 0x80070032 (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.
  2. 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 (kills cowork-svc.exe and 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 HcsShutdownComputeSystem returns ERROR_NOT_SUPPORTED on 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.

View original on GitHub ↗