Cowork crash pc when select a old conversation

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?

Subject: Reproducible BSOD (KERNEL_MODE_HEAP_CORRUPTION) when opening an old conversation in Claude Cowork — multiple machines

What Should Happen?

Not power down the pc with crash kernel

Error Messages/Logs

Subject: Reproducible BSOD (KERNEL_MODE_HEAP_CORRUPTION) when opening an old conversation in Claude Cowork — multiple machines

Summary:
Claude Cowork is causing a consistent, reproducible system crash (BSOD) when opening an old conversation. The exact same bugcheck has been confirmed on multiple machines.

Steps to reproduce:
1. Open Claude Cowork
2. Access an old conversation (existing history)
3. The system crashes with a BSOD (KERNEL_MODE_HEAP_CORRUPTION)

Technical details (analyzed via WinDbg, !analyze -v, across 3 different kernel dumps):
- Bugcheck: 0x13A (KERNEL_MODE_HEAP_CORRUPTION)
- Arg1: 0x17 — "heap detected that a block was corrupted in a delay free list. This is likely a use-after-free error or a buffer overflow of an adjacent block"
- Failure.Bucket: 0x13a_17_nt!RtlpHeapHandleError
- Failure.Hash: {b1500314-0083-90bd-d812-716f3060523d} — identical across all 3 dumps analyzed
- Stack trace consistent across all 3 dumps, entirely within the Windows kernel itself (nt!ExpWorkerThread → nt!RtlpHpLfhOwnerCompact → nt!RtlpHeapHandleError), process "System", no third-party driver appears on the stack
- Windows build: 10.0.26100.8972 (Windows 11 24H2)

Elimination steps already performed:
- Driver Verifier enabled specifically on the ESET antivirus drivers (ehdrv.sys, epfw.sys, epfwwfp.sys, eamonm.sys) — no violation detected; crash recurred with the same signature
- Driver Verifier enabled specifically on the GPU drivers (dxgkrnl.sys, igdkmdn64.sys) — no violation detected; crash recurred with the same signature
- Confirmed the issue occurs on multiple different machines, which rules out a hardware (RAM) failure as the likely cause, since that would be expected to produce distinct signatures on distinct hardware

Our conclusion:
Since Driver Verifier caught no third-party driver across two targeted test rounds, and the issue is reproducible on multiple machines with the same failure bucket, the most likely cause is an interaction between Cowork (possibly related to the memory allocation volume/pattern when loading an old conversation with a large history) and a heap management bug in the Windows kernel itself (Low Fragmentation Heap / delay free list), which may already be fixed or pending a fix in a more recent cumulative update.

I'd appreciate it if the technical team could:
1. Confirm whether there are similar reports from other users
2. Check whether there's a memory allocation pattern when loading long conversations that could be exposing this behavior
3. Advise on any mitigation in the meantime (e.g., limiting how much history is loaded at once)

Happy to provide the full .dmp files or further details if useful.

Steps to Reproduce

select a old conversation

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.25927

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_