[BUG] Claude Desktop (Windows/MSIX) causes recurring kernel BSODs - 4-month evidence incl. a 7-week natural experiment - same family as #30137 / #69359 / #80912

Environment

• OS: Windows 11 Home, build 26200.9278 (also occurred on 26100 and 26200.9168)
• CPU: AMD Ryzen 5 3600 · RAM: 32 GB DDR4-3200 · GPU: Radeon RX 5500 XT (Adrenalin 26.6.1)
• Claude Desktop: current MSIX-packaged build (auto-updating); CoworkVMService present (StartType=Automatic), cua-driver-serve logon task present
• Also on machine: WSL2/Ubuntu, Hyper-V/VBS active
• Hardware health: Windows Memory Diagnostic clean; SSD SMART wear 0%, zero WHEA-Logger events across the entire period; sfc/DISM clean at time of crashes

Summary

Recurring full-OS kernel crashes (BSODs) tightly correlated with Claude Desktop being installed/active, spanning May–September 2026, surviving: motherboard BIOS update, three GPU driver versions, two Windows builds, clean system files, and an MSIX Repair. Crash-free only when the app is off/dormant.

The key evidence — a 7-week natural experiment

• Jul 7 → Aug 25, 2026: subscription lapsed; Claude Desktop unused (verified via on-disk session artifacts). Machine ran 24/7 (other background apps active). Zero crashes for ~7 weeks.
• Aug 26: subscription resumed, app active again. First crash within hours (Aug 26 08:35). Escalated to multiple crashes/day.
• Aug 28 controlled test: app + all Claude processes fully killed for ~4 hours → zero crashes. App reloaded at ~19:15 → bugcheck at 19:51 (36 minutes).
• Sep 1: four crashes in one evening (19:16–21:36) while app in use.

Crash signature (10+ dumps available)

Bugcheck codes across the period: 0x00020001 (HYPERVISOR_ERROR — most frequent, 7+), 0x0000000A, 0x0000001E (arg1 0xC0000005), 0x000000F7, 0x0000013A, 0x0000003B, 0x00000101.

• Dumps attribute to ntoskrnl.exe (KeBugCheckEx); one dump names symcryptk.dll (kernel crypto — consistent with MSIX/container integrity validation under load).
• Zero WHEA events ever → not a hardware fault surfacing on its own.
• Multi-code zoo + hypervisor emphasis is consistent with user-mode memory corruption escalating through the virtualization/container stack, as previously documented in:
• anthropics/claude-code #30137 (0x139/0x1E/0x50, Win 26200 — closed "not planned")
• anthropics/claude-code #69359 (Cowork + large MCP payload BSODs 0x34/0x139/0x13A — closed duplicate)
• anthropics/claude-code #80912 (July 24, 2026 — same signature, open/stale, unanswered)
• anthropics/claude-code #32870 (Wof.sys via NtQueryDirectoryFileEx)
• oven-sh/bun #27692 / #21875 (runtime memory corruption escalating to kernel)

Mitigations attempted (all insufficient)

1. BIOS update (ASRock P4.00→P10.50), GPU driver updates, chipset current — no effect on app-correlated crashes
2. sfc (found+repaired, then clean), DISM RestoreHealth, chkdsk — crashes continued
3. Windows Memory Diagnostic — clean
4. Removed unrelated kernel drivers (LibreHardwareMonitor/PawnIO fully uninstalled) — crashes continued with them gone
5. Windows Update preview channel disabled — crashes continued
6. CoworkVMService set to demand-start (registry; sc.exe config is Access-denied even elevated — service ACL locked) — reverted to Automatic by an app auto-update within days; crashes continued regardless
7. MSIX Repair of the app (Sep 1) — under observation

Repro conditions

Long/heavy Claude Desktop sessions (local agent/Cowork workloads, MCP connectors, frequent subprocess spawning). Crashes occur both mid-session and while the app's background components idle.

Asks

1. Acknowledge and link this to the open #80912 family rather than closing as duplicate-without-fix
2. Investigate the Cowork VM service + Bun runtime memory-safety on Windows 11 26200 (interaction with VBS/Hyper-V and MSIX integrity validation per the symcryptk attribution)
3. Provide a supported way to run the app with kernel-facing components disabled (the service's ACL currently blocks even Administrators from sc config)
4. Interim guidance for affected users

Minidumps and full event-log timeline available on request.