Windows kernel BSOD (0x139) in VS Code session — same signature as #30137

Additional occurrence report: 0x139 GUARD_ICALL_CHECK_FAILURE during Claude Code / Claude Desktop (Cowork) sessions
Reporting on behalf of a Claude Desktop (Cowork) user on Windows 11, adding confirmation data to the crash signature already tracked in #30137, #32870, and #80912.
System
Laptop: Acer Predator PHN16-72
CPU: Intel Core i9-14900HX (Raptor Lake-HX Refresh)
RAM: 32 GB DDR5
OS: Windows 11 Home Single Language 64-bit, build 26100.8875 → later 26100.8894 (KB5121767)
BIOS: Acer V1.17 → updated to V1.18 mid-investigation (no effect on crash recurrence)
Claude Desktop version: 1.24012.9 (03c61d) — latest available at time of report
Antivirus: Kaspersky (fully removed via kavremover during troubleshooting) → Windows Defender only — no effect on crash recurrence
Compact OS: Confirmed OFF (compact /compactos:query → "system is not in the Compact state")
Usage pattern that triggers the crash
Crashes consistently occur during Claude Desktop / Cowork sessions with multiple agents running in parallel, doing codebase search/indexing across several local project repositories. Crashes have not been reproduced during gaming, video encoding, or other sustained CPU-heavy workloads unrelated to Claude.
Three independent crash dumps analyzed (WinDbg !analyze -v)
All three share the identical FAILURE_ID_HASH: {88bd549f-a028-0599-8f3b-3c24fdf0cd3f} and FAILURE_BUCKET_ID: 0x139_a_GUARD_ICALL_CHECK_FAILURE_nt!guard_icall_handler.
Dump file Timestamp PROCESS_NAME BIOS at time
072626-19421-01.dmp 2026-07-26 23:40:06 where.exe 1.17.0.0
072726-22468-01.dmp 2026-07-27 19:13:11 where.exe 1.18.0.0
072726-21015-01.dmp 2026-07-27 22:43:52 claude.exe 1.18.0.0
Common stack trace (all three, functionally identical):

nt!KeBugCheckEx
nt!guard_icall_handler+0x1e
nt!RtlpExecuteHandlerForException+0xf
nt!RtlDispatchException+0x2d2
nt!KiDispatchException+0x35f
nt!KiExceptionDispatch+0x145
nt!KiGeneralProtectionFault+0x365
nt!KscpCfgDispatchUserCallTargetEsSmep+0x11
Ntfs!FindNextIndexEntry2+0x675
Ntfs!NtfsContinueIndexEnumeration+0x10e
Ntfs!NtfsQueryDirectory+0xd32
Ntfs!NtfsCommonDirectoryControl+0x2ce
Ntfs!NtfsFsdDirectoryControl+0xcb
nt!IopfCallDriver+0x5b
FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x3fe
FLTMGR!FltpDispatch+0x244
nt!IopfCallDriver+0x5b
nt!IopSynchronousServiceTail+0x1c5
nt!NtQueryDirectoryFileEx+0xd8
nt!KiSystemServiceCopyEnd+0x25

Bugcheck arguments (identical across all three):

KERNEL_SECURITY_CHECK_FAILURE (139)
Arg1: 000000000000000a — Indirect call guard check detected invalid control transfer.
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: <trap frame address, varies>

Notes
This matches the nt!guard_icall_handler bucket variant (crash lands inside Ntfs.sys itself, not inside Wof!WofPreDirectoryControlCallback as in #32870) — consistent with the theory in #80912/#30137 that this is not Compact-OS/WOF-specific, but a more general corruption of an indirect call target that happens to surface inside NTFS directory enumeration (NtQueryDirectoryFileEx).
PROCESS_NAME alternates between claude.exe and where.exe across occurrences. where.exe is a native Windows utility for PATH resolution — its presence supports the hypothesis in #80912 that Claude Code (via Bun) spawning subprocesses for tool/PATH resolution is part of the trigger path, not just sustained direct file I/O by claude.exe itself.
BIOS microcode update (Acer V1.17 → V1.18, includes newer Intel MCU) had zero effect on crash recurrence or signature — rules out CPU firmware/voltage instability as a contributing factor in this case.
Full antivirus removal (Kaspersky → Windows Defender only) had zero effect — rules out AV minifilter interaction as a contributing factor in this case.
Official Intel Processor Diagnostic Tool (v4.1.9.41) ran full stress suite (Cache, IMC, Prime/FP/FMA3/AVX2, DGEMM, GPU stress) twice with all modules PASS — no CPU/memory functional fault detected under controlled short-duration stress (acknowledged as inconclusive given the intermittent nature of the bug).
Suggested mitigation while a fix is pending
Per the discussion in #32870, throttling/batching NtQueryDirectoryFileEx calls on Windows — or avoiding many concurrent parallel ripgrep-driven directory walks from multiple simultaneous agents — appears to reduce trigger frequency, consistent with the concurrency-defect theory discussed in the linked Microsoft Q&A thread.
Happy to share full !analyze -v output or raw .dmp files if useful for reproduction.

<html>
<body>
<!--StartFragment--><html><head></head><body><p>Independent reproduction on <strong>24H2 / build 26100</strong> (existing reports here and in #32870 are 25H2 / 26200). Two crashes, 17 minutes apart, same workload both times. My stack contains <strong>both</strong> the <code>Wof!WofPreDirectoryControlCallback+0x695</code> frame from #32870 <strong>and</strong> the <code>Ntfs!FindNextIndexEntry2</code> chain from this issue, which suggests these are the same underlying defect rather than two separate ones.</p>
<h3>Environment</h3>

  |  
-- | --
OS | Windows 11 24H2, build 26100
Wof.sys | 10.0.26100.8875 (newer than the 10.0.26100.5074 in #32870, still faults at the same offset)
CPU | Intel(R) Core(TM) i9-14900HX (32 logical processors) — matches the hardware correlation noted in this issue
Workload | Claude Code on a Unity project (large Library/ tree)
Process | find.exe via NtQueryDirectoryFile

<h3>Bugcheck</h3>
<pre><code>FAILURE_BUCKET_ID: 0x139_a_GUARD_ICALL_CHECK_FAILURE_Wof!WofPreDirectoryControlCallback
BUCKET_ID_FUNC_OFFSET: 695
FAILURE_ID_HASH: {78ac0991-5393-0281-b23b-ce115373dc6d}
IMAGE_NAME: Wof.sys IMAGE_VERSION: 10.0.26100.8875
BUGCHECK: 0x139 P1=0xa (Indirect call guard check detected invalid control transfer)
PROCESS_NAME: find.exe
</code></pre>
<h3>Trap frame — CFG dispatch faults on a non-canonical pointer</h3>
<pre><code>nt!KscpCfgDispatchUserCallTargetEsSmep+0x11:
fffff805b75c0791 4f8b1cd3 mov r11,qword ptr [r11+r10*8] ds:fbffdc7615ad6d78=????????????????
r11=fbffdc7615ad6d78 r10=0000000000000000
</code></pre>
<p><code>r11</code> holds a non-canonical address, so the guard-bitmap lookup takes a GP fault, which dispatches to <code>nt!guard_icall_handler</code> and bugchecks. The function pointer was already corrupt before CFG got involved.</p>
<h3>Stack</h3>
<pre><code>nt!KeBugCheckEx
nt!guard_icall_handler+0x1e
nt!RtlpExecuteHandlerForException+0xf
nt!RtlDispatchException+0x2d2
nt!KiDispatchException+0x35f
nt!KiExceptionDispatch+0x145
nt!KiGeneralProtectionFault+0x365
nt!KscpCfgDispatchUserCallTargetEsSmep+0x11
Ntfs!FindNextIndexEntry2+0x675
Ntfs!NtfsContinueIndexEnumeration+0x10e
Ntfs!NtfsQueryDirectory+0xd32
Ntfs!NtfsCommonDirectoryControl+0x2ce
Ntfs!NtfsFsdDirectoryControl+0xcb
nt!IopfCallDriver+0x5b
nt!IofCallDriver+0x13
FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x3fe
FLTMGR!FltPerformSynchronousIo+0x443
Wof!WofPreDirectoryControlCallback+0x695
FLTMGR!FltpPerformPreCallbacksWorker+0x568
FLTMGR!FltpPassThroughInternal+0xc0
FLTMGR!FltpPassThrough+0x230
FLTMGR!FltpDispatch+0x228
nt!IopfCallDriver+0x5b
nt!IofCallDriver+0x13
nt!IopSynchronousServiceTail+0x1c5
nt!NtQueryDirectoryFile+0xe0
nt!KiSystemServiceExitPico+0x496
</code></pre>
<h3>Cross-dump comparison</h3>
<p>I compared both minidumps frame-by-frame by module+offset (ASLR-independent). The two stacks are <strong>identical at the same stack offsets</strong> from <code>+0x0810</code> through <code>+0x1b80</code> — 67 frames in common, same bugcheck subtype, same faulting offset, same process. Deterministic path, not a random corruption.</p>
<p>Notably, the only third-party driver anywhere near either stack (a security-suite driver appearing once in crash 1) did <strong>not</strong> appear in crash 2, and sat in the region where the two stacks diverge — i.e. it was stale stack data, not a participant. Both reproducible stacks are 100% Microsoft code: <code>ntoskrnl</code> + <code>Ntfs.sys</code> + <code>FLTMGR.SYS</code> + <code>Wof.sys</code>.</p>
<h3>Notes</h3>
<ul>
<li><code>chkdsk C: /scan</code> reports no filesystem problems (1.16M file records, 28,274 reparse points, clean).</li>
<li>Consistent with reports here and in #32870 that this is a <strong>concurrency</strong> issue: the trigger is parallel directory enumeration, and single-threaded walks of the same tree are stable.</li>
<li>Since Wof.sys 10.0.26100.8875 still faults at <code>+0x695</code>, this is not fixed in the 24H2 servicing branch as of July 2026.</li>
</ul></body></html><!--EndFragment-->
</body>
</html>

Note that I added a script to reproduce this on your PC in #32870 - through that I confirmed the cause - the specific KB to uninstall and resolve the issue.

Correction to my earlier comment: I misreported the build. This machine is
Windows 11 25H2, build 26200.8875 (UBR 8875, ntoskrnl 10.0.26100.8875) — the
same branch as the other reports here, not 24H2/26100. I had read the servicing
branch (26100) out of the dump header as the OS build. Please disregard the
"not specific to the 25H2 branch" inference in that comment; it doesn't hold.

The rest of the data stands: four crashes 07-28 to 07-30, four different
triggering processes (find.exe ×2, AvBugReport.exe, Unity.exe), 15/15 core
frames identical at identical stack offsets, RAX=0 / R10=0 / R11=0xFBFF… in
every one. KB5101650 is installed here (UBR 8875).

One oddity worth flagging: Wof.sys on this machine reports FileVersion
10.0.26100.1 despite UBR 8875, and its PE checksum (0x00050EDA, 284112 bytes)
is identical to the image loaded in every crash dump. If others can post the
checksum rather than the version string, that would be a more reliable way to
compare binaries across machines than FileVersion appears to be here.

**Additional data point — kernel dump identifying which indirect call is failing**

Confirming the same signature on a fifth i9-14900HX machine, and adding analysis from a full kernel dump (not a triage minidump) that identifies the specific call target.

System

• MSI Raider 18 HX A14VHG (MS-1822)
• Intel Core i9-14900HX, 64 GB DDR5
• Windows 11 25H2, build 26200.8875 (kernel 26100.8875)
• BIOS E1822IMS.30B (April 2024) — deliberately not updated, see below
• Compact OS: off (compact /compactos:query → "not in the Compact state")
• HVCI/VBS: enabled (SecureKernel.HalpHvciEnabled = 1)

Signature match

FAILURE_ID_HASH:    {88bd549f-a028-0599-8f3b-3c24fdf0cd3f}
FAILURE_BUCKET_ID:  0x139_a_GUARD_ICALL_CHECK_FAILURE_nt!guard_icall_handler

Identical hash to the three dumps reported above. Stack matches frame-for-frame and offset-for-offset. The only difference is the syscall entry — nt!NtQueryDirectoryFile+0xe0 rather than NtQueryDirectoryFileEx+0xd8 — because the triggering process here was Robocopy.exe.

14 bugchecks, 10 Jun – 8 Aug 2026

| Count | Code |
|---|---|
| 11 | 0x139 (0xa) GUARD_ICALL |
| 2 | 0x00020001 HYPERVISOR_ERROR |
| 1 | 0x3B SYSTEM_SERVICE_EXCEPTION (0xc0000005) |

Trigger processes observed: Robocopy.exe, go.exe, and PowerShell Get-ChildItem -Recurse. Not exclusively Claude Code on this machine — anything performing recursive directory enumeration reproduces it. That supports the "general corrupted indirect-call target surfacing inside NTFS enumeration" reading rather than anything client-specific.

Frequency scaled with concurrency: weekly at first, then roughly every 6 minutes during a period with several parallel agent sessions plus a large robocopy running. Consistent with the mutex/serialisation repro in the linked Microsoft Q&A thread.

New: what the corrupted pointer actually is

The failing call site disassembles to:

Ntfs!FindNextIndexEntry2+0x660:
  movzx r9d, byte ptr [rbp+77h]     ; arg4 - case flag (=1)
  mov   r8, rbx                      ; arg3
  mov   rdx, qword ptr [rbp+67h]     ; arg2
  mov   rcx, qword ptr [rbp-41h]     ; arg1
  call  nt!KscpCfgDispatchUserCallTargetEsSmep   ; returns to +0x675

Pool-tagging the arguments identifies them:

| Reg | Address | Pool tag | Contents |
|---|---|---|---|
| rcx | ffffe10b69963000 | NtMo — mount.c, ntfs.sys, 0x20000 | ascending UTF-16 table 0000,0001,0002,0003… → the $UpCase table |
| rdx | ffffe10bb25491e0 | NtFd — DirCtrl.c, ntfs.sys, 0x60 | valid UTF-16 filename |
| r8 | ffffcc02bb545508 | — | second name buffer |

Ntfs!NtfsCollateNames sits immediately after FindNextIndexEntry2 in the binary. The signature (upcase_table, name_a, name_b, case_flag) identifies this as the NTFS index collation callback, dispatched indirectly because the routine depends on the index's collation rule.

The key detail: every data argument was intact. The 128 KB $UpCase table was fully valid, the filename buffer was correct UTF-16 in a properly-tagged NTFS allocation, the flag byte sane. Only the 8-byte function pointer was zero:

rax=0000000000000000   r10=0 (= rax>>9)   r11=fbffa9f6f30dce20  (CFG bitmap base)
nt!KscpCfgDispatchUserCallTargetEsSmep+0x11:
  mov r11,qword ptr [r11+r10*8]  ds:fbffa9f6`f30dce20=????????????????

The fault address equals the bitmap base exactly, so r10 == 0, so rax >> 9 == 0, so the call target was < 512 — null, not a wild or non-canonical pointer. (Worth distinguishing from the report above where r11 held a non-canonical value; both fault in the same instruction, but the target differs in character.)

A single pointer-sized value reading back as zero with all adjacent structure fields valid is a different shape from general structure corruption. It narrows the question to: where is the index collation function pointer stored, and what path can leave it null?

Caveat: non-volatile registers r13/r14/rbx read as zero in the trap frame — a GP fault saves only a partial context — so I couldn't walk back to the owning structure.

Ruled out on this machine

• Ntfs.sys integrity — Authenticode valid, sfc /verifyfile reports no integrity violations. It is the shipped binary, unmodified.
• Component store — was genuinely corrupt; repaired with DISM /RestoreHealth. No effect on crashes.
• Third-party minifilter — an orphaned PDFsFilter (Raxco, bundled via McAfee PC Optimizer) was unloaded and its service deleted. Crashes continued.
• A 5-minute scheduled robocopy task — disabled. Crashes continued.
• Compact OS — already off throughout.
• Wof.sys — loaded (altitude 40700, instances attached) but absent from this stack. Matches the nt!guard_icall_handler bucket variant rather than the Wof!WofPreDirectoryControlCallback one.

One data point I can't interpret

WHEA-Logger Id 19 on 07/08: Corrected Machine Check · Internal parity error · Processor Core · APIC ID 33. Single occurrence in 180 days. Given the report above where Intel's own Processor Diagnostic Tool passed all modules twice and a microcode/BIOS update (Acer V1.17 → V1.18) changed nothing, I don't believe this is causal — noting it only in case it correlates for others on this SKU.

Happy to share the full MEMORY.DMP (7.16 GB) or run targeted WinDbg commands against it if that would help narrow where the collation pointer is sourced.

@JDLondon7 Your collation-callback identification slots together with an analysis in #32870 that answers your open question directly. @dxdum, working from a kernel dump, found where that pointer is sourced: NTFS selects the comparison routine from a 4-entry function table inside the Ntfs image (Ntfs+0x5E7B8/0x5E7D8), indexed by a field at [Vcb+0x2B0]. On their machine that field read 0x60001 instead of 1, a 2-byte partial overwrite of the upper half, so the lookup ran past the table into zeroed image bytes and returned the null you caught in RAX. Your "single pointer-sized value reads zero while every adjacent structure is valid" is exactly what that mechanism predicts: the pointer is not stored corrupted, it is fetched through a corrupted index.

Since you have the full 7.16 GB dump, you can close that loop in one read where the rest of us with triage dumps cannot: locate the Vcb for the crashing volume and dump the qword at +0x2B0. dxdum's fast check: anything other than a small integer 0-3 confirms it. That would make yours the second independent kernel-dump confirmation of the corrupted-index mechanism, and your partial-context caveat stops mattering, the Vcb is reachable from the volume device object rather than the trap frame.

Second ask, and this one produces the datum the thread is missing: try the KB5101650 rollback with a measured before/after rather than waiting. Procedure, block-list and the reproduction script are in my comments on #32870; the short version:

Suspend-BitLocker -MountPoint "C:" -RebootCount 1   # if BitLocker is on
wusa /uninstall /kb:5101650                          # reboots; if error 0x800f0825, restart first, retry
# then immediately: Settings > Windows Update > Pause updates (past next Patch Tuesday), and:
New-Item 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' -Force | Out-Null
Set-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' -Name AUOptions -Type DWord -Value 2

then run the walk-loop script from #32870 against it. On my m18 R2 (24H2 branch) that took the machine from bugchecking in 10-21 minutes to 24 laps / 66 minutes clean, and 10 days / zero bugchecks since under unthrottled Claude Code use.

I want to be straight about why your machine is the interesting test rather than a formality: your onset is 10 June, which predates KB5101650 by 5 weeks, on the 26200 branch. So the rollback on your machine has 2 informative outcomes, not 1. Clean walks afterwards extends the rollback fix to 25H2 and implicates the July servicing across both branches; crashes continuing on the reverted binaries is the first hard evidence the armed defect predates July, which reframes the whole KB timeline several of us have been leaning on. Either result, with lap counts, is worth more than any amount of further dump reading.

Minor corroboration on your WHEA note: this machine logged exactly 1 uncorrectable WHEA event across 19 crashes in the same period, also on a 14900HX, also non-causal on the evidence (deterministic same-offset faults before and after, clean SMART, memory at spec). Your single corrected parity event in 180 days reads the same way to me: coincidental noise on a SKU that attracts hardware suspicion this bug does not deserve.