Claude Cowork won't start on Win11 25H2 — Deep dive into WSL2/Hyper-V failure: everything tried, everything found [Ryzen 5 5600X / Gigabyte B450M DS3H V2]

[vitorsalamoni-cmyk]

I've spent weeks trying to get Claude Cowork (Anthropic's desktop AI tool)
working on Windows 11 25H2. It requires WSL2 to run its workspace container.
This post documents everything I found — maybe it helps someone or someone
here has the final piece.

---

HARDWARE & OS

• CPU: AMD Ryzen 5 5600X (Zen 3)
• Motherboard: Gigabyte B450M DS3H V2
• RAM: 32GB
• GPU: NVIDIA RTX 3060
• OS: Windows 11 Pro 25H2 — Build 26200.9278 (fully updated as of Sep 2026)

---

THE SYMPTOM
Claude Cowork fails to start its workspace with:
HRESULT 0x80370102 (hypervisor not running)

Running wsl --install -d Ubuntu manually reproduces it:
Wsl/InstallDistro/Service/RegisterDistro/CreateVm/HCS/HCS_E_HYPERV_NOT_INSTALLED

---

WHAT IS CONFIRMED CORRECT

• SVM Mode: Enabled in BIOS (verified visually)
• IOMMU: Enabled in BIOS (changed from Auto to Enabled — no effect)
• VirtualizationFirmwareEnabled: True (WMI)
• HypervisorPresent: True (WMI) — meaning VBS is running
• bcdedit hypervisorlaunchtype: Auto
• vmcompute: Running (Manual)
• WslService: Running (Automatic)
• Windows features all enabled:
  VirtualMachinePlatform ✅
  HypervisorPlatform ✅
  Microsoft-Hyper-V-All ✅
  Microsoft-Windows-Subsystem-Linux ✅
• Memory Integrity (HVCI): Disabled
• SecurityServicesRunning: {0} — VBS active but no security services inside it
• SFC /scannow and DISM /RestoreHealth: no violations

---

EVERYTHING TRIED (all failed)

1. Enabled all Hyper-V features via Windows Settings and DISM
2. Multiple full shutdowns (shutdown /s /t 0)
3. Disabled Fast Startup (powercfg /h off)
4. netsh winsock reset + reboot
5. Enabled IOMMU in BIOS (was on Auto)
6. DISM disable all Hyper-V features → full shutdown → re-enable
7. wsl --install --no-distribution
8. Checked and confirmed SVM Mode enabled visually in BIOS
9. Tested across Windows Updates: KB5094126, KB5095093, KB5121003, 26200.9278
10. Full Windows clean reinstall (didn't help — 25H2 ISO was the only
    one available from Microsoft at the time)

---

KEY FINDINGS

1. hvsocket provider is missing from Winsock catalog:
   netsh winsock show catalog | findstr -i "hv"
   → Returns nothing
   This was likely caused by running netsh winsock reset as a
   troubleshooting step. Re-enabling Hyper-V features via DISM did
   not restore it.

2. HCS log channel does not exist:
   wevtutil sl "Microsoft-Windows-Hyper-V-Compute/Operational" /e:true
   → "channel not found"
   The HCS operational log was never created — meaning HCS never
   fully initialized.

3. hcsdiag list returns nothing — no output, no error.

4. Get-WinEvent on System log returns zero Hyper-V/HCS entries.

This points to HCS never completing its initialization, likely because
the hvsocket Winsock provider is missing. The chicken-and-egg problem:
HCS needs hvsocket to initialize, but hvsocket is only re-registered
by HCS during initialization.

---

OPEN QUESTIONS

• Is there a way to manually re-register the hvsocket Winsock provider
  without a full OS reinstall?
• Is there a specific DLL or component registration that targets only
  the HCS/Hyper-V Winsock providers?
• Has anyone seen this specific combination of symptoms (missing hvsocket
  • no HCS log channel) and found a fix that isn't a clean reinstall?

Related GitHub issue: #14384

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[vitorsalamoni-cmyk]

WslLogs-2026-09-05_13-06-02.tar.gz

Logs attached as requested.

Key findings before collecting logs:

• netsh winsock show catalog | findstr -i "hv" returns nothing (hvsocket provider missing)
• Microsoft-Windows-Hyper-V-Compute/Operational log channel does not exist
• hcsdiag list returns no output

[github-actions]

Diagnostic information

Detected appx version: 2.7.8.0
Detected user visible error: Wsl/InstallDistro/Service/RegisterDistro/CreateVm/HCS/HCS_E_HYPERV_NOT_INSTALLED

[vitorsalamoni-cmyk]

New finding after log analysis:

HvSocket.dll EXISTS on the system:
C:\Windows\System32\HvSocket.dll (75248 bytes, 06/06/2026)
C:\Windows\System32\4545ffe2-0dc4-4df4-9d02-299ef204635e_hvsocket.dll (26064 bytes)

The Winsock catalog HAS a "Hyper-V RAW" entry (entry #8 in Protocol_Catalog9),
but its PackedCatalogItem points to mswsock.dll instead of HvSocket.dll.

Attempting regsvr32 on HvSocket.dll fails:
"DllRegisterServer entry point not found"
(expected — it's a Winsock transport provider, not a COM DLL)

So the root cause appears to be: HvSocket.dll is present but incorrectly
registered in the Winsock catalog (pointing to mswsock.dll instead).

Question: Is there a supported way to re-register HvSocket.dll as a Winsock
transport provider without a full OS reinstall?
Possibly via WSCInstallProvider or a specific DISM component repair?

The GUID in the companion filename suggests the provider GUID may be:
{4545ffe2-0dc4-4df4-9d02-299ef204635e}

[vitorsalamoni-cmyk]

Update after deeper investigation — isolated the bug to WSL2 Utility VM path

CRITICAL FINDING: Standard Hyper-V VM creation works perfectly.

Test performed:
New-VM -Name "TestHyperV" -Generation 2 -NoVHD -MemoryStartupBytes 512MB
Result: SUCCESS — Status "Operating normally", Version 12.0

This proves:

• HCS is functional ✅
• Hypervisor is running ✅
• Standard Hyper-V VM creation works ✅
• The bug is ISOLATED to the WSL2 Utility VM (UVM) creation path ❌

WSL VERSIONS TESTED — all fail identically:

• 2.7.8.0 (stable)
• 2.7.13.0 (stable, wsl --update)
• 2.9.10.0 (pre-release, kernel 6.18.40.1-1)

The pre-release 2.9.10.0 error now explicitly says:
"If this error was unexpected, consider searching existing issues
or filing a new one at github.com/microsoft/WSL/issues"

ADDITIONAL DIAGNOSTICS:

• vmbusr.sys: RUNNING ✅
• vmbus Parameters\Winsock\HelperDllName: wshhyperv.dll ✅
• HvSocket.dll present in System32 ✅
• IOMMU: Enabled in BIOS (AMD CBS > NBIO Common Options) ✅
• SVM Mode: Enabled ✅
• New-VM (standard Hyper-V): SUCCESS ✅
• wsl --install -d Ubuntu: FAILS with HCS_E_HYPERV_NOT_INSTALLED ❌

CONCLUSION:
The failure is in HcsCreateComputeSystem when WSL2 attempts to create
its Utility VM (UVM). Standard Hyper-V VMs use a different HCS code
path and succeed. This confirms the bug is in Windows 25H2's handling
of the WSL2-specific UVM creation path, not in WSL version, BIOS
configuration, or Hyper-V feature installation.

Hardware: AMD Ryzen 5 5600X / Gigabyte B450M DS3H V2 / 32GB / RTX 3060
OS: Windows 11 Pro 25H2 Build 26200.9278

[vitorsalamoni-cmyk]

RESOLVED — Root cause found and fixed

After extensive investigation, the issue was caused by a combination of
three factors, all related to gaming optimizations:

ROOT CAUSE 1 — disabledynamictick (PRIMARY FIX):
bcdedit showed the following non-default values in a secondary boot entry:
disabledynamictick Yes
useplatformclock No
useplatformtick No

This is a common CS2/gaming optimization that disables the dynamic tick
scheduler. It breaks WSL2 UVM creation specifically — standard Hyper-V
VMs still work because they use a different timer path. Removing this
entry fixed the core issue:

bcdedit /deletevalue "{your-entry-guid}" disabledynamictick
bcdedit /deletevalue "{your-entry-guid}" useplatformclock
bcdedit /deletevalue "{your-entry-guid}" useplatformtick

ROOT CAUSE 2 — Secure Boot in Setup Mode (no Platform Key):
Secure Boot was enabled but "Not Active" — System Mode was "Setup"
with no keys enrolled. Fixed by:

• Setting Secure Boot Mode to Custom in BIOS
• Running Restore Factory Keys to install Microsoft keys
• This changed System Mode from "Setup" to "User" and activated Secure Boot

ROOT CAUSE 3 — Hyper-V devices disabled (Error 22):
Three devices were disabled in Device Manager:

• Microsoft Hyper-V Virtualization Infrastructure Driver
• Microsoft Composite Bus Enumerator
• NDIS Virtual Network Adapter Enumerator

Fixed with:
Get-PnpDevice | Where-Object {$_.FriendlyName -match "Hyper-V|Composição|NDIS Virtual"} | Enable-PnpDevice -Confirm:$false

VERIFICATION:
wsl -d Ubuntu -e uname -r
→ 6.18.40.1-microsoft-standard-WSL2 ✅

Hardware: AMD Ryzen 5 5600X / Gigabyte B450M DS3H V2 / RTX 3060
OS: Windows 11 Pro 25H2 Build 26200.9278

Note: The disabledynamictick setting is the primary fix.
If you play CS2 or other competitive games and followed timer optimization
guides, check your bcdedit for this value first.

[chemwolf6922]

Hi vitorsalamoni-cmyk.
The effective root cause is 3. Glad to hear it's resolved.
Have you run any third party "performance optimization" software after the windows installation?