Repository navigation
[BUG] claude.exe triggers Windows BSOD via Wof.sys during directory listing (NtQueryDirectoryFileEx) #32870
Description
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?
claude.exe (Claude Code CLI) triggers a Windows kernel BSOD (Blue Screen of Death) by performing heavy NtQueryDirectoryFileEx syscalls (standard directory listing). The crash occurs in Wof.sys (Windows Overlay Filter) at WofPreDirectoryControlCallback+0x695 — a CFG (Control Flow Guard) indirect-call guard violation.
This is not an external Windows kernel bug in Wof.sys, but a Claude Code bug, due to Claude Code's intensive directory scanning, no delay in the same instant makes it a reliable trigger. Filing here so Anthropic is aware that Claude Code can crash Windows systems with this specific Wof.sys version, as well as wsl hypervisor.
Crash Statistics (all triggered by claude.exe)
| Date | BSODs | Bugcheck codes |
|---|---|---|
| 2026-03-06 | 7 | 0x139, 0x3B, 0x50, 0x10E, 0x1E, 0x14F |
| 2026-03-09 | 1 | 0x139 |
| 2026-03-10 | 5 | 0x139 (x2), 0x3B (x2), 0x1E (x1) |
| 2026-03-11 | 1 | 0x50 |
| Total | 14 | 4 distinct types at same Wof.sys +0x695 offset |
All March 9-11 crashes have identical call stack:
NtQueryDirectoryFileEx → FLTMGR → Wof!WofPreDirectoryControlCallback+0x695 → CFG guard violation
4 manifestations of the same bug — the corrupted indirect call target lands in different memory regions:
- 0x139 — CFG guard catches invalid target before execution
- 0x3B (
c0000005) — pointer escapes CFG, hits unmapped memory → access violation - 0x1E (
c0000005) — same access violation via different exception path - 0x3B (
c000001d) — pointer lands on non-code bytes → illegal instruction - 0x50 — pointer references invalid page in nonpaged pool
Affected Configuration
- Wof.sys: 10.0.26100.5074 (ships with Windows 11 25H2 build 26200)
- Compact OS: Enabled increases crash frequency, but crashes also occur with CompactOS disabled
- WOF minifilter: Attached at altitude 40700, intercepts every NTFS directory IRP
Microsoft Bug Report
Filed on Microsoft Q&A: https://learn.microsoft.com/en-us/answers/questions/5814272/wof-sys-bsod-0x139-kernel-security-check-failure-i
Potential Mitigation
Could Claude Code reduce the frequency/intensity of NtQueryDirectoryFileEx calls, or batch directory listings differently? This wouldn't fix the kernel bug, but might reduce the trigger rate on affected systems.
What Should Happen?
Claude Code should be able to perform directory listings without triggering a Windows BSOD. On systems with Wof.sys 10.0.26100.5074, the high volume of NtQueryDirectoryFileEx calls from claude.exe reliably crashes the kernel.
Ideally:
- Claude Code could throttle or batch directory enumeration on Windows to reduce the frequency of
NtQueryDirectoryFileExcalls - Or detect the vulnerable Wof.sys version and warn the user to disable Compact OS (
compact /CompactOS:never)
Error Messages/Logs
WinDbg !analyze -v output (abbreviated):
KERNEL_SECURITY_CHECK_FAILURE (139)
Arg1: 000000000000000a — indirect call guard check detected invalid control transfer
FAILURE_BUCKET_ID: 0x139_a_GUARD_ICALL_CHECK_FAILURE_Wof!WofPreDirectoryControlCallback+0x695
FAILURE_ID_HASH: {78ac0991-5393-0281-b23b-ce115373dc6d}
STACK_TEXT:
nt!KeBugCheckEx
nt!guard_icall_handler+0x1e
nt!KscpCfgDispatchUserCallTargetEsSmep+0x11
Ntfs!FindNextIndexEntry2+0x675
Ntfs!NtfsContinueIndexEnumeration+0x10e
Ntfs!NtfsQueryDirectory+0xd32
FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x3fe
FLTMGR!FltPerformSynchronousIo+0x443
Wof!WofPreDirectoryControlCallback+0x695 <-- CRASH
FLTMGR!FltpPerformPreCallbacksWorker+0x58f
nt!NtQueryDirectoryFileEx+0xd8
PROCESS_NAME: claude.exe
MODULE_NAME: Wof
IMAGE_VERSION: 10.0.26100.5074
Second manifestation (0x3B at the same offset):
SYSTEM_SERVICE_EXCEPTION (3b)
ExceptionCode: c0000005 (ACCESS_VIOLATION)
FAILURE_BUCKET_ID: AV_Wof!WofPreDirectoryControlCallback+0x695
FAILURE_ID_HASH: {3ae300a6-24ac-569b-3ce2-789a00065d56}Steps to Reproduce
- Run Windows 11 25H2 (build 26200) with Wof.sys 10.0.26100.5074
- Optionally enable Compact OS:
compact /CompactOS:always(increases frequency but not required) - Run
claudein a large directory (e.g., a monorepo with many files/subdirectories) - Claude Code performs intensive directory listings via
NtQueryDirectoryFileEx - System BSODs with bugcheck 0x139 (KERNEL_SECURITY_CHECK_FAILURE) or 0x3B (SYSTEM_SERVICE_EXCEPTION)
Workaround: compact /CompactOS:never reduces frequency but does not eliminate the bug.
Environment:
- Windows 11 25H2 Build 26200.7922
- 192GB RAM, 32 cores, NVIDIA RTX 5000 Ada
- 3.8 TB disk
- Monorepo with ~100K files across nested directories
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
No response
Claude Code Version
2.1.72 (Claude Code)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
Minidumps & Diagnostics
Two ZIP archives with all kernel minidumps and diagnostic outputs:
- Original ZIP (Mar 9 dump) — 1x
.dmpfrom 03-09 - New ZIP (Mar 10-11 dumps) — 5x
.dmpfiles from 03-10 and 03-11
Contents: 6x .dmp files total, WinDbg analysis, system info, event logs, driver list, triage output.
Hardware Tests Performed (all clean)
- Windows Memory Diagnostic: PASSED
- Disk scan: No corruption
- SFC /scannow: No integrity violations
- DISM /RestoreHealth: Clean
- In-place upgrade, repair install from ISO: Completed (replaced all files except Wof.sys)
Why This Is a Wof.sys Bug, Not Hardware
14 crashes at the exact same instruction (WofPreDirectoryControlCallback+0x695) across 6 days, producing 4 different exception types (0x139, 0x3B, 0x1E, 0x50) at the same offset. Random memory corruption wouldn't hit the same instruction deterministically. The 4 different bugcheck codes are expected — the corrupted indirect call target lands in different memory regions each time, producing different CPU exceptions.
Activity
VRDate commentedon Mar 10, 2026
Related: #30137 reports the same BSODs (0x139, 0x1E, 0x50) on Windows 11 build 26200 — 5 BSODs in 2 days. Another user in that thread reports 15 BSODs in one day. Same root cause: Wof.sys CFG guard bug triggered by claude.exe directory enumeration.
VRDate commentedon Mar 10, 2026
Related Issues (for context)
Claude Code has a pattern of causing OS-level crashes across platforms. The Wof.sys BSOD is a separate kernel driver bug, but these show the broader stability picture:
Same Wof.sys BSOD (kernel-mode, fix owner: Microsoft):
Separate Bun/memory issues (user-mode, fix owner: Anthropic/Oven):
switch on corrupt valuepanics on Windows (Bun 1.3.10)Important distinction: #30137 attributes BSODs to "Bun memory corruption propagating to kernel" — this is incorrect. User-mode memory corruption cannot cause a CFG guard failure (
GUARD_ICALL_CHECK_FAILURE) inWof.sys. CFG checks are compile-time integrity validations in the driver binary. The Wof.sys bug and the Bun memory bugs are two independent problems that Claude Code happens to trigger simultaneously through heavy directory enumeration and Node.js/Bun runtime usage respectively.VRDate commentedon Mar 11, 2026
Update: 14 BSODs, 4th bugcheck type (0x50)
New crash — 2026-03-11 04:18 UTC:
0x00000050PAGE_FAULT_IN_NONPAGED_AREA0xffffbb0e0760f040, 0x2, 0xfffff8040d352e58, 0x2031126-30703-01.dmpRunning total: 7 (Mar 6) + 1 (Mar 9) + 5 (Mar 10) + 1 (Mar 11) = 14 BSODs in 6 days.
4th bugcheck type: 0x50 joins 0x139, 0x3B, 0x1E. All are different manifestations of the same Wof.sys +0x695 indirect call corruption — the invalid pointer lands in different memory regions producing different exceptions:
Wof.sys: Still
10.0.26100.1— no Microsoft patch. CompactOS remains disabled. WOF minifilter still attached (cannot safely detach).Trigger:
claude.exedirectory enumeration →NtQueryDirectoryFileEx→ FLTMGR →Wof!WofPreDirectoryControlCallback+0x695.Updated dump ZIP shared on MS Q&A #5814272.
VRDate commentedon Mar 11, 2026
Update: 16 BSODs — corruption spreading to other kernel modules
3 new BSODs today (2026-03-11), with a significant change: two of the three crashes are NO LONGER in Wof.sys.
0x50PAGE_FAULT+0x695(same known bug)AV_Wof!WofPreDirectoryControlCallback0x1EKMODE_EXCEPTNtfsContinueIndexEnumeration+0x14AV_Ntfs!NtfsContinueIndexEnumeration0x3BSYS_SVC_EXCEPT+0x876dAV_nllNetHub!unknown_functionRunning total: 7 (Mar 6) + 1 (Mar 9) + 5 (Mar 10) + 3 (Mar 11) = 16 BSODs in 6 days.
Escalation: Kernel memory corruption spreading
Previously all 13 crashes blamed
Wof.sys +0x695. Today, only 1 of 3 is Wof.sys — the other two are:Ntfs.sys —
NtfsContinueIndexEnumeration+0x14is apush r15instruction that caused a General Protection Fault. A #GP onpush r15means the stack pointer (RSP) was corrupted. This is still in the directory enumeration path (downstream from WOF's minifilter callback).nllNetHub.sys — Norton LifeLock network hub driver, in
afwServ.exe(Norton Application Firewall). Unrelated to filesystem — suggests kernel pool corruption spreading beyond the directory enumeration path.Theory: Wof.sys corruption at
+0x695is poisoning kernel pool/stack memory. When the corrupted pointer lands in WOF's own code, WinDbg blames Wof.sys. When it lands in NTFS or Norton memory, those modules crash instead. The Ntfs.sys crash (stack corruption in directory enumeration) strongly supports this — WOF's minifilter runs before NTFS in the filter chain, and could corrupt NTFS's stack frame.System state
10.0.26100.1(unchanged, no Microsoft patch)32.0.15.9571(unchanged)This is no longer just a WOF code defect — the corruption is destabilizing other kernel components. The system is becoming less stable over time, not more.
Related: #30137, MS Q&A #5814272
VRDate commentedon Mar 11, 2026
Control test: TreeSize Free scanned entire 3.8TB SSD — zero BSODs
To isolate whether the crash trigger is any directory enumeration or specifically Claude Code's parallel pattern, I ran TreeSize Free 4.8.1 as a control test:
NtQueryDirectoryFileExthrough the sameFLTMGR → Wof.sysminifilter chain)This proves:
The bug is a concurrency defect in
Wof!WofPreDirectoryControlCallback— the callback's indirect call dispatch at+0x695is not thread-safe under high-concurrency minifilter re-entrancy. Single-threaded callers (TreeSize,dir /s) never hit the race condition.This also explains why "millions of Windows users" don't see this — most tools don't generate this level of concurrent directory enumeration through the minifilter stack.
VRDate commentedon Mar 11, 2026
Progress sync — all vendors now engaged
Actions taken today (2026-03-11)
Diagnostics:
Bug reports filed/updated across 4 platforms:
Key evidence posted today:
push r15) = WOF corrupting downstream modulesWaiting on:
VRDate commentedon Mar 11, 2026
Feedback Hub report filed
Microsoft's community advisor (David-M) confirmed this is a core driver defect and recommended filing via Feedback Hub for direct escalation to Microsoft engineers.
Feedback Hub link: https://aka.ms/AA106t77
Please upvote if you're experiencing Wof.sys BSODs during Claude Code sessions. Higher engagement = higher priority for Microsoft's kernel team.
Current status: 17 BSODs in 7 days (2026-03-06 through 2026-03-12). Wof.sys 10.0.26100.1 still unpatched. CompactOS OFF, still crashing. 3 faulting kernel modules (Wof.sys, Ntfs.sys, Norton nllNetHub.sys).
VRDate commentedon Mar 13, 2026
BSOD #20 — 2026-03-14 00:19
Another crash overnight. Same identical bug:
Bugcheck:
0x139KERNEL_SECURITY_CHECK_FAILUREBucket:
0x139_a_GUARD_ICALL_CHECK_FAILURE_Wof!WofPreDirectoryControlCallbackHash:
{78ac0991-5393-0281-b23b-ce115373dc6d}Process:
claude.exeStack:
System state:
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.
VRDate commentedon 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 callNtQueryDirectoryFileEx, 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.5074atWofPreDirectoryControlCallback+0x695Trigger: 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 rapidNtQueryDirectoryFileExcalls 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).
Create the wrapper
Create
claude.cmdin the same directory asclaude.exe(typically%USERPROFILE%\.local\bin\):On Windows,
.cmdtakes priority over.exein the same directory. Everyclaudeinvocation from cmd.exe, PowerShell, or Windows Terminal now goes through WSL automatically.How it works
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:
Claude will fall back to
claude.exe(Windows native).What doesn't work
compact /compactos:never)Affected versions
Timeline
VRDate commentedon Mar 14, 2026
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.syscannot 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:
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:
Setup (2 minutes):
Install JBang (one-line install, runs on any Java), then:
{ "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
Files (all in the gist)
https://gist.github.com/VRDate/862268b57dd197b8775f893a7be1e548
Mutex.jbang.ktmutex-acquire.shTestMutex.jbang.ktgen-repro-data.shclaude-bsod-workaround.mdVRDate commentedon Mar 14, 2026
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
21 remaining items
KZelab commentedon Jul 18, 2026
Just started getting this on my Alienware m18 R2 laptop (I9-14900HX)
JohannOosthuizen commentedon Jul 21, 2026
Confirming this on a second, unrelated machine four months later — same
FAILURE_ID_HASH, sameWof!WofPreDirectoryControlCallback+0x695offset — but on Wof.sys 10.0.26100.8875 / build 26200.8894 rather than the 10.0.26100.5074 / 26200.7922 in the original report. The defect survived at least one servicing cycle, so "wait for a Windows update" is not currently a viable mitigation. Two further data points below: a non-Claude-Code enumerator hitting the same path, and a quantified measure of how much the Compact OS workaround actually buys.Environment
Hyper-V root enlightenment active. Wof.sys is attached as a boot-start minifilter at altitude 40700, same as reported. Ntfs.sys and Wof.sys are both dated 2026-07-14 (July cumulative update).
Crash signature — identical
Two buckets observed across seven crashes (six minidumps retained):
Both hashes match this issue exactly. Both resolve to
SYMBOL_NAME: Wof!WofPreDirectoryControlCallback+695— the same +0x695 offset. Six 0x139 and one 0x3B.Trap frame (0x139)
A prior crash showed
r11=fbffff64b5ac4458. Both targets are non-canonical, and both carry a0xfbhigh byte where a valid kernel pointer would have0xff— i.e. the same single-byte-off pattern in the high half of the pointer, not arbitrary garbage.Full stack (0x139) — matches the issue with the intermediate FLTMGR frames filled in
0x3B variant
Identical stack from
Wof!WofPreDirectoryControlCallback+0x695downward.ExceptionCode c0000005; rip lands atNtfs!NtfsContinueIndexEnumeration+0withrbp=4080000040000003. This is the same "pointer escapes CFG and is executed" manifestation described in the issue's four-manifestations section, just reached from a slightly different frame.New data point 1 — the defect survived a servicing cycle
The original report is against Wof.sys 10.0.26100.5074 on build 26200.7922 (March 2026). This system is on Wof.sys 10.0.26100.8875, build 26200.8894 (July 2026) — several driver revisions later. Same symbol, same +0x695, same two failure hashes.
Observed fact: the bug is present on both driver builds. Practical consequence for the issue's "Proposed Mitigations" section: detecting a "vulnerable Wof.sys version" cannot currently be done by pinning a single known-bad version — both the March and July drivers reproduce it.
New data point 2 — a second, non-Claude-Code enumerator reaches the same defect
This is the part most relevant to PR #35710's scope.
On the two most recent crashes the faulting process is
dartvm.exe— the Dart/Flutter MCP language server, which runs a persistent recursive filesystem watcher. This machine was running Claude Code and the Dart MCP server concurrently against a Flutter project.Note also the 11:53 crash attributed to
SystemSettings— an ordinary shell process doing a directory listing was enough to be the one holding the IRP when the driver faulted.Observed fact: the crashing thread is not always Claude Code's. Reading (inference): the defect is in the shared
Wof.sysdirectory-control path and is reachable by any sufficiently concurrent directory-enumeration workload on the volume. The process named in the dump is whichever caller happened to be insideNtQueryDirectoryFileExat the moment, not necessarily the one that created the concurrency.New data point 3 — quantified effect of the Compact OS workaround
compact /CompactOs:neverwas applied mid-day, between the 11:53 and 13:34 crashes.Mean uptime went from ~17.5 min to ~132.5 min — roughly a 7.6x improvement — but crashes continued. Small sample: two observations either side. This confirms the issue's characterization of the workaround as partial and puts a number on it. Mechanically (inference): decompressing OS binaries removes most of Wof's decompression work, but it does not detach the minifilter from the directory-control path, so the faulting callback still runs on every directory enumeration.
Onset correlation — flagged as inference, not proof
Sequence on this machine:
No 0x139 bugchecks appear anywhere in ~3 months of retained event logs prior to 2026-07-16.
The 2026-07-14 driver replacement initially looked causal because it lands two days before the first crash. I do not think it is: the same defect is documented in this issue against a March 2026 driver, so the July update is most likely coincidental. The more probable reading is that the change on this machine was the introduction of a second concurrent enumerating tool, which pushed a pre-existing latent defect above its trigger threshold. Stated explicitly as inference — I cannot separate the two changes from the evidence I have.
Ruled out
0xfbhigh byte), so CFG is catching a real bad transfer, not misfiring.Open question for maintainers
PR #35710's semaphore covers Claude Code's own Glob / Grep / Read / Bash invocations. Based on the evidence above, the concurrency that trips this defect is volume-wide, not process-wide: a file-watching MCP language server enumerating in its own process is outside that semaphore and was the faulting process on two of the seven crashes here.
Is the tool-mutex approach intended to be scoped only to Claude Code's in-process filesystem tools, or is there a path to covering the MCP-server case — e.g. a machine-wide rather than session-wide semaphore, or guidance that the mutex alone is insufficient when other file-watching tooling runs alongside Claude Code? A fix scoped to Claude Code's own tools would have reduced but, on this machine, probably not eliminated the crashes.
Happy to provide additional
!analyze -voutput or dump detail if useful.JohannOosthuizen commentedon Jul 22, 2026
Workaround: serializing filesystem tool calls with hooks (no code changes, installable today)
Following up on my earlier data — since PR #35710's tool mutex isn't merged, I built the same idea out of the existing hooks system: a
PreToolUse/PostToolUsepair that serializes all of Claude Code's filesystem tool calls through amkdir-based lock. Posting it here since it's working on the machine described above and others hitting this can install it today.Result so far: the machine went from nine
Wof.sysbugchecks in three days (seven of them in one afternoon, longest-ever uptime 2 h 43 m) to 21+ hours crash-free with the hook active during normal Claude Code + MCP-server workloads. Single machine, single day — treat it as a strong signal, not proof.How it works
Three hook registrations in
settings.json:PreToolUseBash|Read|Glob|Grep|Edit|WritePostToolUsePostToolUseFailureThe
PostToolUseFailureregistration matters: Claude Code fires a separate event when a tool call fails, so without it one failed call strands the lock.Design properties, all deliberate:
mkdiras the atomic primitive — atomic on NTFS, no race between test and create, no dependencies.$HOME/.claude/wof-mutex.lock, so concurrent sessions/subagents on the same machine serialize against each other too — which is what you want, since the Wof.sys race is volume-wide.Install
~/.claude/wof-mutex-acquire.sh:~/.claude/wof-mutex-release.sh:Merge into
~/.claude/settings.json(alongside your existing keys):Notes:
"shell": "bash"runs the scripts under Git Bash, which ships with Git for Windows (a Claude Code prerequisite on Windows).stat -c %Yis GNU-stat syntax — fine there. The bug is Windows-only, so no portability effort was made.jqor other dependencies — plain POSIX sh plus GNU stat.Performance impact — measured
This is not free. Numbers from the machine above (i9-14900HX, NVMe):
How that ~118 ms lands in practice:
shlaunches per tool call — not lock contention. It's a flat per-call tax.Readroughly triples in wall-clock).If the tax bothers you, the matcher can be narrowed to
Glob|Grep|Bash— the directory-enumerating tools — leavingRead/Edit/Write(single-file operations) at full speed. I haven't tested whether the narrow matcher still suppresses the crashes, so I'm running the broad one until I have more uptime data. Single-file ops appearing in crash-time concurrency can't be ruled out from my dumps.What this does not protect against
Being explicit, because this is a mitigation, not a fix:
Grepinvocation runs ripgrep, which walks directories multi-threaded internally. The hook serializes calls, not the parallelism within one.Wof.sys; it's not a reason to close the issue.Given (1) and (2), I'd have predicted a reduction rather than the clean 21 h I'm seeing — possibly the removed concurrency drops total trigger pressure below threshold even though other enumerators remain. More uptime data will tell.
Happy to report back with longer-term numbers or the narrow-matcher experiment.
lexliller commentedon Jul 25, 2026
Adding another independent machine with the identical failure bucket, on a newer Wof.sys than previously reported (10.0.26100.8875 vs 10.0.26100.5074) — so the July 2026 cumulative (KB5101650) restamped the binary without fixing the bug.
Machine: Alienware m18 R2, Windows 11 24H2 build 26100.8894, Wof.sys 10.0.26100.8875
Crashes: 5 between 2026-07-16 and 2026-07-25, all the same bucket. Crashing process was
python.exein earlier dumps andclaude.exein the latest (2026-07-25), both doing directory enumeration.!analyze -vfrom the 2026-07-25 minidump:The faulting CFG dispatch dereferences a non-canonical
fbff....address in r11 (fbff8b8fec5fe370in this dump,fbffa6be65bac5a0in the 7/23 one — same corruption shape, different values, different processes), consistent with a garbage callback target fed into the CFG bitmap computation rather than random hardware corruption.Corroborating observations matching this thread:
compact /compactos:query→ "not in the Compact state"), so the bug does not require CompactOS — WOF's pre-directory-control callback fires regardless.dxdum commentedon Jul 26, 2026
Independent reproduction on different hardware, plus the concrete corrupted field in NTFS
Hit this twice today on a different machine than the original report. Signature matches byte for byte. Adding the piece that I could not find in this thread or in the MS Q&A: the exact NTFS structure field that gets clobbered, which pins down the Wof -> NTFS corruption path rather than inferring it.
System
Two bugchecks 40 minutes apart, both
0x139arg1=0xa(GUARD_ICALL_CHECK_FAILURE), bothNtfs!FindNextIndexEntry2+0x675, in two different processes enumerating two different directories:Different directories, same volume, same code path. That rules out on-disk index corruption in one directory (chkdsk is a dead end here) and points at corrupted in-memory volume state.
Root cause, concretely
NTFS selects its name comparison routine through an index into a function pointer table inside the Ntfs.sys image:
The table has exactly four entries:
Read from the kernel dump at crash time:
The low 16 bits still hold the correct value
1(file name index). Bits 16-31 have been overwritten with6. So the index becomes0x60001, the lookup landsNtfs_base + 0x35E7E0, still inside the image, reads zero, and NTFS calls address 0. Kernel CFG catches the invalid indirect transfer and bugchecks. Verified in the debugger:That is a 2-byte-offset partial overwrite of a live NTFS VCB field, not a bit flip and not a wild pointer. Once that qword is corrupted, the next wildcard directory enumeration anywhere on the volume detonates. That is why the crashing process is always a short-lived one that happens to enumerate a directory early in its life (a starting python or pwsh scanning module paths). The victim process is unrelated to the culprit.
My two stacks show the plain top-level path with the Wof pre-callback already returned:
This is the downstream NTFS-victim variant described in the MS Q&A thread, and the corrupted VCB field is the missing link between the two.
Hardware ruled out
Worth stating because this bugcheck usually gets blamed on RAM or CPU, and this box runs an i9-14900HX with an aggressive turbo policy, which is the obvious false suspect:
6, and the low half of the field is intact. Bit flips do not do that.Trigger correlation
Crash 1 landed 14 minutes into a Defender scheduled Quick Scan while agent work was running (CPU 61% avg in that window). Consistent with the concurrency theory in this thread: it needs overlapping directory enumerations, and a background scanner plus parallel agent tool calls is exactly that.
Status
Wof.sys shipped in the July 2026 CU still carries the defect. Compact OS being off does not prevent it, confirming the earlier finding in this thread.
For anyone triaging their own dumps, the fast check is
!analyze -vgiving0x139_a_GUARD_ICALL_CHECK_FAILUREwithNtfs!FindNextIndexEntry2+0x675, then reading[Vcb+0x2B0]: anything other than a small integer 0-3 is this bug.JohannOosthuizen commentedon Jul 26, 2026
Further work-around currently under way as follows by updating the projects claude.md, unfortunately the cost is avoiding sub-agent delegation.
Wof.sys BSOD avoidance (Windows — do not remove)
This machine has a kernel-driver defect (Wof.sys) that bugchecks under concurrent
NTFS directory enumeration. To minimize Claude Code's own contribution:
sweep/find across the codebase"). Do targeted, path-specific lookups yourself.
flutter,dart,npm,recursive grep/find) while any other filesystem work is in flight. Do them
strictly one at a time, and say so before starting.
**/*globs, nols -R, nogrep -r.Prefer a known path + single-file Read. If a search is unavoidable,
rg --threads 1.ELBALAZO94 commentedon Jul 27, 2026
Adjacent data point, and one correction to how the stack in this report is being attributed. I want to be explicit up front: I am not claiming to reproduce the signature in this issue. My dumps do not contain
Wofframes, so my case is probably a different failure with the same architectural shape. I am posting it because two of its properties are directly relevant to the triage here.1.
Wof!...+0x695is a return address, not the faulting instructionWinDbg prints frames callee-first. Re-reading the stack in the original report:
The invalid indirect-call target is dispatched inside
Ntfs!FindNextIndexEntry2+0x675.Wof!WofPreDirectoryControlCallback+0x695is the site from which WOF issues a re-entrant synchronous directory enumeration through FLTMGR. WOF is therefore on the triggering path, but this excerpt does not establish that the defective instruction is insideWof.sys— theFAILURE_BUCKET_IDnames WOF because it is the owning minifilter frame.Consequences for triage:
Wof.sys: NTFS directory-index enumeration, the context passed through the nested I/O request, persistent on-volume index/reparse-point state, and any other minifilter that hooksIRP_MJ_DIRECTORY_CONTROLon reparse-point-backed files.That last item is where my case lands.
2. What my case actually shows — and what it does not
Eight analyzed kernel minidumps, 16–23 July 2026, Windows 11 25H2 build
26200.8894. Two properties matter:(a) The crashing user-mode process varied.
claude.exe,git.exe,powershell.exe,OneDrive.exe. One crash occurred immediately after importing a skill ZIP via Claude Desktop, withgit.exeas the active process. Claude Code was not a necessary condition on my machine. I am stating that plainly because it is evidence against attributing my BSODs to Claude Code, and anyone reading this thread should weight my report accordingly.(b) No
Wofframes; recurringNtfs.sys+FLTMGR.SYS.compact /CompactOS:queryreported the system was not in a Compact state before the reinstall, so the WOF amplifier documented in this issue was absent on my machine. What I did have attached toC:wasCldFlt(OneDrive cloud-files placeholder filter) — architecturally the same pattern as WOF: a minifilter that intercepts directory control on files backed by reparse points, and that can issue nested I/O to hydrate or fix up metadata.OneDrive.exeappearing as the active process in one dump is consistent with that path being involved, though I have not symbolized the dumps far enough to prove it.So the useful reading of my data is not "WOF confirmed" but: the same nested-enumeration architecture exists for more than one Microsoft minifilter, and a broad recursive glob is enough to load it heavily. My reproduction trigger was a single broad pattern allowed outside the active workspace:
3. Format vs. in-place — the one contrast worth testing
Recurring offsets in the analyzed dumps (see version caveat above):
Diagnostics completed before the reinstall, all clean: HP extended memory test (45 iterations, 6 h 24 min, zero errors); processor diagnostics passed;
DISM /Online /Cleanup-Image /RestoreHealth;sfc /scannow;chkdsk C: /scan(online scan only — see §3); SSD SMART withCritical Warning = 0,Media and Data Integrity Errors = 0,Error Information Log Entries = 0,Available Spare = 100%,Percentage Used = 6%. All observed minifilters were Microsoft-signed, which narrows but does not exclude filter involvement.Dumps retained in backup:
I still have all eight pre-reinstall minidumps and can provide them privately, along with WinDbg output, Event Viewer exports, SMART data and
`/`fltmcoutput. Given §2(a), the most valuable thing in them is probably the non-Claude crashes: ifgit.exeandOneDrive.exereach the same NTFS/FLTMGR path, that is a datum this thread does not currently have.LeitchP commentedon Jul 28, 2026
Additional data: reproduced with Wof.sys disabled and with zero third-party filesystem filters loaded. Register state matches @dxdum's corrupted-Vcb mechanism exactly.
I have included a replication test at the end which caused the problem within 20 minutes or so every time I ran it.
Alienware m18 R2 (third in this thread), i9-14900HX, Windows 11 24H2 build 26100.8875. 19 minidumps decoded, all one signature: 0x139 P1=0xA in NTFS directory enumeration, stack offsets matching those reported above (Ntfs +0x115AC5 / +0x1157BB / +0x11517E / +0x2684F2, FLTMGR +0xC70E). Trap-context registers in all 19 dumps: RAX=0, R10=0, R11=0xFBFF... — i.e. a null call target from the over-indexed comparison-routine table, consistent with the [Vcb+0x2B0] corruption @dxdum documented. (The page-aligned RCX values are the enumeration buffer argument.)
Elimination sequence, each step verified by reproduction afterwards:
So on this machine the failure needs no Wof and no third-party filter; whichever filter is in-frame is a bystander to the shared NTFS path. Reproduction without claude.exe: looping
compact /q /sfull-drive walks alongside normal background activity bugchecks it in 10 to 20 minutes.Timeline matches @rzinnatullin and @Andre-Erasmus: KB5101650 installed 17 Jul, daily crashes from 19 Jul (sporadic same-machine BSODs since late March predate it). Crash frequency also tracks Claude Code usage intensity, consistent with concurrent Glob/Grep enumeration as the dominant trigger; CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY=1 reduces exposure only.
Test Script
Same workload (script below), 3 controlled runs:
Roughly 6x the longest pre-rollback survival with zero faults, on the identical trigger. Note the scope: this resolves the daily-crash regression introduced with the July servicing; the sporadic pre-July crashes on this machine (~fortnightly since late March) imply the latent defect predates KB5101650, so the rollback is a mitigation, not proof the older binaries are clean. Will retest on the August cumulative and report.
geoffschaeffer commentedon Jul 29, 2026
Adding a fourth i9-14900HX data point, and confirming the register signature described above on two independent dumps.
System: Acer laptop, Intel Core i9-14900HX (32 logical processors), Windows 11 24H2 build 26100, Wof.sys 10.0.26100.8875 (i.e. post-KB5101650).
Crashes: two, 17 minutes apart, both while Claude Code ran directory enumeration over a Unity project (large
Library/tree). Processfind.exeviaNtQueryDirectoryFile. No crashes on this machine before this.Register signature — matches the corrupted-Vcb mechanism on both dumps
WinDbg analyzed only the second dump, so I extracted the
KTRAP_FRAMEfrom the first one manually (located at stack+0x1098in both; field offsets calibrated against the known-good WinDbg values from dump 2).Null call target,
0xFBFF...guard-bitmap address, page-aligned RCX — consistent with the[Vcb+0x2B0]over-indexed comparison-routine table described above.Faulting instruction in both:
Stack offsets
Present in both dumps:
Ntfs +0x115AC5,Ntfs +0x11517E,Ntfs +0x2684F2,FLTMGR +0xC70E.Ntfs +0x1157BBappears in crash 1; crash 2 hasNtfs +0x1148E1at the same stack slot.I compared the two dumps frame-by-frame by module+offset (ASLR-independent): identical at the same stack offsets from
+0x0810through+0x1b80, 67 frames in common. Deterministic path.Corroborating the "filter in frame is a bystander" finding
My dumps independently support this from the other direction. Crash 1 contained a single Norton driver address (
nllbidsdriver.sys+0x58df8) on the stack, which initially looked like a lead. Crash 2 contained no third-party driver frames at all — and the Norton address in crash 1 sat at stack offset+0x0b38, inside the region where the two stacks diverge, i.e. stale stack data rather than a live frame. A pointer census across the whole dump confirmed it: every loaded driver has a baseline of 3 self-references from its own entry in the driver table, andnllbidsdriver.syshad exactly 4 — the one stale stack slot.WinDbg bucketed my crash 2 as
0x139_a_GUARD_ICALL_CHECK_FAILURE_Wof!WofPreDirectoryControlCallback(BUCKET_ID_FUNC_OFFSET: 695), but given the report above that the crash reproduces with Wof.sys disabled entirely, that attribution looks like the same bystander effect —Wof!WofPreDirectoryControlCallback+0x695is simply the frame that issued the synchronous directory query viaFltPerformSynchronousIobefore control reached the shared NTFS path.Other notes
chkdsk C: /scanclean (1.16M file records, 28,274 reparse points, no problems).FAILURE_ID_HASH: {78ac0991-5393-0281-b23b-ce115373dc6d}Happy to attach both minidumps if useful.
isnowx17 commentedon Aug 2, 2026
Additional reproduction after KB5101650 — three identical BSODs through Claude Code UI
I am experiencing the same
Wof.sysdirectory-enumeration crash described in this issue.Environment
26200.8875KB5101650sfc /scannow: no integrity violations foundRegression timing
Claude Code previously worked on this same computer without causing BSODs.
The crashes began after
KB5101650was installed. This does not prove that the Windows update is the root cause, but the timing may be relevant because all three crashes after the update fail in the same WOF directory-control path.Reproduction pattern
I have stopped intentionally reproducing it because it has already caused multiple kernel crashes.
Crash information
I experienced three recent BSODs:
All three generated the same bugcheck and arguments:
The diagnostic information consistently points to:
The filesystem path includes:
Processes recorded as active during the crashes:
The system remains stable when Claude Code is not running.
Possible mitigation request
Could Claude Code reduce or serialize concurrent directory-enumeration operations on affected Windows systems?
Potential mitigations could include:
NtQueryDirectoryFileExoperations;Wof.sysversions and warning the user.I have the following diagnostics available:
msinfo32system information;fltmcfilesystem-filter lists.I am not uploading the complete diagnostic archive publicly because dumps and event logs may contain usernames and local file paths, but I can provide specific sanitized sections if requested.
LeitchP commentedon Aug 3, 2026
@emelmusti83-sys Your report slots cleanly into the pattern established above, including the bugcheck difference. 0x1E with 0xC0000005 is one of the 4 documented manifestations of this same defect (0x139 / 0x3B / 0x1E / 0x50, per the original report): the corrupted call target sometimes gets caught by CFG (0x139) and sometimes escapes into an access violation (your 0x1E). Same path, same
Wof!WofPreDirectoryControlCallbackbucket, and per the elimination testing earlier in this thread, the Wof frame is a bystander to a shared NTFS enumeration defect. Your onset timing after KB5101650 matches @rzinnatullin, @Andre-Erasmus and my machine (installed 17 Jul, daily crashes from 19 Jul). Your active-process spread (powershell.exe, dotnet.exe) also fits: once the volume structure is poisoned, whichever process enumerates next takes the crash.Two things you can act on today.
1. Uninstall and block KB5101650. This is what stopped the daily crashes on my machine, and I verified it with a controlled reproduction rather than just waiting: the identical workload that bugchecked in 10-21 minutes on 26100.8875 ran 24 laps / 66 minutes clean after the rollback (Wof.sys reverted to 10.0.26100.1). Procedure, learned the hard way because the update reinstalled itself on my first attempt:
After the reboot, immediately close the roads back, in this order:
Notes from my attempt: do not rely on
Hide-WindowsUpdatealone (it hangs while updates are paused, and a name-based hide is useless against the August cumulative, which will carry the same binaries under a new KB number if unfixed). The pause plus AUOptions=2 covers both. Verify the end state:Reverse the policy later by deleting the
AUregistry key; reinstall the update whenever a fixed build ships by resuming updates.2. Use the reproduction script in my comment above as your measurement tool. I understand not wanting to crash the machine again, so run it in whichever mode suits your risk tolerance: post-rollback only, where a 60-120 minute clean run is your evidence the rollback worked (it should not crash); or once before and once after if you want the same controlled before/after I posted. Crashes from it are ordinary bugchecks, NTFS journalling handles them, but that call is yours, especially without full backups.
On your mitigation requests: a concurrency lever already exists,
CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY=1set as a user environment variable reduces exposure (it cannot eliminate it, since other enumerators on the volume still contribute). See also the hooks-based serialisation workaround posted by @JohannOosthuizen above, and PR #35710 for the in-product fix. But on a machine crashing within 1-2 minutes of opening Claude Code, the rollback is the intervention with measured results; the throttles are for those staying on the July binaries.LeitchP commentedon Aug 6, 2026
10-day follow-up on the KB5101650 rollback: zero bugchecks
Status update on the machine from my earlier comments (Alienware m18 R2, i9-14900HX, 24H2, rolled back to Wof.sys / Ntfs.sys 10.0.26100.1 on 28 Jul):
Context for those numbers: on the KB5101650 binaries this machine was averaging ~1.3 bugchecks/day (19-28 Jul), and the controlled reproduction crashed it in 10-21 minutes on demand. At that rate, 10 silent days had odds of roughly 1 in 30,000, so the July regression is dead on this machine, not merely quieter. Notably the clean run includes daily Claude Code use in VS Code with no concurrency throttling (
CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCYremoved), no serialization hooks, and no CompactOS/Wof changes — the rollback alone.One honest caveat: this machine also had sporadic same-path crashes (~fortnightly, March-July) predating KB5101650, and 10 days cannot yet distinguish "gone" from "back to fortnightly" for that older, slower rate. The daily regression and the latent defect remain separate questions.
Plan: the August cumulative gets installed manually next week (updates are on a notify-only policy per my earlier comment), then the same reproduction script runs against it. Pass = report here and everything gets restored; fail = it comes off the same way KB5101650 did. Either result posted with lap counts.
ksx-kshan commentedon Aug 13, 2026
Windows update 9168 seems to resolve this for me, so far. Might be worth a try.
Windows 11 25H2 — NTFS/Wof directory-enumeration BSOD
BEFORE: Build 26200.8894 (KB5121767, on top of KB5101650 / 26200.8875)
AFTER: Build 26200.9168 (KB5121003, 2026-08-11 Patch Tuesday)
ntfs.sys
component: amd64_microsoft-windows-ntfs_31bf3856ad364e35 8875 -> 9168
before SHA256: B340816E8F307030247D624D746437B2CA1133664C6261DF1376B5829CB69380 (2026-07-14 23:10)
after SHA256: 24B023140A6D162DB3FE0D701109FC0BE4FDD9EC65E1C40522934AE3CC0A28C6 (2026-08-11 16:50)
Wof.sys
component: amd64_microsoft-windows-overlayfilter_31bf3856ad364e35 8875 -> 8972
before SHA256: 065980458B88B99AE0C408A83FF1E3CBD87E7A10DBACBBD83981B497C20DB34B (2026-07-14 23:10)
after SHA256: 62EA99EC3FF37B223B2624B72CBC1D0F4362A358B7E21BFE53831859C2437F4A (2026-08-11 16:50)
Note: KB5121767 (26200.8894) did NOT change either binary — it bumped the build while
carrying both forward byte-identical. KB5121003 (26200.9168) is the first update to
actually replace them.
DaltonSalvatti commentedon Aug 15, 2026
Same bug family here, but with a different faulting frame — reporting in case it helps narrow down the defect.
Over 25 days I hit 10 BSODs, all with
claude.exeasPROCESS_NAME(10/10), all during directory enumeration. My stack faults inNtfs!FindNextIndexEntry2+0x675rather thanWof!WofPreDirectoryControlCallback+0x695, but the bugcheck, mechanism and trigger match this report exactly.Crash signature
Stack (identical in every dump):
The one 0x3B had the same stack, faulting at
Ntfs!NtfsContinueIndexEnumeration+0with0xc0000005— i.e. the same corrupted indirect target manifesting as an AV instead of tripping CFG.Wof.sys is attached here too
Even though my frame is in
Ntfs, WOF is loaded and attached to C: at the altitude named in this report:Full minifilter set on C: — all Microsoft, no third-party AV or shell extensions:
bindflt, UCPD, WdFilter, gameflt, CldFlt, bfs, luafv, Wof, FileInfoCompactOS was already disabled the whole time (
compact /compactos:query→ "system is not in the Compact state"), which corroborates the note in this thread thatcompact /CompactOS:neverdoes not eliminate the crashes — WOF stays attached regardless.Affected directories — not tied to a specific path
I extracted the target directory from each kernel dump via
!thread→!irp <irp> 1→!fileobj <OriginalFileObject>.Four distinct directories across the 10 crashes:
...\dasalldp\node_modules\rxjs\internal\util...\dasalldp\node_modules\rxjs\_esm5\internal\operators...\mydevbotapp\src\images\icons\material...\mydevbotmeet\node_modulesNotes that may matter:
System.IO.Directory.GetFileSystemEntries— before and after the crashes.chkdsk /scan(repeatedly) and an offlinechkdsk /ffound no filesystem problems, and the volume was never dirty.dasalldp\node_modulesand reinstalled it from scratch (npm install); it crashed again a few days later in a different rxjs subdirectory. I restoredicons\materialclean from git; it crashed on that same path twice afterwards.Not reproducible sequentially — looks concurrency/timing dependent
I tried to reproduce on demand with ripgrep 15.0.0 against the exact directory that had just crashed the machine:
All three completed normally, three times, no crash. So a single sequential walk does not trigger it — consistent with the "dozens of concurrent directory walks" theory in this thread rather than a deterministic per-directory defect.
Hardware exhaustively ruled out
I went a long way down the hardware path before finding this issue, so I can add fairly strong negative evidence:
chkdsk /scan(multiple) + offlinechkdsk /fgit fsck --full --strict, 8 repositoriesHmbAllocationPolicy=0(HMB off)Every hardware hypothesis was falsified by a subsequent crash. This matches other reports here where "hardware checks all passed".
Environment
Wof, Boot startiaStorVD19.5.7.1058)node_modulesFrequency
10 crashes between Jul 21 and Aug 14, initially up to 2 per day, later spacing out to 6 and then 10 days apart. The spacing correlates with how much heavy scanning I was doing, not with any of the hardware changes above.
Suggestion
Adding to what was already proposed in this thread: since a single sequential
rgwalk provably does not trigger it here, throttling or serializing the concurrentNtQueryDirectoryFileExbursts on Windows looks like it would be an effective client-side mitigation while the kernel-side issue is investigated.Happy to share the kernel dumps or run any specific WinDbg commands against them if that would help.