[BUG] CoworkVMService crashes with ExitCode 1066 "Incorrect function" on Windows 11 Pro 25H2 Build 26200 | service fails during early initialization, all user-side fixes exhausted

This was auto-labeled invalid by the bot, but this is a legitimate, thoroughly documented bug affecting CoworkVMService on Windows 11 Pro 25H2. Please re-triage. See related issues #32481, #29941, and #30179 for the same root cause.

Additional Diagnostic Details

Startup sequence (cowork_vm_node.log)

This shows the exact point of failure. The service gets past callback initialization and smol-bin copy but crashes during "Configuring Windows VM service":

2026-03-24 21:56:18 [info] [VM:steps] download_and_sdk_prepare completed (11ms)
2026-03-24 21:56:18 [info] [VM:steps] load_swift_api started
2026-03-24 21:56:18 [info] [VM:steps] load_swift_api completed (0ms)
2026-03-24 21:56:18 [info] [Callbacks] Initializing VM event callbacks...
2026-03-24 21:56:18 [info] [Callbacks] VM event callbacks initialized
2026-03-24 21:56:18 [info] [VM:start] Copying smol-bin.x64.vhdx to bundle: C:\Program Files\WindowsApps\Claude_1.1.8359.0_x64__pzs8sxrjxfjjc\app\resources\smol-bin.x64.vhdx -> C:\Users\mnr_k\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\smol-bin.vhdx
2026-03-24 21:56:19 [info] [VM:start] smol-bin.x64.vhdx copied successfully
2026-03-24 21:56:19 [info] [VM:start] Configuring Windows VM service...
2026-03-24 21:56:24 [error] [VM:start] Startup failed: Error: VM service not running. The service failed to start.

Service status confirmation

PS> Get-CimInstance Win32_Service -Filter "Name='CoworkVMService'" | Select Name, State, ExitCode, PathName

Name            State   ExitCode PathName
----            -----   -------- --------
CoworkVMService Stopped     1066 "C:\Program Files\WindowsApps\Claude_1.1.8359.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"

VM bundle files (complete and validated)

All checksums passed during download. Bundle is intact:

initrd                     175,549,736
initrd.zst                 171,552,961
rootfs.vhdx             9,252,634,624
rootfs.vhdx.zst         2,326,875,206
smol-bin.vhdx               37,748,736
vmlinuz                     14,965,128
vmlinuz.zst                 14,710,568

Network state (NAT never created because service crashes before reaching this step)

PS> Get-NetNat
# (empty)

PS> Get-HnsNetwork | Select Name, Type, AddressPrefix
Name           Type AddressPrefix
----           ---- -------------
Default Switch ICS

Virtualization services confirmed running

PS> Get-Service vmms, vmcompute | Select Name, Status, StartType
Name       Status  StartType
----       ------  ---------
vmcompute  Running Manual
vmms       Running Automatic

Related issues (same or overlapping root cause)

• #32481 — CoworkVMService crashes with "Incorrect function" on Win 11 Pro 25H2 Build 26200 (v1.1.5749)
• #29941 — Signature verification initialization failure from MSIX container
• #30179 — DCOM 10016 blocks CoworkVMService start from MSIX container (Win11 Home→Pro upgrade)
• #27652 — HcnCreateNetwork ICS regression in v1.1.3963
• #25914 — HCS DLL initialization failure on Build 26200

All of these share the same symptom: CoworkVMService crashes with ExitCode 1066 / "Incorrect function" before any VM boot or network creation attempt. The bug appears to be in cowork-svc.exe's early initialization within the MSIX sandbox on Windows 11 25H2 (Build 26200).

Workaround: Change service type from packaged to regular

I hit the same issue on Windows 10 Pro Build 26100 with Claude Desktop v1.1.9310.0. After exhausting all the usual fixes (enabling Hyper-V, HypervisorPlatform, Containers, Containers-HNS, VM bundle deletion, reinstalls, reboots), the service still wouldn't start.

Root cause: The CoworkVMService is registered as WIN32_PACKAGED_PROCESS (type 210), and the Windows Service Control Manager on 25H2 builds can't properly activate packaged services via the MSIX package activation framework. The service binary (cowork-svc.exe) is a standard Go Windows service that doesn't actually need the MSIX package context to run.

Fix: Change the service type in the registry from 210 (packaged) to 16 (regular WIN32_OWN_PROCESS). Run this in an admin PowerShell:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService' -Name 'Type' -Value 16

Then reboot. After reboot the service starts normally, the VM boots (~12s), and the workspace is fully functional.

To revert (if needed):

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService' -Name 'Type' -Value 210

Note: Claude Desktop updates will likely re-register the service and reset the type back to 210, so you may need to re-apply this after updates.

System info:

• Windows 10 Pro Build 26100 (25H2)
• Claude Desktop v1.1.9310.0 (MSIX from Microsoft Store)
• All virtualization features enabled (Hyper-V, VirtualMachinePlatform, HypervisorPlatform, Containers, Containers-HNS)
• vmms, vmcompute, HvHost all running

Thank you for your comment, however, this did not solve the issue. Please find below the technical details:

Root Cause Confirmed: Signature Verification Path Resolution Failure

The detailed service log at C:\ProgramData\Claude\Logs\cowork-service.log
confirms the exact failure point across 30+ attempts spanning March 19 - April 1:
[HCS] vmcompute.dll loaded successfully
[HCS] computecore.dll loaded successfully
[HCS] Procs initialized, HCS ready
[HCN] Initialized HCN API from computenetwork.dll
[HCN] EnumerateNetworks result: [...]
Service error: signature verification initialization failed:
failed to get service executable path: The system cannot find the path specified.

Key observations:

• HCS and HCN initialization succeed every time
• The crash happens specifically during signature self-verification
• The service executable exists and is accessible (Test-Path confirms)
• Service type was changed to 16 (regular process) per workaround

in this thread — same failure

• The Go binary's internal path resolution fails within the MSIX

package context regardless of service type

• This has been failing identically since March 19 across versions

1.1.7714, 1.1.8359, 1.1.8629, and 1.1.9669

This is definitively a bug in cowork-svc.exe's signature verification
routine, not a system configuration issue. The binary needs to use
an MSIX-aware path resolution method (e.g., Windows.ApplicationModel.Package
API) instead of whatever Go syscall it's currently using.

Related: #29941 documents the identical error.

Same build here — Windows 11 Pro 25H2 Build 26200. I fixed this without modifying the registry or service type.

What worked for the signature verification / ExitCode 1066:

I updated Windows to the latest patch (KB5086672, takes you to build 26200.8117) and activated my Windows license. After both, the service started normally — signature verification passed without any workarounds.

Check your build with winver. If you're not on 26200.8117+, that update might be the fix.

Also watch out for the EXDEV error after fixing this one:

Once the service starts, you might hit a second bug where Cowork fails at ~80% with EXDEV: cross-device link not permitted. This happens if your app storage is set to a drive other than C:\.

Check: Settings > System > Storage > Where new content is saved. If "New apps will save to" is anything other than C:\, change it to C:\, then clean reinstall Claude:

Remove-Item "$env:APPDATA\Claude" -Recurse -Force
Remove-Item "$env:LOCALAPPDATA\Claude" -Recurse -Force
Remove-Item "C:\ProgramData\Claude" -Recurse -Force
Remove-Item "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force

You can verify the problem by checking if the MSIX package has symlinks to another drive:

Get-ChildItem "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" | Format-Table Name, Attributes, Target

If you see symlinks to D:\WpSystem\ → that's the EXDEV cause. After changing storage to C:\ and reinstalling, everything worked for me.
---
📌 Full diagnostic tool and step-by-step guide: https://github.com/LozadAPP/claude-cowork-windows-fix

@LozadAPP Thank you. 👍

[Solved] Confirmed: Windows update KB5086672 (build 26200.8117) fixes the signature verification failure.

CoworkVMService now starts normally. No registry changes, reinstall, or storage location changes were needed.

Just the Windows update and a reboot. The service type registry workaround (changing Type from 210 to 16) was NOT required.

Previously failing on build 26200.8037 across Claude Desktop versions 1.1.7714 through 1.1.9669.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.