[Bug] Windows 11: Concurrent filesystem tools trigger Wof.sys race condition (BSOD 0x139)
Bug Description
# Bug report: Claude Code's concurrent filesystem tool dispatch triggers a Windows kernel bugcheck (Wof.sys race) — nine BSODs, root-cause analysis, and a hooks-based workaround with measured cost
> One-line summary: On Windows 11, Claude Code's parallel filesystem tools (and multithreaded ripgrep) reliably trigger a pre-existing race condition in Microsoft's Windows Overlay Filter driver (Wof.sys), bugchecking the entire machine. The defect is Microsoft's, but Claude Code is one of the most effective known triggers. Serializing Claude Code's filesystem tool calls via a hooks-based mutex took this machine from nine BSODs in three days to 21+ hours crash-free.
This is a self-contained report. It consolidates and extends the data in claude-code issue #32870 (same failure hashes, four months later, newer driver) and is directly relevant to the scoping of PR #35710 (tool mutex).
---
## 1. Environment
| Component | Version |
|---|---|
| Claude Code | 2.1.217, Windows native |
| Model | Opus 4.8 (1M context) |
| OS | Windows 11 Home 25H2, build 26200.8894 |
| Wof.sys | 10.0.26100.8875 (2026-07-14, July CU) |
| ntoskrnl.exe | 10.0.26100.8894 |
| Hardware | Intel Core i9-14900HX laptop, NVMe |
| Volume | Single NTFS volume, ~3.8 TB, ~92 GB free |
| Compact OS | Enabled at onset; disabled mid-incident (see §6) |
| Concurrent tooling | Dart/Flutter MCP language server (persistent recursive file watcher) running alongside Claude Code |
Wof.sys is a boot-start minifilter at altitude 40700, attached to every NTFS volume whether or not Compact OS is active.
## 2. Impact
Full-machine kernel bugcheck (BSOD) — total loss of all unsaved work in every application, not just Claude Code. Nine crashes over three days, seven of them in a single afternoon, with mean uptime between failures dropping to ~10–25 minutes at the worst. The machine was effectively unusable for development until mitigated.
## 3. Crash record
All 2026. Times local. Faulting process is whichever thread held the IRP at the moment of the fault — see §5.
| Date | Time | Bugcheck | Faulting process | Uptime at crash |
|---|---|---|---|---|
| 07-16 | — | 0x139 | — | — (first occurrence; no dump retained) |
| 07-20 | 18:49 | 0x139 | — | — |
| 07-21 | 11:15 | 0x139 | — | 0:25 |
| 07-21 | 11:41 | 0x139 | — | 0:10 |
| 07-21 | 11:53 | 0x139 | SystemSettings | 0:10:34 |
| 07-21 | 13:34 | 0x139 | dartvm.exe | 1:41 |
| 07-21 | 16:19 | 0x3B (c0000005) | dartvm.exe | 2:43:51 |
| 07-21 | ~16:31 | 0x139 (Arg1=0xa) | — | ~0:10 |
| 07-21 | ~16:47 | 0x3B (c0000005) | — | ~0:15 |
No 0x139 bugchecks appear anywhere in ~3 months of retained event logs prior to 07-16. Eight kernel minidumps retained; six analyzed with WinDbg (!analyze -v, Microsoft public symbols), the last two matched via Event Log bugcheck parameters (identical kCFG signature; identical faulting-instruction offset module-slid by ASLR).
## 4. Crash signature
Every analyzed dump resolves to the same symbol and offset. Two Watson buckets, split only by manifestation:
``
FAILURE_BUCKET_ID: 0x139_a_GUARD_ICALL_CHECK_FAILURE_Wof!WofPreDirectoryControlCallback
FAILURE_ID_HASH: {78ac0991-5393-0281-b23b-ce115373dc6d}
FAILURE_BUCKET_ID: AV_Wof!WofPreDirectoryControlCallback
FAILURE_ID_HASH: {3ae300a6-24ac-569b-3ce2-789a00065d56}
SYMBOL_NAME: Wof!WofPreDirectoryControlCallback+695 (all dumps, both buckets)
`
Representative 0x139 stack (kCFG catches an indirect call through a corrupt pointer):
`
nt!KeBugCheckEx
nt!guard_icall_handler+0x1e
...
nt!KiGeneralProtectionFault+0x365
nt!KscpCfgDispatchUserCallTargetEsSmep+0x11
Ntfs!FindNextIndexEntry2+0x675
Ntfs!NtfsContinueIndexEnumeration+0x10e
Ntfs!NtfsQueryDirectory+0xd32
Ntfs!NtfsCommonDirectoryControl+0x2ce
Ntfs!NtfsFsdDirectoryControl+0xcb
nt!IofCallDriver+0x13
FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x3fe
FLTMGR!FltPerformSynchronousIo+0x443
Wof!WofPreDirectoryControlCallback+0x695 <-- defect
FLTMGR!FltpPerformPreCallbacksWorker+0x568
...
nt!NtQueryDirectoryFileEx+0xd8
nt!KiSystemServiceCopyEnd+0x25
`
The corrupt indirect-call targets observed (r11 = fbffe9cef691f4a0, fbffff64b5ac4458) are non-canonical with a 0xfb high byte where a valid kernel pointer has 0xff — a partially-corrupted pointer, not arbitrary garbage. The 0x3B variant is the same pointer escaping CFG and being executed (c0000005 at Ntfs!NtfsContinueIndexEnumeration).
**Ruled out:** filesystem corruption (NTFS event 98: all volumes healthy), kCFG false positive (targets genuinely non-canonical), hardware (deterministic identical offset across nine crashes, and the same signature on entirely different silicon in #32870), third-party filter drivers (clean stacks, first-party modules only).
## 5. Why this is a Claude Code issue (trigger, not defect)
The defect is a race in Wof.sys`'s directory-control pr…
Note: Content was truncated.