[BUG] Windows: Claude Code directory enumeration triggers kernel BSOD (0x139 in Ntfs!FindNextIndexEntry2) — reproducible on 2.1.216

Preflight Checklist

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

What's Wrong?

On Windows, Claude Code's directory-enumeration activity reliably triggers a Windows kernel bugcheck in the NTFS directory-enumeration path. The fault is KERNEL_SECURITY_CHECK_FAILURE (0x139), Arg1 0xA (Control Flow Guard indirect-call violation), occurring in Ntfs!FindNextIndexEntry2 / Ntfs!NtfsContinueIndexEnumeration, reached via NtQueryDirectoryFile. It also appears as 0x50 (PAGE_FAULT_IN_NONPAGED_AREA, execute) in the same functions.

The underlying fault is in the Windows NTFS enumeration path, so any concurrent directory walk can hit it. But this machine had zero bugchecks in normal use before adopting Claude Code, and reached ~10–20 crashes/day during heavy coding. Claude Code generates far more concurrent NtQueryDirectoryFile traffic than any other workload on the machine (Grep/ripgrep over repos, per-turn where.exe lookups, build-adjacent walks, parallel tool calls, and multi-agent fan-out), which turns a latent, never-seen fault into a daily failure. Crash frequency tracks how much concurrent directory enumeration Claude performs.

Confirmed triggers, all landing on the identical NTFS stack:

Multiple concurrent agents (e.g. /review fanning out) each enumerating the repo — worst-case concurrency, several parallel directory walks at once
dotnet build on a 14-project Blazor Server solution (build-internal parallel enumeration)
A single read-only Grep content search over a repo path during a code-free research session (no build, no writes)
where.exe PATH enumeration during Claude Code turn-prep, while otherwise idle
During boot, before desktop (Claude not yet running) — same signature
Once while gaming with Claude idle (background enumeration the likely cause)

Notably, the user-side mitigation route is limited: a PreToolUse throttle hook (mutex + cooldown) reduces frequency substantially but cannot eliminate crashes, because turn-prep enumeration (where.exe) and dotnet build-internal enumeration run below the tool-hook layer and are unreachable by any hook. Mitigation therefore needs to be inside Claude Code on Windows.

What Should Happen?

Claude Code on Windows should not be able to drive the host to a kernel BSOD through routine directory enumeration. Concurrent NtQueryDirectoryFile activity from Grep/Glob, internal executable lookups, build-adjacent walks, and multiple simultaneous agents should be bounded/serialised so that enumeration volume stays within what the OS handles safely, rather than issuing enough parallel directory-enumeration calls to trip the NTFS fault.

Error Messages/Logs

Bugcheck: 0x00000139 (0x000000000000000a, 0, 0, <addr>) — KERNEL_SECURITY_CHECK_FAILURE, "Indirect call guard check detected invalid control transfer."

Symbolised stack (!analyze -v), representative and consistent across dumps:

nt!KeBugCheckEx
nt!guard_icall_handler
nt!KiExceptionDispatch
nt!KscpCfgDispatchUserCallTargetEsSmep
Ntfs!FindNextIndexEntry2+0x675
Ntfs!NtfsContinueIndexEnumeration
Ntfs!NtfsQueryDirectory
Ntfs!NtfsFsdDirectoryControl
nt!NtQueryDirectoryFile
FAILURE_BUCKET_ID: 0x139_a_GUARD_ICALL_CHECK_FAILURE_nt!guard_icall_handler
PROCESS_NAME: dotnet.exe   (also seen: where.exe)
IMAGE_VERSION: 10.0.26100.8875

A second dump manifested as 0x50 with FAILURE_BUCKET_ID: AV_Ntfs!NtfsContinueIndexEnumeration, AV.Type: Execute — execution jumped to a corrupted code pointer in the same enumeration path.

Crash timeline (from Windows event log + WinDbg; NTFS-enumeration crashes only — a separate resolved hypervisor path is noted at the end):

Date	Bugcheck	Context
18 Jul 2026	0x139 / 0xA	dotnet.exe — Ntfs enumeration (symbolised)
18 Jul 2026	0x50	dotnet.exe — Ntfs!NtfsContinueIndexEnumeration (symbolised)
18 Jul 2026	0x139 / 0xA	during dotnet build
20 Jul 2026	0x139 / 0xA	where.exe PATH enumeration on turn-prep (symbolised)
24 Jul 2026	0x139 / 0xA	during boot, before desktop (Claude not running)
24 Jul 2026	0x139 / 0xA	active session
24 Jul 2026	0x139 / 0xA	while gaming, Claude idle
25 Jul 2026	0x139 / 0xA	read-only Grep over repo, code-free research session
25 Jul 2026	0x139 / 0xA	two concurrent agents (/review fan-out) enumerating repo

Peak ~10–20/day during heavy coding periods; not all logged (some crashes hung at 0% writing the dump and left no event). Full !analyze -v output and minidumps available on request (not attached publicly as kernel dumps may contain in-memory fragments).

Steps to Reproduce

Windows 11 (build 26100.8875), Claude Code via Claude Desktop, a moderately large repo on an NTFS volume.
Have Claude perform directory-enumeration-heavy work: multiple concurrent agents (e.g. /review fan-out), a repo-wide Grep, a dotnet build on a multi-project solution, or normal turn-prep that issues where.exe lookups.
Kernel BSODs with 0x139 (Arg1 0xA) in Ntfs!FindNextIndexEntry2 via NtQueryDirectoryFile. Not deterministic per operation — probabilistic per enumeration — but frequency rises sharply with enumeration volume/concurrency, and is highest under multi-agent fan-out, reaching multiple crashes/day under heavy coding.

Ruled out with evidence (i.e. not the cause):

Updating Claude Code — reproduces on current 2.1.216
Third-party AV filters — removed McAfee + NordVPN file filters; dumps show clean filter stack (WdFilter only); still crashes
On-disk corruption — chkdsk /f clean (indexes verified, no repairs); DISM/SFC clean
Hardware — NVMe SMART healthy (0 wear), no WHEA events, BIOS at stock (no OC/undervolt), stable under sustained gaming load
User PreToolUse throttle hook — reduces frequency but cannot eliminate (harness-internal/build-internal enumeration is below the hook layer)

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.216 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Environment:

Claude Code 2.1.216, run via Claude Desktop, Windows
Windows 11, kernel 26100.8875 (client build 26200.8875)
Intel Core i9-14900HX; 4TB KIOXIA NVMe (SMART healthy)
Workload: .NET / Blazor Server solution (~14 projects)

Analysis / requested changes:
The triggering enumeration is largely internal to the harness (turn-prep where.exe, Grep, build-adjacent walks) or comes from multi-agent fan-out, and is thus unreachable by user PreToolUse hooks, so mitigation needs to be inside Claude Code on Windows:

Cap/serialise concurrent directory enumeration (NtQueryDirectoryFile) on Windows — a bounded concurrency limit spanning Grep/Glob, internal walks, and concurrent agents (a global limit, not per-agent, so multi-agent fan-out can't multiply it).
Aggressively cache/deduplicate where.exe-style executable lookups (2.1.117 added per-process caching; a first-lookup-per-process still enumerates — a persistent cross-process cache would reduce this).
Consider offering the gentler enumeration path used on macOS/Linux native builds (bfs/ugrep), or an opt-in low-concurrency search mode, on Windows — where the current build still uses the bundled ripgrep-based Grep.

Related: consistent with #32870 and PR #35710 (tool-mutex throttle). This report adds symbolised NTFS stacks, multiple independent (including Claude-free) triggers, multi-agent as worst-case concurrency, and confirmation that current 2.1.216 still reproduces.

A separate, largely-resolved crash path also occurred: 0x20001 HYPERVISOR_ERROR tied to the Cowork VM / Docker-WSL2 Hyper-V bridge (three occurrences in June), addressed by stopping the Cowork VM service and moving Cowork tasks to cloud execution. Noted for completeness; not the subject of this report.