Cowork ARM64: stale VM instance holds smol-bin.vhdx (EBUSY) + zero HNS networks — recurring host BSODs (Samsung Galaxy Book4 Edge, Snapdragon X)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

Cowork fails with "VM connection timeout after 60 seconds" on every attempt.
Two distinct failure modes are present simultaneously on this machine:

1. The VM instance ID is identical across all restart cycles, and

smol-bin.vhdx stays locked (EBUSY) by a VM that is no longer reachable.
The failing step is load_swift_api — earlier than the
add_plan9_shares failures reported in #67901 / #66535 / #39636.

1. Get-HnsNetwork returns zero networks from an elevated session,

reproducing the silent HNS failure of #67901 on a different device model.

Additionally, [KernelBugMonitor] State reset fires exactly 4 minutes after
every failure, and the host has produced 5 bugchecks in 14 days.

Environment

• Device: Samsung Galaxy Book4 Edge, model code NP750XQB-KA2DE
• CPU: Snapdragon(R) X - X126100 - Qualcomm(R) Oryon(TM) (2.96 GHz)
• GPU: Qualcomm(R) Adreno(TM) X1-45
• RAM: 16 GB (15.6 GB usable)
• Disk: 280 GB of 477 GB used
• OS: Windows 11 Home 25H2, build 26200.8875 (ARM64), installed 2026-05-19
• Feature Experience Pack: 1000.26100.334.0
• Claude Desktop: 1.22209.3.0 (MSIX, Claude_1.22209.3.0_arm64__pzs8sxrjxfjjc)
• Bundle version: 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a
• HypervisorPresent: True
• Services: CoworkVMService Running (Automatic), hns Running (Manual), vmcompute Running (Manual)
• AV: Windows Defender only

Key finding 1 — stale VM instance never released

Across three consecutive startup cycles (02:02, 02:06, 02:11), the VM instance
ID does not change:

[VM:start] VM instance ID: b493c72d-ba05-436f-a03f-a034bdb1af60

Every cycle then hits:

[VM:start] Copying smol-bin.arm64.vhdx to bundle: ... -> ...\claudevm.bundle\smol-bin.vhdx
[warn] [VM:start] smol-bin.vhdx locked by running VM (EBUSY), skipping copy
[info] [VM:start] Configuring Windows VM service...
[info] [VM:start] Windows VM service configured
[info] [VM:start] Still waiting for guest connection... 10107ms elapsed, 21 polls
[info] [VM:start] Still waiting for guest connection... 20311ms elapsed, 41 polls
[info] [VM:start] Still waiting for guest connection... 30528ms elapsed, 61 polls
[info] [VM:start] Still waiting for guest connection... 40702ms elapsed, 81 polls
[info] [VM:start] Still waiting for guest connection... 50869ms elapsed, 101 polls
[error] [VM:start] Connection timeout, last completed step: load_swift_api

The orphaned VM holds the VHDX, so the fresh image is never copied and each
retry re-attaches to a dead instance. Skipping auto-reinstall (already
attempted once) means the app's own recovery path is disabled after the
first try, so the state never clears on its own.

Key finding 2 — KernelBugMonitor fires every cycle

02:06:51 [info] [KernelBugMonitor] State reset
02:11:51 [info] [KernelBugMonitor] State reset

Exactly 4 minutes after each failure, in every cycle.

Key finding 3 — recurring host bugchecks

C:\Windows\Minidump over 14 days:

070326-10265-01.dmp 2026-07-03 10:44 1,835,116 bytes
070726-10031-01.dmp 2026-07-07 13:29 2,988,578 bytes
071526-10984-01.dmp 2026-07-15 07:32 1,722,161 bytes
071526-10625-01.dmp 2026-07-15 23:09 2,558,793 bytes
071526-10203-01.dmp 2026-07-15 23:16 1,442,859 bytes

Three within 16 hours on 2026-07-15. Earlier analysis on this machine pointed
to HYPERVISOR_ERROR and GPU TDR (qcdxkm8380.sys). Cowork is the only
hypervisor workload on this system.

Key finding 4 — no HNS networks exist at all

From an elevated PowerShell:

PS C:\windows\system32> Get-HnsNetwork
PS C:\windows\system32>

Zero networks returned, no error. Get-NetNat returns "Invalid class" — the
NAT provider is not present on this ARM64 image at all, so the manual
cowork-vm-nat workaround from #67901 cannot be applied here.

This reproduces the silent HNS failure of #67901 on a second device and model,
and shows it co-occurring with the stale-VHDX lock described above. The two
previously separate ARM64 failure clusters are present simultaneously on this
machine.

Difference from existing issues

• #67901 — silent HNS failure, fails at add_plan9_shares. Here the same

empty-Get-HnsNetwork state occurs, but the start aborts earlier, at
load_swift_api, because a stale VM instance holds the VHDX. Suggests the
HNS failure is independent of the failing step.

• #66535 / #39636 — guest kernel never reaches init. Here the guest is never

given a fresh disk in the first place.

• #40198 — same device family (Galaxy Book4 Edge), but no EBUSY/stale-instance

evidence, no empty-HNS finding, and no bugcheck correlation. Also a
different RAM tier (16 GB here), ruling out the ≥32 GB configurations as a
precondition.

Expected behaviour

1. A failed VM start should release its handle on smol-bin.vhdx, or the next

start should force-terminate the stale compute system before retrying.

1. Skipping auto-reinstall (already attempted once) should not permanently

disable recovery — the counter should reset once the app restarts.

1. HNS network creation should surface an error instead of logging

create_network completed (0ms) when no network is actually created.

1. A guest that never connects should not be able to take the host down.

Available on request

Full cowork_vm_node.log, cowork-service.log, minidumps, elevated
Get-HnsNetwork / Get-NetNat output.

What Should Happen?

1. A failed VM start should release its handle on smol-bin.vhdx, or the next

start should force-terminate the stale compute system before retrying.
Currently the orphaned instance keeps the disk locked indefinitely.

1. Skipping auto-reinstall (already attempted once) should not permanently

disable recovery — the counter should reset when the app restarts.

1. HNS network creation should surface an error instead of reporting success

when no network is actually created; Get-HnsNetwork returning zero
networks should not be a silent state.

1. A guest VM that never connects should not be able to bring down the host.

Five bugchecks in 14 days on the only hypervisor workload on this machine
is a separate and more serious problem than the startup failure itself.

1. If Snapdragon/ARM64 cannot currently run Cowork reliably, the Cowork

Readiness Check should say so instead of reporting "SUPPORTED" with all
items green.

Error Messages/Logs

=== cowork_vm_node.log — three consecutive startup cycles ===

2026-07-20 02:02:31 [info] [VM:start] Still waiting for guest connection... 40595ms elapsed, 81 polls
2026-07-20 02:02:41 [info] [VM:start] Still waiting for guest connection... 50749ms elapsed, 101 polls
2026-07-20 02:02:51 [error] [VM:start] Connection timeout, last completed step: load_swift_api
2026-07-20 02:02:51 [info] Dispatching startup error: VM connection timeout after 60 seconds
2026-07-20 02:02:51 [error] [VM:start] Startup failed: Error: VM connection timeout after 60 seconds
    at OTn (C:\Program Files\WindowsApps\Claude_1.22209.3.0_arm64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.chunk-BgC35fdt.js:945:5769) {
  [stack]: [Getter/Setter],
  [message]: 'VM connection timeout after 60 seconds'
}
2026-07-20 02:02:51 [info] [VM:start] Skipping auto-reinstall (already attempted once)
2026-07-20 02:06:51 [info] [KernelBugMonitor] State reset
2026-07-20 02:06:51 [info] [VM:start] Beginning startup, bundlePath=C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
2026-07-20 02:06:51 [info] [VM:start] Bundle version: 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a
2026-07-20 02:06:51 [info] [VM:start] VM instance ID: b493c72d-ba05-436f-a03f-a034bdb1af60
2026-07-20 02:06:51 [info] [VM:steps] download_and_sdk_prepare started
2026-07-20 02:06:51 [info] [VM:steps] download_and_sdk_prepare completed (3ms)
2026-07-20 02:06:51 [info] [VM:steps] load_swift_api started
2026-07-20 02:06:51 [info] [VM:steps] load_swift_api completed (0ms)
2026-07-20 02:06:51 [info] [VM:start] Copying smol-bin.arm64.vhdx to bundle: C:\Program Files\WindowsApps\Claude_1.22209.3.0_arm64__pzs8sxrjxfjjc\app\resources\smol-bin.arm64.vhdx -> C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\smol-bin.vhdx
2026-07-20 02:06:51 [warn] [VM:start] smol-bin.vhdx locked by running VM (EBUSY), skipping copy
2026-07-20 02:06:51 [info] [VM:start] Configuring Windows VM service...
2026-07-20 02:06:51 [info] [VM:start] Windows VM service configured
2026-07-20 02:07:01 [info] [VM:start] Still waiting for guest connection... 10107ms elapsed, 21 polls
2026-07-20 02:07:11 [info] [VM:start] Still waiting for guest connection... 20311ms elapsed, 41 polls
2026-07-20 02:07:21 [info] [VM:start] Still waiting for guest connection... 30528ms elapsed, 61 polls
2026-07-20 02:07:31 [info] [VM:start] Still waiting for guest connection... 40702ms elapsed, 81 polls
2026-07-20 02:07:41 [info] [VM:start] Still waiting for guest connection... 50869ms elapsed, 101 polls
2026-07-20 02:07:51 [error] [VM:start] Connection timeout, last completed step: load_swift_api
2026-07-20 02:07:51 [info] [VM:start] Skipping auto-reinstall (already attempted once)
2026-07-20 02:11:51 [info] [KernelBugMonitor] State reset
2026-07-20 02:11:51 [info] [VM:start] Beginning startup, bundlePath=C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
2026-07-20 02:11:51 [info] [VM:start] Bundle version: 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a
2026-07-20 02:11:51 [info] [VM:start] VM instance ID: b493c72d-ba05-436f-a03f-a034bdb1af60
2026-07-20 02:11:51 [info] [VM:steps] download_and_sdk_prepare started
2026-07-20 02:11:51 [info] [VM:steps] download_and_sdk_prepare completed (3ms)
2026-07-20 02:11:51 [info] [VM:steps] load_swift_api started
2026-07-20 02:11:51 [info] [VM:steps] load_swift_api completed (0ms)
2026-07-20 02:11:51 [info] [VM:start] Copying smol-bin.arm64.vhdx to bundle: ... -> C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\smol-bin.vhdx
2026-07-20 02:11:51 [warn] [VM:start] smol-bin.vhdx locked by running VM (EBUSY), skipping copy
2026-07-20 02:11:51 [info] [VM:start] Configuring Windows VM service...
2026-07-20 02:11:51 [info] [VM:start] Windows VM service configured
2026-07-20 02:12:01 [info] [VM:start] Still waiting for guest connection... 10194ms elapsed, 21 polls
2026-07-20 02:12:11 [info] [VM:start] Still waiting for guest connection... 20355ms elapsed, 41 polls
2026-07-20 02:12:21 [info] [VM:start] Still waiting for guest connection... 30467ms elapsed, 61 polls
2026-07-20 02:12:31 [info] [VM:start] Still waiting for guest connection... 40667ms elapsed, 81 polls
2026-07-20 02:12:41 [info] [VM:start] Still waiting for guest connection... 50889ms elapsed, 101 polls
2026-07-20 02:12:51 [error] [VM:start] Connection timeout, last completed step: load_swift_api
2026-07-20 02:12:51 [info] [VM:start] Skipping auto-reinstall (already attempted once)

Note: VM instance ID b493c72d-ba05-436f-a03f-a034bdb1af60 is identical in all
three cycles — the orphaned instance is never released.


=== Elevated PowerShell — host networking ===

PS C:\windows\system32> Get-HnsNetwork
PS C:\windows\system32>
(zero networks returned, no error)

PS C:\> Get-NetNat
Get-NetNat : Invalid class
    + CategoryInfo          : MetadataError: (MSFT_NetNat:root/StandardCimv2/MSFT_NetNat) [Get-NetNat], CimException
    + FullyQualifiedErrorId : HRESULT 0x80041010,Get-NetNat


=== Services ===

Name             Status StartType
----             ------ ---------
CoworkVMService Running Automatic
hns             Running    Manual
vmcompute       Running    Manual

HypervisorPresent: True


=== C:\Windows\Minidump — 5 bugchecks in 14 days ===

070326-10265-01.dmp   2026-07-03 10:44   1,835,116
070726-10031-01.dmp   2026-07-07 13:29   2,988,578
071526-10984-01.dmp   2026-07-15 07:32   1,722,161
071526-10625-01.dmp   2026-07-15 23:09   2,558,793
071526-10203-01.dmp   2026-07-15 23:16   1,442,859

Steps to Reproduce

1. Use a Windows 11 ARM64 device with Snapdragon X (Samsung Galaxy Book4 Edge,

model NP750XQB-KA2DE, build 26200.8875).

1. Install Claude Desktop 1.22209.3.0 (ARM64 MSIX) and sign in to a paid plan.
2. Open Claude Desktop and switch to the Cowork tab.
3. Enter any prompt to trigger workspace startup.
4. Wait 60 seconds — the error appears:

"Failed to start Claude's workspace — VM connection timeout after 60 seconds"

1. Close and reopen Claude Desktop, then repeat step 4 twice more.
2. Open %APPDATA%\Claude\logs\cowork_vm_node.log and compare the three

startup cycles:

• The VM instance ID is identical in all three

(b493c72d-ba05-436f-a03f-a034bdb1af60).

• Each cycle logs

smol-bin.vhdx locked by running VM (EBUSY), skipping copy.

• Each cycle aborts with

Connection timeout, last completed step: load_swift_api.

1. In an elevated PowerShell, run Get-HnsNetwork — it returns zero

networks with no error.

1. Run Get-NetNat — it fails with "Invalid class"; the NAT provider is not

present on this ARM64 image.

1. Check C:\Windows\Minidump — 5 bugchecks over the preceding 14 days,

three of them within 16 hours.

Reproduction rate: 100%. Cowork has never started successfully on this device.
Reinstalling the workspace, restarting the app, and rebooting the machine all
produce the identical result.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

N/A (Claude Desktop 1.22209.3.0 arm64 — not a Claude Code issue)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This is a Claude Desktop / Cowork issue, not Claude Code. The repo's issue
form has no Desktop-specific option, so some fields above are filled with the
closest available match.

Claude Desktop: 1.22209.3.0 (MSIX, Claude_1.22209.3.0_arm64__pzs8sxrjxfjjc)
Device: Samsung Galaxy Book4 Edge NP750XQB-KA2DE, Snapdragon X - X126100
OS: Windows 11 Home 25H2, build 26200.8875 (ARM64)