[BUG] Cowork regression: KERNEL_MODE_HEAP_CORRUPTION (0x13A) in storvsp!VspVsmbFileCreate — started with build 1.15962.0, not fixed in 1.15962.1.0

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?

Likely same family as #50822 (closed stale, no fix — Cowork Hyper-V PFN_LIST_CORRUPT / host memory corruption) and #57591 (closed duplicate — Cowork VM hvax64 double-fault). Filing fresh because both are closed with no resolution. This report adds a named bucket (storvsp!VspVsmbFileCreate), a timestamped regression (Cowork update 6/25 11:54 → first crash 6/25 12:11), and a second-machine repro that the prior reports lack.

Platform

• Windows 11 Pro, build 26100 (24H2). Also reproduced after updating one host to 26200 (25H2, 26200.8737) — crash persisted, so not branch-specific.
• Claude desktop, MSIX / Microsoft Store install (package family Claude_pzs8sxrjxfjjc).
• Reproduced on two separate machines: the original (Intel, Dell) and a second, newer workstation.

What's wrong

Host BSODs with bugcheck 0x13A (KERNEL_MODE_HEAP_CORRUPTION) during Cowork sandbox use. Kernel dump shows nonpaged-pool corruption (delay-free list, Arg1 = 0x17 = use-after-free or adjacent-block overrun) detected during allocation in the Hyper-V vSMB host-storage path.

FAILURE_BUCKET_ID: 0x13a_17_storvsp!VspVsmbFileCreate

storvsp!VspVsmbFileCreate+0x5a9
  -> nt!NtQueryVolumeInformationFile
    -> nt!ExAllocatePool2
      -> pool corruption detected (nt!RtlpHeapHandleError -> KeBugCheckEx)

!pool on the corruption address: "Corrupt region", invalid previous size.
"Scanning for single bit errors... None found"  -> structural corruption, not RAM.

The faulting thread is a System worker running storvsp!VspVsmbCreateFileWorker — i.e. the Cowork VM's host-directory sharing over vSMB.

Regression timeline (from AppxDeployment-Server log + System Event ID 1001)

Cowork had run cleanly for ~2 weeks. Then:

| Time (local) | Event |
|---|---|
| 2026-06-17 .. 06-23 | Routine Cowork package updates, no crashes |
| 2026-06-25 11:54 | Cowork package version change (update registered) |
| 2026-06-25 12:11 | First 0x13A bugcheck — 17 minutes later |
| 2026-06-26 (cluster) | Repeated 0x13A crashes; main.log banners appVersion 1.15962.0 |
| 2026-06-29 09:27 | Updated to 1.15962.1.0 |
| 2026-06-29 11:02, 14:13 | Still crashing 0x13A after the update |

Bad build introduced at 6/25: 1.15962.0. Point release 1.15962.1.0 (6/29) does not fix it.

Ruled out (with evidence)

• RAM — no single-bit errors in !pool; identical deterministic bucket across every crash. Not stochastic.
• SentinelOne EDR + OES client — both present, but fleet-wide; only machines running Cowork crash. A second host with an older OES client version crashes identically. Eliminates both as the variable.
• Stale third-party driver — a legacy MiniTool pwdrvio.sys (BOOT_START) was found and disabled; crash persisted unchanged.
• Windows patch level — storvsp.sys unchanged since 6/11 (v10.0.26100.1); no Windows cumulative installed in the days before the 6/25 crash onset. Updating the OS to 25H2 did not help.
• Hardware — reproduced on a second, newer machine.

The only thing that changed in the crash window was the Cowork build registered at 2026-06-25 11:54.

Repro

Run a file/network-heavy Cowork session on an affected host. BSOD within minutes to ~1 hour.

Artifacts available

• Full kernel MEMORY.DMP (CrashDumpEnabled=2) with the bucket above.
• !analyze -v and !pool output.
• AppxDeployment version-change log and Event ID 1001 history establishing the timeline.

Ask

1. What changed in the sandbox's vSMB host-share mount / file-metadata (volume-information) handling between the pre-6/23 build and 1.15962.0?
2. Is 1.15962.1.0 expected to address this? (It does not, in our testing.)
3. Can the host-share mount mode or file-metadata enumeration be made configurable / throttled as a mitigation while a fix is prepared?

What Should Happen?

Running a Cowork session should not bugcheck the Windows host. The sandbox's host-storage sharing (vSMB) should not corrupt kernel nonpaged pool.

Error Messages/Logs

FAILURE_BUCKET_ID: 0x13a_17_storvsp!VspVsmbFileCreate

storvsp!VspVsmbFileCreate+0x5a9
  -> nt!NtQueryVolumeInformationFile
    -> nt!ExAllocatePool2
      -> pool corruption (nt!RtlpHeapHandleError -> KeBugCheckEx)

!pool: "Corrupt region", invalid previous size. No single-bit errors (not RAM).

Steps to Reproduce

1. Windows 11 host, Claude desktop (MSIX) 1.15962.1.0, Cowork enabled.
2. Start a Cowork session and run a file/network-heavy task.
3. Host BSODs with 0x13A (storvsp!VspVsmbFileCreate) within minutes to ~1 hour.
4. Reproduced on two separate machines; persists after updating to 1.15962.1.0.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Yes. Worked for ~2 weeks until the Cowork update registered 2026-06-25 11:54 (first crash 17 min later). Bad build: 1.15962.0. Exact prior version string not captured before the 6/29 update overwrote it.

Claude Code Version

Claude desktop (MSIX/Store) 1.15962.1.0 — not the Claude Code CLI. Filing here because Cowork BSODs are triaged in this repo (see #50822, #57591).

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_