CoworkVMService fails: signature verification cannot resolve executable path in MSIX packaged process

Environment

• OS: Windows 11 Pro 24H2, Build 26100
• Claude Desktop: v1.1.7714.0 (MSIX, SignatureKind: Developer)
• Package: Claude_1.1.7714.0_x64__pzs8sxrjxfjjc
• Hyper-V: Fully enabled (Microsoft-Hyper-V-All, HypervisorPlatform, VirtualMachinePlatform)
• HCS/HCN: Working (computecore.dll v10.0.26100.7309, vmcompute Running)
• Reproduced on: Two separate machines (one with VMware Workstation 25, one clean)

Problem

CoworkVMService (cowork-svc.exe) crashes immediately on start with:

• WIN32_EXIT_CODE: 1066 (ERROR_SERVICE_SPECIFIC_ERROR)
• SERVICE_EXIT_CODE: 1

The Windows Event Log misleadingly shows "Incorrect function" (event 7024) because CoworkVMService has no registered Event Message DLL. The actual error is visible only in the Application Event Log raw event properties.

Root Cause

The service logs the following sequence (Application Event Log, provider: CoworkVMService):

Starting CoworkVMService as Windows service
Claude VM Service starting...
Waiting for configuration from app via 'configure' method...
[HCS] Initializing HCS DLLs...
Warning: failed to open service for recovery config: Access is denied.
[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: ["790e58b4-...", "c08cb7b8-..."]
Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.

The service successfully initializes HCS and HCN, but then fails during signature verification because it cannot resolve its own executable path from within the WIN32_PACKAGED_PROCESS (type 210) container context.

The Go binary likely calls QueryServiceConfigW() or a similar API to obtain the service ImagePath for signature verification. This call returns ERROR_PATH_NOT_FOUND (3) when running inside the MSIX package container, even though the file physically exists at the registered ImagePath.

Additional Factor: Non-System AppX Volume

The system has two AppX volumes:

• C:\Program Files\WindowsApps — System Volume (IsSystemVolume=True)
• G:\WindowsApps — Non-system volume (was set as default)

The Claude package reports InstallLocation as C:\Program Files\WindowsApps\Claude_1.1.7714.0_x64__pzs8sxrjxfjjc, and the file is accessible from both the user context and SYSTEM context (verified via PsExec -s). The MSIX VFS maps both C: and G: paths. This dual-volume configuration may contribute to the path resolution failure inside the packaged process.

What Was Tried (and didn't help)

1. Stopping all VMware services and processes — no effect
2. Restarting vmcompute (Host Compute Service) — service occasionally starts but crashes within seconds
3. Windows App Reset (Settings → Apps → Claude → Advanced → Reset) — no effect
4. Enabling HypervisorPlatform feature — was already enabled
5. DCOM 10016 fix attempts for {15C20B67-12E7-4BB6-92BB-7AFF07997402} — key is TrustedInstaller-protected beyond even SYSTEM access; also not the root cause
6. Modifying service SCM SDDL via sc sdset (as SYSTEM via PsExec) to grant Claude's AppContainer SID query rights — succeeded but did not fix the path resolution
7. Setting default AppX volume to C: via Set-AppxDefaultVolume — no effect on existing installation
8. Attempting Move-AppxPackage to system volume — failed with 0x800701C5
9. Delete Cowork VM Bundle and Restart — re-downloaded successfully but same error

Additional Context

• yukonSilver feature flag reports status=unsupported via GrowthBook, but the VM bundle downloads and the service attempts to start regardless
• cowork_vm_node.log shows: [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
• On one occasion the service briefly reached Running state and progressed to "Configuring Windows VM service..." before timing out after 30s with Error: Request timed out: configure
• The Event Log provider CoworkVMService has no registered EventMessageFile, causing all service log messages to appear as empty in Event Viewer (only visible via raw Properties[0].Value access)
• Claude Desktop continuously logs: connect ETIMEDOUT \.\pipe\cowork-vm-service

Suggested Fix

The signature verification code in cowork-svc.exe should use GetModuleFileName() (Go: os.Executable()) instead of querying the SCM for the service ImagePath, or it should handle the MSIX virtualized filesystem context where QueryServiceConfig may fail with ERROR_PATH_NOT_FOUND.

Additionally, registering an Event Message DLL for the CoworkVMService provider would make these errors visible in Event Viewer instead of appearing as blank messages.