Skip to content

[BUG] Claude Code sessions cause Windows kernel BSODs (0x139, 0x1E, 0x50) — not application crashes, full OS crashes requiring hard reboot #30137

New issue
New issue
Closed as not planned
Closed as not planned
[BUG] Claude Code sessions cause Windows kernel BSODs (0x139, 0x1E, 0x50) — not application crashes, full OS crashes requiring hard reboot#30137
Labels
area:corebugSomething isn't workinghas reproHas detailed reproduction stepsplatform:windowsIssue specifically occurs on Windows

Description

@joe-hireable
joe-hireable
opened on Mar 2, 2026

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

This is NOT a duplicate of the existing Bun crash issues (#21875, #27847, #18405). Those issues document Bun application-level segfaults and panics. This issue documents the next level of severity: Claude Code sessions are causing Windows kernel blue screens (BSODs) — full operating system crashes that require hard reboots and risk file system corruption.

I experienced 5 BSODs in 2 days (1–2 March 2026), all during or immediately after Claude Code sessions. The system is otherwise completely stable under sustained heavy loads (gaming, development, compilation).

Why this is distinct from existing Bun crash issues

Existing issues (#21875, #27847) This issue
Bun process segfaults/panics Windows kernel crashes (BSODs)
Claude Code exits to terminal Entire OS goes down — all apps, all unsaved work lost
Recovery: restart Claude Code Recovery: hard reboot required
Risk: lost session state Risk: file system corruption, hardware damage from unclean shutdowns
Bugcheck: none (user-mode crash) Bugcheck codes: 0x139, 0x1E, 0x50 (kernel-mode failures)
Minidumps: Bun crash reports Minidumps: Windows kernel crash dumps with bugcheck analysis

The Bun memory corruption documented in #21875 (N-API race conditions, GC use-after-free) appears to be severe enough in some cases to propagate beyond user-mode and corrupt kernel-visible structures, particularly through the file system path.

Environment

Component Value
OS Windows 11, Build 26200 (x64)
CPU Intel Core i9-14900HX (32 logical processors)
RAM 32GB
Hardware PCSpecialist Recoil VIII 17 (TongFang GM7IX8N)
Claude Code Latest at time of crashes
Installation methods tested Native install AND npm install — both cause BSODs

BSOD Details (WhoCrashed analysis)

Crash 1 — Mon 02/03/2026 14:24:04
Bugcheck 0x139 KERNEL_SECURITY_CHECK_FAILURE — kernel detected corruption of a critical data structure.
Parameters: (0xA, 0x0, 0x0, 0xFFFFEF82EFE267F0)
Dump: C:\Windows\Minidump\030226-24468-01.dmp

Crash 2 — Sun 01/03/2026 17:52:09
Bugcheck 0x139 KERNEL_SECURITY_CHECK_FAILURE — identical to Crash 1.
Parameters: (0xA, 0x0, 0x0, 0xFFFFE2809452E7F0)
Dump: C:\Windows\Minidump\030126-25015-01.dmp

Crash 3 — Sun 01/03/2026 17:44:09
Bugcheck 0x1E KMODE_EXCEPTION_NOT_HANDLED — kernel-mode unhandled exception.
Parameters: (0xFFFFFFFFC0000005, 0xFFFFF806910B30B0, 0x0, 0xFFFFFFFFFFFFFFFF)
Dump: C:\Windows\Minidump\030126-24234-01.dmp

Crash 4 — Sun 01/03/2026 17:23:19
Bugcheck 0x1E KMODE_EXCEPTION_NOT_HANDLED — identical type to Crash 3.
Parameters: (0xFFFFFFFFC0000005, 0xFFFFF806B904DF17, 0x0, 0xFFFFFFFFFFFFFFFF)
Dump: C:\Windows\Minidump\030126-24812-01.dmp

Crash 5 — Sun 01/03/2026 17:16:08
Bugcheck 0x50 PAGE_FAULT_IN_NONPAGED_AREA — invalid system memory referenced.
Module: Ntfs.sys (NT File System Driver)
Parameters: (0xFFFFF806CD582E50, 0x10, 0xFFFFF8064D582E50, 0x2)
Dump: C:\Windows\Minidump\030126-23296-01.dmp

Key observations:

  • Crashes 3, 4, and 5 occurred in a 36-minute cascade (17:16 → 17:44 → 17:52), consistent with the cascade degradation pattern documented in Repeated Bun v1.3.5 segfaults -- 78 crashes, root cause identified (Windows + WSL) #21875
  • WhoCrashed found no offending third-party drivers in any of the 5 dumps
  • The 0x139 parameter 1 = 0xA indicates LIST_ENTRY corruption — consistent with heap corruption propagating to kernel structures
  • The 0x1E with code 0xC0000005 (ACCESS_VIOLATION) at kernel addresses suggests corrupted pointers reaching kernel-mode code
  • The Ntfs.sys crash is particularly concerning — heavy file I/O during Claude Code sessions may be triggering file system-level corruption
  • System is otherwise rock-stable under sustained heavy loads (gaming, other development tools, compilation)

030126-23296-01.dmp
030126-24234-01.dmp
030126-24812-01.dmp
030126-25015-01.dmp
030226-24468-01.dmp

What Should Happen?

Claude Code should never cause an operating system kernel crash. If the Bun runtime encounters memory corruption, it should crash at the application level (as documented in #21875) without propagating corruption to kernel-visible structures. The existing Bun crash issues need to be treated with higher urgency given that the consequences now extend beyond lost sessions to full OS crashes and potential data loss.

Error Messages/Logs

WhoCrashed conclusion:
> 5 crash dumps have been found and analyzed. No offending third party drivers have been found.

I have the 5 minidump files from `C:\Windows\Minidump\` and Windows Event Viewer error logs available. Happy to upload if needed.

Steps to Reproduce

Steps to Reproduce

  1. Windows 11 x64, Intel i9-14900HX, 32GB RAM
  2. Install Claude Code (tested both native and npm install — both cause BSODs)
  3. Use Claude Code for extended sessions (30+ minutes)
  4. System BSODs — no Bun crash dialog, no application-level error, straight to kernel panic and forced reboot

Not deterministic, but 5 BSODs in 2 days makes Claude Code unusable on this machine.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.63 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Related issues (for context, not duplicates):

What I've ruled out:

  • Hardware: System is stable under all other workloads including sustained gaming and heavy compilation
  • Drivers: WhoCrashed found no third-party driver involvement
  • BIOS: Aware of Intel 13th/14th Gen microcode issues. While I plan to check for a BIOS update, crashes are exclusively correlated with Claude Code sessions, not general usage
  • Installation method: Tested both native and npm — identical behaviour
  • Terminal: Tested on PowerShell and WSL, Integrated VS Code Terminal as well as Standalone. BSOD Issues persist.
  • RAM: 32GB, no issues detected in other workloads

Activity

  1. joe-hireable
    added
    bugSomething isn't working
    on Mar 2, 2026
  2. github-actions
    added
    platform:windowsIssue specifically occurs on Windows
    has reproHas detailed reproduction steps
    area:core
    on Mar 2, 2026

  3. github-actions commented on Mar 2, 2026

    @github-actions
    github-actionsBot
    on Mar 2, 2026 – with GitHub Actions

    Found 3 possible duplicate issues:

    1. [BUG] CRITICAL - Claude Code crashing my PC and forcing reboot. Not RAM/memory issue #30094
    2. [BUG] orphaned processes from subagents crashing computer #18405
    3. [BUG] Claude CLI Code tool is completely crashing my computer. Your software is crap #15291

    This issue will be automatically closed as a duplicate in 3 days.

    • If your issue is a duplicate, please close it and 👍 the existing issue instead
    • To prevent auto-closure, add a comment or 👎 this comment

    🤖 Generated with Claude Code

  4. joe-hireable commented on Mar 2, 2026

    @joe-hireable
    joe-hireable
    on Mar 2, 2026
    Author

    @Jarred-Sumner

  5. joe-hireable commented on Mar 3, 2026

    @joe-hireable
    joe-hireable
    on Mar 3, 2026
    Author

    @bcherny

  6. Lumengine commented on Mar 8, 2026

    @Lumengine
    Lumengine
    on Mar 8, 2026

    Same on my side. I had 15 BSOD yesterday, even with simple session (around 5min). It's barely unusable.

  7. VRDate commented on Mar 10, 2026

    @VRDate
    VRDate
    on Mar 10, 2026

    This is the same root cause I documented in #32870 with full WinDbg analysis.

    Root cause: Wof.sys (Windows Overlay Filter) version 10.0.26100.5074 has a CFG (Control Flow Guard) bug at WofPreDirectoryControlCallback+0x695. Claude Code's heavy NtQueryDirectoryFileEx calls (from Glob/Grep tools scanning directories) trigger this crash.

    Your 0x139 with parameter 0xA = GUARD_ICALL_CHECK_FAILURE — that's the exact same CFG indirect-call guard violation I see. The 0x1E and 0x50 are likely cascading from the same Wof.sys corruption.

    My stats: 11 BSODs across 3 days (7 + 1 + 3), all triggered by claude.exe doing directory listings. @Lumengine's 15 BSODs in one day is consistent with this pattern.

    Workaround: compact /CompactOS:never (from elevated cmd) reduces frequency but doesn't eliminate crashes — Wof.sys callback fires on every directory IRP regardless of CompactOS state.

    Microsoft bug report: https://learn.microsoft.com/en-us/answers/questions/5814272/wof-sys-bsod-0x139-kernel-security-check-failure-i

    WinDbg failure bucket: 0x139_a_GUARD_ICALL_CHECK_FAILURE_Wof!WofPreDirectoryControlCallback+0x695
    Failure hash: {78ac0991-5393-0281-b23b-ce115373dc6d}

    All minidumps + diagnostics: Google Drive ZIP

  8. VRDate commented on Mar 10, 2026

    @VRDate
    VRDate
    on Mar 10, 2026

    Correction on root cause theory: The original issue attributes BSODs to "Bun memory corruption propagating to kernel structures" — this is not what's happening. User-mode memory corruption cannot cause a CFG guard failure in a kernel driver.

    The 0x139 parameter 0xA (GUARD_ICALL_CHECK_FAILURE) is a compile-time Control Flow Guard check inside Wof.sys — it means the driver's own indirect call dispatch table has an invalid target at offset +0x695. This is a code defect in the driver binary itself, not corruption from outside.

    These are two separate bugs:

    Bun crashes (#21875) Kernel BSODs (this issue)
    User-mode: Bun process segfaults Kernel-mode: Wof.sys driver crashes
    Cause: Bun N-API race / GC issues Cause: Wof.sys CFG bug at WofPreDirectoryControlCallback+0x695
    Fix owner: Anthropic / Oven (Bun) Fix owner: Microsoft
    Effect: claude.exe exits Effect: entire OS crashes

    Claude Code just happens to trigger both: Bun crashes from its runtime, and the Wof.sys BSOD from its heavy directory enumeration (NtQueryDirectoryFileEx).

    @Lumengine — try compact /CompactOS:never from an elevated command prompt. It won't fully fix it but should reduce the crash rate significantly.

  9. zhimin-z commented on Mar 11, 2026

    @zhimin-z
    zhimin-z
    on Mar 11, 2026

    Same for me...

  10. VRDate commented on Mar 11, 2026

    @VRDate
    VRDate
    on Mar 11, 2026

    Related: Feedback Hub report for Wof.sys BSOD

    A Feedback Hub report has been filed for the Wof.sys kernel crash that affects Claude Code users. Microsoft's Q&A community advisor confirmed this is a core driver defect.

    Feedback Hub link: https://aka.ms/AA106t77

    Please upvote to help Microsoft prioritize a Wof.sys patch. Full technical details in #32870.

  11. VRDate commented on Mar 14, 2026

    @VRDate
    VRDate
    on Mar 14, 2026

    Workaround: Run Claude Code in WSL to avoid Wof.sys BSOD

    Full writeup: https://gist.github.com/VRDate/862268b57dd197b8775f893a7be1e548

    Claude Code BSOD Workaround — Wof.sys Crash on Windows 11 Build 26200+

    Problem

    Claude Code triggers BSOD (Blue Screen of Death) on Windows 11 Build 26200+ during normal operation. The crash occurs in Wof.sys (Windows Overlay Filter) when Claude's filesystem operations call NtQueryDirectoryFileEx, which passes through the WOF minifilter and hits a CFG (Control Flow Guard) violation.

    Bugcheck codes: 0x139 (KERNEL_SECURITY_CHECK_FAILURE), 0x3B, 0x1E, 0x50

    Faulting module: Wof.sys 10.0.26100.5074 at WofPreDirectoryControlCallback+0x695

    Trigger: Any filesystem-heavy operation — directory listing, file search, glob patterns — the kind of thing Claude Code does constantly.

    Bug reports:

    Root Cause

    This is a Windows kernel bug, not a Claude Code bug. Wof.sys (Windows Overlay Filter) handles WIM-backed files and CompactOS compression. When Claude Code (or any process) makes rapid NtQueryDirectoryFileEx calls on NTFS volumes, the WOF minifilter crashes in its directory control callback. CompactOS ON/OFF makes no difference — the bug is in the minifilter code path itself.

    WOF is a critical Windows component — it cannot be disabled, detached, or unloaded without breaking Windows.

    Workaround: Run Claude Code in WSL

    Since the crash only happens on NTFS (Windows filesystem), running Claude Code inside WSL2 (which uses ext4) completely bypasses the Wof.sys code path.

    Setup (5 minutes)

    Prerequisites: WSL2 with Ubuntu (from Microsoft Store).

    # 1. Install Ubuntu from MS Store (if not already)
wsl --install Ubuntu-24.04

# 2. Install Node.js inside WSL
wsl -d Ubuntu-24.04 -u root -- bash -c '
  curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
  apt install -y nodejs
'

# 3. Install Claude Code inside WSL
wsl -d Ubuntu-24.04 -u root -- npm install -g @anthropic-ai/claude-code

# 4. Verify
wsl -d Ubuntu-24.04 -u root -- claude --version

    Create the wrapper

    Create claude.cmd in the same directory as claude.exe (typically %USERPROFILE%\.local\bin\):

    @echo off
wsl -d Ubuntu-24.04 -u root -- claude %*

    On Windows, .cmd takes priority over .exe in the same directory. Every claude invocation from cmd.exe, PowerShell, or Windows Terminal now goes through WSL automatically.

    How it works

    BEFORE (crashes):
  Windows cmd/terminal
    → claude.exe (Windows native)
      → NtQueryDirectoryFileEx on NTFS
        → Wof.sys minifilter → BSOD

AFTER (safe):
  Windows cmd/terminal
    → claude.cmd (wrapper)
      → wsl -- claude (runs in WSL)
        → ext4 filesystem (no Wof.sys)
        → /mnt/c/ for Windows files (read/write, no WOF callback)

    Your project files stay on C:\ — Claude in WSL accesses them via /mnt/c/. Your IDE (VS Code, IntelliJ, etc.) runs on Windows watching the same files. No file duplication needed.

    Reverting

    When Microsoft patches Wof.sys, simply delete the wrapper:

    del %USERPROFILE%\.local\bin\claude.cmd

    Claude will fall back to claude.exe (Windows native).

    What doesn't work

    Attempted fix Result
    Disable CompactOS (compact /compactos:never) Still crashes
    Windows Update (KB5079473) Did not update Wof.sys
    Norton AV exclusions Unrelated (separate nllNetHub.sys crash)
    Disabling WOF service DO NOT — breaks Windows

    Affected versions

    • Windows: Build 26200+ (Windows 11 24H2 Insider/Dev)
    • Wof.sys: 10.0.26100.5074 (unchanged across updates)
    • Claude Code: All versions (the bug is in the OS, not Claude)
    • Also affects: Any process making rapid filesystem directory queries (not Claude-specific)

    Timeline

    Date Event
    2026-03-06 First BSODs after Windows upgrade to Build 26200
    2026-03-06 7 crashes in one day
    2026-03-12 Feedback Hub report filed, GitHub issues opened
    2026-03-14 WSL workaround deployed, 21 total crashes logged
    TBD Microsoft Wof.sys patch

  12. VRDate commented on Mar 14, 2026

    @VRDate
    VRDate
    on Mar 14, 2026

    Update from issue #32870 — root cause proven, workaround available

    Root cause: concurrent unthrottled filesystem tool calls from multiple Claude Code agents overwhelm Wof.sys WofPreDirectoryControlCallback on Windows 11 Build 26200+. 23 BSODs logged.

    Workaround: a "traffic light" server (JBang Kotlin) that serializes agent tool calls via a PreToolUse hook. Tested: 5 agents with traffic light = stable (381 tool calls). Without = BSOD in minutes.

    Full writeup + code + repro kit: https://gist.github.com/VRDate/862268b57dd197b8775f893a7be1e548

    Minidumps + proof: https://drive.google.com/file/d/1bnn5LPNy_ygehdc2zy2QayZ0dyt-pKqc/view?usp=sharing

  13. kolkov commented on Mar 16, 2026

    @kolkov
    kolkov
    on Mar 16, 2026

    Experienced a complete system deadlock on Windows 10 with Claude Code v2.1.76 (Opus 4.6, 1M context).

    Symptoms:

    • System did not BSOD — no crash, no blue screen
    • Windows stayed visually responsive — could switch between windows
    • Keyboard completely stopped working — no input accepted anywhere
    • Could not reboot gracefully — Ctrl+Alt+Del, Start menu, nothing responded to keyboard
    • Only recovery: hard power-off (holding power button)

    Environment:

    • Windows 10 Home 10.0.19045
    • Claude Code v2.1.76, Opus 4.6 with 1M context (just enabled)
    • GoLand IDE with Claude Code plugin
    • 40 GB RAM, WD SN740 512GB SSD

    Context:

    Previously reported: #14674 (closed/locked by bot without any team response)
    Related root cause analysis: #33949

  14. VRDate commented on Mar 17, 2026

    @VRDate
    VRDate
    on Mar 17, 2026

    Update from #32870 — 25 BSODs, root cause reframed

    Not a Wof.sys bug — Claude Code CLI misuse of the OS. The model fires parallel filesystem tool calls (Glob, Grep, Read, Bash find) with zero backpressure. 6 operations in 1 second against a 200K-file monorepo = instant BSOD.

    Proof: I built a rate-limiting mutex daemon (PreToolUse hook, serializes calls with 15-100ms delay). Ran stable for 3 days with 0 BSODs. Took daemon offline for v2 development → 2 BSODs within hours.

    The fix: Claude Code needs a built-in 15-100ms delay between filesystem tool calls. This is a CLI architecture issue, not a Windows kernel bug. Sub-agents spawned via the Agent tool also bypass PreToolUse hooks entirely — structural gap.

    25 BSODs in 12 days. Full details + workaround: https://gist.github.com/VRDate/862268b57dd197b8775f893a7be1e548

    Also relevant to @kolkov's system deadlock above — same root cause (unthrottled parallel I/O), different symptom.

  15. VRDate commented on Mar 18, 2026

    @VRDate
    VRDate
    on Mar 18, 2026

    Fix submitted: PR #35710

    This is the same root cause as #32870 — parallel filesystem tool calls overwhelming Wof.sys.

    A tool-mutex plugin fix has been submitted as PR #35710. The plugin adds a file-based counting semaphore that serializes concurrent filesystem operations, preventing the kernel driver overload that causes BSOD.

    See #32870 for full crash analysis (27 BSODs, 9 bugcheck types, memory dump analysis).

  16. github-actions
    added
    staleIssue is inactive
    on Apr 2, 2026

  17. github-actions commented on Apr 16, 2026

    @github-actions
    github-actionsBot
    on Apr 16, 2026 – with GitHub Actions

    Closing for now — inactive for too long. Please open a new issue if this is still relevant.

  18. github-actions
    closed this as not plannedon Apr 16, 2026

  19. steve-colson commented on Apr 16, 2026

    @steve-colson
    steve-colson
    on Apr 16, 2026

    Closed?!

  20. github-actions
    removed
    staleIssue is inactive
    on Apr 16, 2026

  21. github-actions commented on Apr 24, 2026

    @github-actions
    github-actionsBot
    on Apr 24, 2026 – with GitHub Actions

    This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

  22. github-actions
    locked as resolved and limited conversation to collaborators on Apr 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:corebugSomething isn't workinghas reproHas detailed reproduction stepsplatform:windowsIssue specifically occurs on Windows

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions