[BUG] Cowork Hyper-V causes PFN_LIST_CORRUPT BSOD and potential NVMe data corruption

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?

What's Wrong?

Cowork's Hyper-V/Windows Sandbox VM is causing host memory corruption (PFN database), resulting in repeated BSODs and potentially contributing to NVMe drive data integrity errors. Three kernel crashes occurred within 72 hours after resuming Cowork usage, following a month of zero crashes without it.

Timeline

• Late February 2026: Original system corruption incident. Windows 11 OS on a Kingston SNV3S2000G 2TB NVMe became unrecoverable during active Cowork use while writing files to disk. CrystalDiskInfo revealed 33,783 Media and Data Integrity Errors (SMART attribute 0D) on a drive with 0% wear and full available spare.
• Late February – mid April 2026: Stopped using Cowork entirely, switched to web chat UI only. Replaced the Kingston drive with a Samsung 9100 PRO 1TB NVMe. Zero crashes for over a month.
• ~April 14, 2026: Resumed using Cowork. Also changed power settings to sleep after 2 hours.
• April 17–19, 2026: Three BSODs in three days.

Crash Details

All three crashes logged as Kernel-Power Event ID 41. Minidumps analyzed with WinDbg (!analyze -v):

| Date | BugcheckCode | Stop Code | SleepInProgress |
|---|---|---|---|
| Apr 17 | 0x1A | MEMORY_MANAGEMENT | 5 (yes) |
| Apr 18 | 0x1000007E | SYSTEM_THREAD_EXCEPTION_NOT_HANDLED | 0 (no — active use) |
| Apr 19 | 0x4E | PFN_LIST_CORRUPT | 0 (no) |

The April 18 crash occurred during active use (Firefox open, doing taxes, Cowork instance in background). The BSOD message displayed was "SYSTEM_THREAD_EXCEPTION_NOT_HANDLED."

WinDbg Analysis (April 18 crash)

The faulting function was nt!MiGetSlabAllocatorRepurposedStandbyList — a Windows memory manager routine that manages the PFN (Page Frame Number) database. The register rax contained 7d47e20000124e05, which is outside valid kernel address space, indicating a corrupted PFN entry.

The full call stack is entirely within Windows memory management internals (no third-party drivers):

nt!MiGetSlabAllocatorRepurposedStandbyList+0x20
nt!MiUnlinkPageFromListEx+0x907
nt!MiRemoveLowestPriorityStandbyPage+0x3c8
nt!MiPruneStandbyPages+0x18f
nt!MiRebalanceZeroFreeLists+0xb6
nt!ExpWorkerThread+0x4bb
nt!PspSystemThreadStartup+0x5a
nt!KiStartSystemThread+0x34

Key detail: Hyper-V is confirmed active in the dump:

Hypervisor.RootFlags.IsHyperV: 1
Hypervisor.Flags.AnyHypervisorPresent: 1
Hypervisor.Flags.VsmAvailable: 1

Failure bucket: AV_nt!MiGetSlabAllocatorRepurposedStandbyList

Connection to Drive Corruption

The Kingston NVMe accumulated 33,783 media integrity errors during the period Cowork was in active use, despite 0% wear and 100% available spare — consistent with a manufacturing defect, but also consistent with corrupted memory being written to disk by a faulty hypervisor layer. After a month without Cowork and a rescan on April 19, the count had risen to 33,923 (+140 errors from continued light use).

The new Samsung 9100 PRO already shows 5 unsafe shutdowns in only 67 power cycles (60 hours of use), all corresponding to the period after Cowork was resumed.

Root Cause Hypothesis

Cowork uses Windows Sandbox, which relies on Hyper-V. The hypervisor sits between hardware and the OS memory manager. The PFN database — exactly what's corrupted in these crashes — is where host-VM memory interactions are managed. Two of the three crashes occurred during or after sleep transitions (SleepInProgress non-zero), suggesting the VM is not cleanly suspending before Windows freezes memory state.

However, the April 18 crash occurred during active use with no sleep involvement, indicating the memory corruption may not be limited to sleep transitions.

Workaround

I created a killswitch script that tears down CoworkVMService and kills the VM process, registered as a scheduled task triggered by Kernel-Power Event ID 42 (system entering sleep). This prevents the VM from being in an inconsistent state during sleep transitions but does not address the active-use crash scenario.

System Info

| Component | Detail |
|---|---|
| OS | Windows 11 (Build 26100.8246) |
| CPU | AMD Ryzen 7 3700X 8-Core Processor, 3600 Mhz, 8 Core(s), 16 Logical Processor(s) |
| RAM | Corsair Vengeance LPX 32 GB (2 x 16 GB) DDR4-3200 CL16 Memory, XMP enabled 3200 Mhz |
| Boot drive | Samsung 9100 PRO 1TB NVMe (C:) |
| Former drive | Kingston SNV3S2000G 2TB NVMe (RMA pending) |
| Secondary drive | Crucial MX500 2TB SATA SSD (D:) |
| Claude Desktop | Claude 1.3109.0 (35cbf6) 2026-04-16T20:32:01.000Z |

What Should Happen

Cowork's VM should not corrupt host memory under any circumstances — during sleep transitions, active use, or otherwise. If the VM cannot safely coexist with Windows memory management under Hyper-V, Cowork should either cleanly suspend the VM before sleep or warn users about the risk.

What Should Happen?

Cowork's VM should not corrupt host memory under any circumstances — during sleep transitions, active use, or otherwise. If the VM cannot safely coexist with Windows memory management under Hyper-V, Cowork should either cleanly suspend the VM before sleep or warn users about the risk.

Error Messages/Logs

See above

Steps to Reproduce

Inconsistently occurs after opening a Claude Cowork instance and allowing the PC to sleep.
BSOD occurs when turning PC back on after sleep.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

N/A

Claude Code Version

N/A

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_