[BUG] claude.exe triggers Windows BSOD via Wof.sys during directory listing (NtQueryDirectoryFileEx)

BSOD #20 — 2026-03-14 00:19

Another crash overnight. Same identical bug:

Bugcheck: 0x139 KERNEL_SECURITY_CHECK_FAILURE
Bucket: 0x139_a_GUARD_ICALL_CHECK_FAILURE_Wof!WofPreDirectoryControlCallback
Hash: {78ac0991-5393-0281-b23b-ce115373dc6d}
Process: claude.exe

Stack:

claude.exe → NtQueryDirectoryFileEx → FLTMGR → Wof!WofPreDirectoryControlCallback+0x695
  → Ntfs!FindNextIndexEntry2+0x675 → KscpCfgDispatchUserCallTargetEsSmep+0x11
  → KiGeneralProtectionFault → guard_icall_handler → KeBugCheckEx

System state:

• Wof.sys 10.0.26100.5074 — unchanged, no Microsoft patch
• CompactOS OFF since 03-09
• No WHEA hardware errors
• System uptime before crash: 1 day 21 hours
• Dump: 031426-31890-01.dmp (17MB)

Running total: 20 BSODs in 9 days (03-06 through 03-14). Same offset (+0x695), same process (claude.exe), same trigger (NtQueryDirectoryFileEx from concurrent ripgrep).

Still waiting for any acknowledgment or workaround suggestion from Anthropic. Even a simple "limit concurrent ripgrep processes" flag would help.

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:

• Feedback Hub
• claude-code #32870 — "Claude Code triggers Wof.sys BSOD on Windows 11 Build 26200"
• claude-code #30137
• MS Q&A #5814272

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 |

Update: Root cause proven + workaround tested (23 BSODs total)

What causes the crash

Claude Code fires multiple filesystem operations (reading files, searching directories) at the same time — especially when using sub-agents. On Windows 11 Build 26200+, the kernel driver Wof.sys cannot handle this many simultaneous directory queries and crashes with a Blue Screen.

It's not about how many files you have — it's about how many are read at the same time. One agent reading files one after another is fine. Two or more agents reading files simultaneously triggers the crash.

Proof from session logs

Extracted the exact tool calls from the JSONL transcript before each crash:

• BSOD #22 (03-14 04:42) — 5 agents running in parallel via WSL, all reading files at the same time → kernel crash
• BSOD #23 (03-14 05:32) — 2 sub-agents launched in the same response, both scanning 18 files concurrently → kernel crash

03:48:26  Claude finds 18 files matching *.jbang.kt
03:48:42  Sub-agent 1 starts reading all 18 files
03:49:51  Sub-agent 2 starts reading all 18 files (while #1 still running)
          ── both agents reading files at the same time ──
          ── 30-50 simultaneous filesystem calls ──
05:32:59  *** BLUE SCREEN — Wof.sys crash ***

Workaround: a "traffic light" for file operations

The fix is a tiny server that acts like a traffic light — it makes Claude's file operations wait in line instead of all running at once. Only one operation goes through at a time.

How it works:

1. A small background server runs on your machine (port 9876)
2. Before every file operation, Claude Code asks the server "can I go?"
3. The server lets one operation through at a time, with a small delay between each
4. This prevents the simultaneous burst that crashes Windows

Setup (2 minutes):

Install JBang (one-line install, runs on any Java), then:

# 1. Start the traffic light server in the background
jbang Mutex.jbang.kt &

# 2. Add this to ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Read|Glob|Grep|Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "bash mutex-acquire.sh"
          }
        ]
      }
    ]
  }
}

That's it. Claude Code will now wait in line for file operations instead of firing them all at once. If the server isn't running, Claude works normally (no impact on single-agent usage).

Speed: The default delay is 2 seconds between operations (safest). For faster interactive work, start with jbang Mutex.jbang.kt --interval 100 (100ms between operations — 10x faster, still safe in testing).

Test results

| Scenario | Tool calls | Result |
|----------|-----------|--------|
| 5 agents, no traffic light | ~36 concurrent reads | BSOD in minutes |
| 5 agents, with traffic light | 381 serialized calls | Stable, no crash |
| Normal tools (TreeSize, robocopy) | Sequential | Stable, no crash |

Files (all in the gist)

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

| File | What it does |
|------|-------------|
| Mutex.jbang.kt | The traffic light server (~120 lines of Kotlin) |
| mutex-acquire.sh | The hook script that asks "can I go?" (6 lines of bash) |
| TestMutex.jbang.kt | Tests to verify the traffic light works correctly |
| gen-repro-data.sh | Script to reproduce the crash: generates test data + agent prompts |
| claude-bsod-workaround.md | Full documentation with setup instructions |

Minidump update — 23 BSODs, new ZIP with proof + mutex

New ZIP (4 dumps from 03-14 + root cause proof + mutex workaround):
https://drive.google.com/file/d/1bnn5LPNy_ygehdc2zy2QayZ0dyt-pKqc/view?usp=sharing

Contains: 4 minidumps, bsod-22-23-concurrent-proof.md (JSONL-extracted timeline proving concurrent agent I/O = crash), Mutex.jbang.kt (traffic light server), mutex-acquire.sh (hook), TestMutex.jbang.kt (tests), gen-repro-data.sh (1GB repro kit + 5 agent prompts).

Updated gist: https://gist.github.com/VRDate/862268b57dd197b8775f893a7be1e548

Update: 25 BSODs — root cause reframed

After 12 days and 25 BSODs, the root cause is clear: this is not a Wof.sys bug — it's Claude Code firing parallel filesystem tool calls with zero backpressure.

Proof: mutex daemon = stable, no mutex = crash

I built a rate-limiting daemon (the "traffic light" from my earlier post) that serializes filesystem tool calls with a configurable delay. Results:

| Period | Mutex daemon | BSODs |
|--------|-------------|-------|
| 03-14 to 03-16 (~3 days) | Running (v1, 100ms-2s interval) | 0 |
| 03-17 night | Offline (developing mutex v2 on sandbox port) | 2 within hours |

The moment the daemon was taken offline for development, BSODs returned. The production daemon wasn't running because I was testing a new version on a different port.

What happened on 03-17

Session was developing mutex daemon v2 (MCP protocol, team tracking, SSE events). All 118 tests passed. Then the model spawned an Explore sub-agent to search for Thymeleaf templates — 6 parallel filesystem operations in ~1 second:

• 3 Glob calls (**/*.html, **/*.thymeleaf, **/gui/**)
• 2 Grep calls (smartadmin in java + gradle files)
• 1 Bash find command

All against a 200K-file monorepo. No throttle, no delay. BSOD within seconds: 0x3B SYSTEM_SERVICE_EXCEPTION in Wof!WofPreDirectoryControlCallback.

The real issue

No kernel minifilter is designed for the kind of burst concurrency Claude Code generates. The model decides to parallelize, the CLI executes immediately. A 15-100ms delay between filesystem tool calls would eliminate the problem entirely at negligible latency cost.

This should be built into Claude Code itself — not left as a user-created workaround. My mutex daemon proves the architecture works. The CLI needs the same thing natively.

Additional structural gap

Sub-agents spawned via the Agent tool run in their own process and do not inherit the parent's PreToolUse hooks. Even with the user-side mutex daemon running, sub-agent filesystem calls are completely unprotected. This is how BSOD #25 happened — the parent session had hooks, the sub-agent didn't.

Also relevant to @kolkov's deadlock report above

The same zero-backpressure parallel tool call pattern likely causes the system deadlock on Windows 10 (no BSOD, just freeze). Different symptom, same root cause: overwhelming the filesystem with concurrent operations.

Running total: 25 BSODs in 12 days. 18 confirmed Wof.sys. All from unthrottled concurrent NtQueryDirectoryFileEx calls.

Updated gist: https://gist.github.com/VRDate/862268b57dd197b8775f893a7be1e548

@bcherny @ant-kurt @fvolcic @ashwin-ant @bogini @chrislloyd @ThariqS @catherinewu @whyuan-cc @dhollman @rboyce-ant @dicksontsai @OctavianGuzu @hackyon-anthropic @wolffiex @igorkofman @sid374 @ddworken

Requesting attention — 25 BSODs in 12 days, zero Anthropic response on this issue or #30137. Multiple affected users including @kolkov (system deadlock on Win10).

This is not a Windows kernel bug. It is Claude Code firing parallel filesystem tool calls (Glob, Grep, Read, find) with zero backpressure. 6 concurrent operations in 1 second against a large codebase crashes any Windows machine. A 15-100ms delay between calls fixes it completely — I built a mutex daemon that proves this (3 days stable, 0 BSODs; removed it → 2 BSODs within hours).

The fix is simple: add a configurable rate limit to filesystem tool calls in the CLI. I've provided the full architecture, code, tests, and repro kit. This needs to be built into Claude Code natively.

Sub-agents spawned via the Agent tool also bypass PreToolUse hooks entirely — even the user-side workaround can't protect against that.

This issue has has repro, bug, and platform:windows labels but no assignee, no milestone, and the external label dismisses it as an OS problem. It isn't.

Fix submitted: PR #35710

A tool-mutex plugin has been developed and submitted as PR #35710 to fix this issue.

Root cause confirmed: Claude Code executes Glob/Grep/Read/Bash tools in parallel with no concurrency limit. Each triggers NtQueryDirectoryFileEx syscalls that overwhelm the Wof.sys kernel driver, causing BSOD.

Fix: File-based counting semaphore plugin that serializes filesystem tool calls:

• Windows: max 1 concurrent op (prevents Wof.sys overload)
• Linux/macOS: max 4 concurrent ops (prevents OOM)
• 75ms cooldown between operations
• PID-based stale slot cleanup

Verified: 256 concurrent workers — without mutex: 7/256 completed (16GB RSS, 249 timeouts). With mutex: 256/256 completed (290MB RSS, zero crashes).

27 BSODs logged on a 192GB/32-core workstation over 12 days before this fix was developed. 9 distinct bugcheck types (0x139, 0x3B, 0x1E, 0x50, 0x14F, 0x10E, 0x20001, 0xC2).

Cross-references:

• PR: #35710
• Related issue: #30137
• MS Q&A: https://learn.microsoft.com/en-us/answers/questions/5814272
• Feedback Hub: https://aka.ms/AA106t77
• Minidump ZIP (20 unique dumps, 87MB): https://drive.google.com/file/d/1Iqo8Ey4CjHfGbPMMRxlZVxaVf-N3i5Ab/view?usp=sharing

@anthropics/claude-code-maintainers @anthropics/claude-code-reviewers @claude
@bcherny @ant-kurt @fvolcic @ashwin-ant @bogini @chrislloyd @ThariqS @catherinewu @whyuan-cc @dhollman @rboyce-ant @dicksontsai @OctavianGuzu @hackyon-anthropic @wolffiex @igorkofman @sid374 @ddworken
@OctavianGuzu @chrislloyd @ant-kurt — requesting a direct review from one of you. Still, no one is assigned to review https://github.com/anthropics/claude-code/pull/35710.

@VRDate Your PR and root cause analysis are excellent. For context — the parallel fs calls without backpressure you found is one of several architectural issues we've documented through reverse-engineering cli.js across 16 npm versions:

1. No file locking on Read/Edit tools — concurrent agents overwrite each other's edits (#33949)
2. Non-atomic JSONL writes — insertMessageChain() writes tool_use and tool_result one at a time in a for-loop, unchanged across 8 versions checked
3. Streaming watchdog exists but disabled — CLAUDE_ENABLE_STREAM_WATCHDOG hidden since v2.1.50, recently tuned to 45s/90s in v2.1.79 but still behind feature flag
4. Bun/mimalloc crashes — 6 crashes in 4 days on Windows, 10-15 GB committed memory even in idle, process crashes taking down IDE (#36132)
5. 21 threads per process — GDB analysis by @rstuart shows all Bun Pool threads deadlocked on a single futex (#26224)

Team response across all these: zero on streaming/crash issues for 8+ months. @catherinewu said "actively investigating" on Feb 23 — 30 days of silence since.

Your experience with the PR not being reviewed is unfortunately consistent.

Our issues: #33949 (root cause analysis) | #36132 (Bun memory crashes) | #35171 (auto-updater leak)
Related: #6836 (orphaned tool calls, 150+ reports) | #3648 (scroll bug, 👍694) | #26224 (streaming hangs, deadlock analysis by @rstuart)

@kolkov, My PR is a plugin I have been using for several days, and it is in the sweet spot between slowing down just 75ms and still letting the system work without crashing. I recommend installing it and reading the code at https://github.com/VRDate/claude-code/tree/claude/add-tool-mutex-Qytsn/plugins/tool-mutex. It uses a mutex to avoid excessive pressure on the OS, and it is just best practice for any CLI filesystem-intensive loads. Arguing that this bug is external is just not taking responsibility.

My Load Test Results (Linux, 4-core / 16 GB)

https://github.com/VRDate/claude-code/tree/claude/add-tool-mutex-Qytsn/plugins/tool-mutex/tests

Previous 256-worker stress test (with vs without mutex)

| Metric | No Mutex (256 workers) | With Mutex (256 workers) |
|---|---|---|
| Completed | 7/256 (2.7%) | 256/256 (100%) |
| Peak RSS | 16,272 MB | 290 MB |
| Min free memory | 35 MB (near OOM) | 15,857 MB |
| Crashes | YES (249 timeouts) | None |

At 1024 workers without mutex, Node.js is OOM-killed (exit code 137).

Node.js load test (16 workers)

Workers:          16
Ops completed:    16/16 (100%)
Peak RSS:         1,298 MB (main)
Free memory:      16,127 MB start → 14,858 MB min → 15,857 MB end
Crashes:          None
Total time:       25.2s

Python load test (16 workers, 160 total ops)

Workers:          16
Iterations:       10
Ops completed:    160/160 (100%)
Peak RSS:         17.6 MB
Free memory:      15,196 MB start → 14,671 MB min → 14,675 MB end
Crashes:          None
Total time:       25.0s

Show that Node.js is not the best way to create a CLI tool anyway.
@anthropics/claude-code-maintainers @anthropics/claude-code-reviewers @claude
@bcherny @ant-kurt @fvolcic @ashwin-ant @bogini @chrislloyd @ThariqS @catherinewu @whyuan-cc @dhollman @rboyce-ant @dicksontsai @OctavianGuzu @hackyon-anthropic @wolffiex @igorkofman @sid374 @ddworken
@OctavianGuzu @chrislloyd @ant-kurt — requesting a direct review from one of you. Still, no one is assigned to review https://github.com/anthropics/claude-code/pull/35710.

Token bucket rate limiter — improved workaround for multi-session use

Building on @VRDate's excellent root cause analysis and PR #35710, we've published an improved workaround that fixes a failure mode we hit with the counting semaphore approach.

Repo: https://github.com/the0riginalgandalf/claude-wof-mitigation**