Fixing 'VM Service Not Running' in Claude Desktop Cowork on Windows

Claude Desktop’s Cowork mode on Windows surfaces a single error for multiple unrelated failures:

Failed to start Claude's workspace
VM service not running. The service failed to start.
Restarting Claude or your computer sometimes resolves this. If it persists,
you can reinstall the workspace or share your debug logs to help us improve.

There are at least six different root causes behind this message. Each requires different diagnostic steps and a different fix. This post is the decision tree I wish existed when I hit it.

Start here: check the two services

From an elevated PowerShell:

Get-Service CoworkVMService | Format-List Name, Status, StartType
Get-Service vmms | Format-List Name, Status, StartType

If vmms (Hyper-V Virtual Machine Management) is not running, the problem is Hyper-V, not Cowork. Enable it in Windows Features and reboot before continuing.

If vmms is running but CoworkVMService is stopped, continue to the diagnostics below.

The diagnostic log

The real information lives in:

%AppData%\Claude\logs\cowork_vm_node.log

Read the last 30 lines:

Get-Content "$env:APPDATA\Claude\logs\cowork_vm_node.log" -Tail 30

What you see in this log determines which failure mode you’re in.

Decision tree

Event Viewer diagnostics

If the cowork log doesn’t explain the failure, check the Windows event logs:

# System log: service crashes
Get-WinEvent -FilterHashtable @{LogName='System'; Level=2; StartTime=(Get-Date).AddHours(-2)} |
  Where-Object {$_.Message -like "*Claude*" -or $_.Message -like "*Cowork*"} |
  Format-List TimeCreated, Message

# DCOM permission errors
Get-WinEvent -FilterHashtable @{LogName='System'; Id=10016; StartTime=(Get-Date).AddHours(-2)} |
  Format-List TimeCreated, Message

Check the network layer

Even when the service starts, the VM may have no internet access:

Get-NetNat

If this returns nothing, the WinNAT rule wasn’t created. Add it manually:

New-NetNat -Name "cowork-vm-nat" -InternalIPInterfaceAddressPrefix "172.16.0.0/24"

This does not persist across reboots. You’ll need to re-run it after every restart, or create a scheduled task (see Workaround for persistent issues below).

For subnet collisions with VPNs or other virtual networks on the 172.16.0.0/24 range, see Elliot Segler’s post on fixing Cowork’s network conflict.

Bundle download

If the log shows rootfs.vhdx missing or the vm_bundles directory doesn’t exist, the bundle hasn’t been downloaded yet. Reopen Claude Desktop and watch the log:

Get-Content "$env:APPDATA\Claude\logs\cowork_vm_node.log" -Tail 15

You should see:

rootfs.vhdx not found, downloading...
rootfs.vhdx.zst checksum validated
vmlinuz not found, downloading...
initrd not found, downloading...
All files ready in C:\Users\...\vm_bundles\claudevm.bundle

If the download completes but the service still shows as Stopped, jump to Race condition fix.

Nuke and redownload

The built-in “reinstall workspace” button in Claude Desktop does not actually reinstall the VM bundle. The cowork log confirms this:

[deleteVMBundle] Reinstall files deleted (sessiondata.img and rootfs.img.zst preserved)

It preserves sessiondata.img and rootfs.img.zst, the two files most likely to be corrupted. This behavior is documented in #24070, where a macOS user discovered the same thing.

To actually start fresh:

# Kill all Claude processes
Get-Process -Name "*claude*" -ErrorAction SilentlyContinue | Stop-Process -Force
Get-Process -Name "*cowork*" -ErrorAction SilentlyContinue | Stop-Process -Force

# Delete the entire vm_bundles directory
Remove-Item -Recurse -Force "$env:APPDATA\Claude\vm_bundles"

Reopen Claude Desktop. It will download a fresh bundle. Monitor with:

Get-Content "$env:APPDATA\Claude\logs\cowork_vm_node.log" -Tail 15

Once you see All files ready, start the service manually:

Start-Service CoworkVMService
Get-Service CoworkVMService | Select-Object Status

Race condition fix

The most common failure mode after a dirty shutdown. Here’s what happens:

1. Claude Desktop launches and immediately tries to start CoworkVMService
2. The VM bundle isn’t fully downloaded or extracted yet
3. The service crashes because it can’t find the required files
4. The service enters a “terminated unexpectedly” state and won’t auto-retry

This is compounded by a shutdown timing issue. Claude Desktop sends a VM stop command with a 30-second timeout. If the VM doesn’t stop in time (Failed: Error: Request timed out: stopVM in the logs), resources aren’t cleanly released. On next launch, the service crashes because Hyper-V resources from the previous session are still held.

The fix is the same as Nuke and redownload: delete vm_bundles, let Claude Desktop redownload, then manually Start-Service CoworkVMService.

Don’t kill Claude processes in Task Manager

This is the single most important thing I learned during this session.

The service crash on restart was reproducible when Claude processes were force-killed via Task Manager after exiting Claude Desktop. The correct shutdown sequence:

1. File > Exit in Claude Desktop
2. Wait at least 60 seconds. The VM shutdown is slow.
3. cowork-svc.exe will remain running in Task Manager. This is normal. It’s the background Windows service, set to AUTO_START.
4. Only then reopen Claude Desktop

If you force-kill cowork-svc.exe or other Claude processes during shutdown, Hyper-V resources (the VM, network adapters, NAT rules) are left in a dirty state, and the service will crash on next start.

Workaround: scheduled task

If the race condition is persistent, create a delayed auto-start:

Set-Content "$env:USERPROFILE\start-cowork.ps1" 'Start-Sleep 30; Start-Service CoworkVMService'

Register-ScheduledTask -TaskName "StartCoworkVM" `
  -Action (New-ScheduledTaskAction -Execute "powershell.exe" `
    -Argument "-WindowStyle Hidden -File $env:USERPROFILE\start-cowork.ps1") `
  -Trigger (New-ScheduledTaskTrigger -AtLogOn -User $env:USERNAME) `
  -Settings (New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries) `
  -RunLevel Highest `
  -Description "Delayed CoworkVMService start after Claude Desktop"

This gives the bundle 30 seconds to finish downloading before the service starts.

Service configuration reference

To verify the service is configured correctly:

sc.exe qc CoworkVMService
sc.exe query CoworkVMService

Expected values:

Related GitHub issues

Environment

• OS: Windows 11 Pro
• Claude Desktop: v1.1.7714.0
• Subscription: Claude Max (individual)
• Hyper-V: Enabled, vmms service running
• CoworkVMService: AUTO_START, LocalSystem