Share via

Wof.sys BSOD 0x139 KERNEL_SECURITY_CHECK_FAILURE in WofPreDirectoryControlCallback on Windows 11 25H2 with Compact OS

Tomer Bar-Shlomo 0 Reputation points
2026-03-09T15:00:02.63+00:00

Bug Summary

Wof.sys (Windows Overlay Filter) causes KERNEL_SECURITY_CHECK_FAILURE (0x139) during NTFS directory enumeration when Compact OS is enabled.

Crash Details

  • Date: 2026-03-09 16:17 (UTC+2)
  • Bugcheck: 0x00000139 (KERNEL_SECURITY_CHECK_FAILURE)
  • Parameter 1: 0x0a — Indirect call guard check detected invalid control transfer (CFG violation)
  • Failure bucket: 0x139_a_GUARD_ICALL_CHECK_FAILURE_Wof!WofPreDirectoryControlCallback+0x695
  • Failure hash: {78ac0991-5393-0281-b23b-ce115373dc6d}
  • Faulting module: Wof.sys version 10.0.26100.5074
  • Triggering process: claude.exe (Anthropic Claude Code CLI)
  • Triggering syscall: NtQueryDirectoryFileEx (standard directory listing)
  • Compact OS: Enabled at time of crash

Call Stack (abbreviated)

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!FltPerformSynchronousIo+0x443
Wof!WofPreDirectoryControlCallback+0x695        <-- CRASH HERE
FLTMGR!FltpPerformPreCallbacksWorker+0x58f
FLTMGR!FltpPassThroughInternal+0xc0
FLTMGR!FltpPassThrough+0x29f
FLTMGR!FltpDispatch+0x264
nt!IopfCallDriver+0x5b
nt!IopSynchronousServiceTail+0x1c5
nt!NtQueryDirectoryFileEx+0xd8
nt!KiSystemServiceExitPico+0x496

Environment

  • OS: Windows 11 25H2 (Build 26200.7922)
  • BuildLabEx: 26100.1.amd64fre.ge_release.240331-1435
  • Wof.sys: 10.0.26100.5074 (WinSxS) / 10.0.26100.1 (FileVersion metadata)
  • CPU: 32 logical processors
  • RAM: 192 GB
  • GPU: NVIDIA RTX 5000 Ada Generation Laptop GPU, driver 32.0.15.9571
  • Disk: 3.8 TB, 204 GB free
  • Compact OS: Was enabled (now disabled as workaround)
  • Recent KBs: KB5077241, KB5074828, KB5077869, KB5077371

Recurrence

This is the second occurrence of the same Wof.sys crash. First was 2026-03-06 (7 BSODs, multiple bugcheck codes). An in-place upgrade from ISO to build 26200 was performed, but Wof.sys was NOT updated (26200 shares 26100 driver binaries).

Workaround Applied

compact /CompactOS:never — decompressed all OS binaries to reduce Wof.sys directory control interceptions. This does not fix the bug but avoids the hot codepath.

Reproduction

Any process performing NTFS directory enumeration on a Compact OS system can trigger this crash. In this case, claude.exe (a Node.js-based CLI tool) was listing directory contents.

Attachments

Memory dump in zip via google drive system-info.txt windbg-analyze.txt event-logs.txt bsod-triage-output.txt driver-list.txt README.txt wof-bsod-report.pdf bsod-decision-workflow.puml.txt bsod-triage.ps1.txt windbg-analyze.ps1.txtdriver-check.ps1.txt

norton-check.ps1.txt

Windows for home | Windows 11 | Performance and system failures

9 answers

Sort by: Most helpful
  1. Deleted

    This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.


    Comments have been turned off. Learn more

  2. David-M 109.6K Reputation points Independent Advisor
    2026-03-11T13:12:46.9466667+00:00

    Given your findings and the high degree of certainty that this is a core driver defect, the Feedback Hub is the best place to report this. It is the direct channel to Microsoft's engineers.

    I searched the hub and didn't find any reports matching your specific technical details, so I believe you'll be the first to document this.

    Try to be as specific as possible in your report. If you come across other users facing the same issue, encourage them to upvote or comment on your post. The higher the engagement, the more likely it is to be prioritized by Microsoft’s engineers.


    For more information about the Feedback Hub, please visit the link below.

    https://support.microsoft.com/en-us/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332


    Feel free to ask any questions you may have.

    0 comments No comments

  3. David-M 109.6K Reputation points Independent Advisor
    2026-03-10T16:41:23.35+00:00

    Thanks for the details.


    I've analyzed the three new minidumps you provided. I had already analyzed yesterday's minidump.

    While the consistency of the crash at Wof!WofPreDirectoryControlCallback+0x695 is undeniable, the conclusion that this is a core bug in a signed Microsoft driver is likely a "false positive" generated by the AI's analysis.

    Here is why:

    1. The Nature of CFG (0x139): A Control Flow Guard failure at a specific offset means the Windows security check successfully caught an invalid jump. It doesn't mean the code at that offset is buggy; it means that the memory address it was supposed to jump to has been corrupted. This corruption usually happens earlier in the stack or is caused by another driver sharing the same memory space.
    2. The "Claude" Factor: Every single crash you've had, including the ones from today, is triggered by claude.exe. If this were a widespread Wof.sys defect, millions of Windows 11 users, including myself, would be reporting BSODs during standard file operations. The fact that it is isolated to this specific tool suggests that the application is performing non-standard directory queries that the Filter Manager cannot reconcile, or it is triggering a conflict with another filter driver.

    My recommendation:

    • Isolate the Software: You have proven that claude.exe is the consistent trigger. Your next step should be to report this directly to the Anthropic/Claude Code development team. Provide them with these minidumps. A user-mode CLI should never be able to trigger a CFG violation in a kernel driver.
    • Stress Test without Claude: Try running a massive directory enumeration using a different tool (like dir /s c:\ or a disk indexer). If the system stays stable, the "bug" isn't in Windows; it's a specific incompatibility between that tool and your system configuration.

    Feel free to ask any questions you may have.


  4. Tomer Bar-Shlomo 0 Reputation points
    2026-03-09T16:06:42.8766667+00:00

    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 when multiple Claude Code agents fire concurrent filesystem tool calls (Glob, Grep, Read) with no delay ΓÇö overwhelming Wof.sys (Windows Overlay Filter) or Hyper-V's 9P bridge.

    23 BSODs logged since 2026-03-06. Two crash paths, same root cause:

    Path Bugcheck Faulting module Count
    Windows native 0x139, 0x3B, 0x1E, 0x50 Wof.sys WofPreDirectoryControlCallback 15
    WSL /mnt/c/ 0x20001 hvix64.exe (Hyper-V) 1
    Other 0x14F, 0x10E Ntfs.sys, Norton 7

    Bug reports:

    Root Cause

    This is a Windows kernel bug, not a Claude Code bug. When Claude Code agents fire concurrent NtQueryDirectoryFileEx calls on NTFS volumes, the WOF minifilter crashes in its directory control callback. The crash is triggered by concurrency, not data volume:

    • 1GB of random files + 5 concurrent agents WITHOUT mutex ΓåÆ BSOD within minutes
    • Same data + same agents WITH mutex (serialized I/O) ΓåÆ stable, 381 tool calls, no crash
    • Same data + normal tools (no Claude) ΓåÆ stable, no crash

    WOF is a critical Windows component ΓÇö it cannot be disabled, detached, or unloaded.

    A rate-limiting daemon that serializes all Claude Code tool calls across concurrent agents via a PreToolUse hook. Only one filesystem operation proceeds at a time.

    Agent 1 ΓöÇΓöÇΓöÉ
    Agent 2 ΓöÇΓöÇΓöñ  PreToolUse hook
    Agent 3 ──┼──→ curl localhost:9876/acquire ──→ Mutex ──→ delay ──→ allow
    Agent 4 ΓöÇΓöÇΓöñ      (blocks until released)
    Agent 5 ΓöÇΓöÇΓöÿ
    

    Setup

    Prerequisites: JBang (runs on any JDK 17+, or installs its own).

    Step 1: Start the daemon

    # JBang (recommended ΓÇö no compilation needed, works everywhere)
    jbang Mutex.jbang.kt
    
    # Custom interval (default 2000ms, use 100-500ms for faster single-agent work)
    jbang Mutex.jbang.kt --interval 500
    
    # Run in background
    jbang Mutex.jbang.kt &
    

    JBang runs the Kotlin script directly ΓÇö no build step, no IDE required. First run downloads dependencies (~5s), subsequent runs start in ~1s.

    Optional: compile to native binary (instant startup, no JVM overhead):

    # Requires GraalVM JDK 21+ with native-image
    jbang export portable Mutex.jbang.kt
    native-image -jar Mutex.jar -o Mutex
    ./Mutex  # ~2MB binary, starts instantly
    

    Step 2: Configure Claude Code hook

    Add to ~/.claude/settings.json:

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

    Step 3: Verify

    curl http://localhost:9876/status
    # mutex  port=9876  interval=2000ms  acquires=0  uptime=5s
    

    How it works

    Each tool call triggers the PreToolUse hook, which calls curl localhost:9876/acquire. The daemon holds a coroutine Mutex ΓÇö only one caller proceeds at a time, with a configurable delay between releases. This serializes all filesystem I/O from all agents to a safe rate.

    Fail-open: if the daemon is not running, the hook exits immediately (no impact on single-agent usage).

    Endpoints

    Endpoint Method Description
    /acquire GET Block until released (rate-limited)
    /status GET Stats: port, interval, acquire count, uptime
    /health GET Liveness check (no blocking)
    /stop GET Graceful shutdown

    Performance impact

    Agents Without mutex With mutex (2s) With mutex (100ms)
    1 ~10 tools/sec 0.5 tools/sec 10 tools/sec
    5 ~50 tools/sec 0.5 tools/sec 10 tools/sec

    For interactive single-agent work, use --interval 100. For overnight batch runs (where BSODs happen most), --interval 2000 is safest.

    Workaround 2: Run Claude Code in WSL

    Since the Wof.sys crash happens on NTFS, running Claude Code inside WSL2 (which uses ext4) bypasses the WOF code path for local files.

    Note: WSL is NOT safe for multi-agent workloads accessing /mnt/c/ ΓÇö the same concurrent I/O burst can crash the Hyper-V 9P bridge (BSOD 0x20001). Use the mutex daemon even in WSL if running multiple agents.

    Setup (5 minutes)

    # 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 now goes through WSL automatically.

    Reverting

    When Microsoft patches Wof.sys, simply delete the wrapper:

    del %USERPROFILE%\.local\bin\claude.cmd
    

    Reproduction

    Step 1: Generate test data

    bash gen-repro-data.sh bsod-repro
    

    Creates ~1GB of random word files across 10 subdirectories. This data alone does NOT crash the system ΓÇö it is inert.

    Step 2: Open 5 Claude Code windows

    cd bsod-repro
    claude
    

    Paste one prompt per window:

    Window 1 ΓÇö Word Sorter:

    Read every .txt file in this directory tree. For each file, read all lines, split into words, sort them alphabetically, and write the sorted output to sorted/. After processing all files, re-scan and repeat.

    Window 2 ΓÇö Frequency Counter:

    Read every .txt file in this directory tree. Count the frequency of every unique word across all files. Write per-directory frequency reports to freq/. Re-scan every 2 minutes.

    Window 3 ΓÇö Duplicate Finder:

    Read every .txt file in this directory tree. For each file, compute a hash by reading the full file. Compare all hashes. Write results to dupes/report.tsv. Cross-check by re-reading. Re-scan every 3 minutes.

    Window 4 ΓÇö Line Merger:

    Read every .txt file in this directory tree. Merge all files within each batch-* subdirectory into merged/. Sort by line. Verify line counts. Re-scan continuously.

    Window 5 ΓÇö Cross-Reference Indexer:

    Read every .txt file in this directory tree. For each unique word, record which files contain it and on which line numbers. Write to xref/index.tsv. Verify by re-reading. Re-scan every 2 minutes.

    Step 3: Wait for BSOD

    All 5 agents will fire concurrent Glob/Grep/Read tool calls. Expected crash within minutes on Windows 11 Build 26200+.

    Step 4: Verify with mutex (should NOT crash)

    Start jbang Mutex.jbang.kt &, configure the hook in settings.json, repeat Step 2. System should remain stable.

    Test results (2026-03-14)

    WITH mutex: PASS

    5 concurrent Sonnet sub-agents, same prompts, same data. Mutex serialized all tool calls.

    Agent Task Tool calls Result
    1 Word Sorter 25 Completed
    2 Frequency Counter 53 9.1M words indexed
    3 Duplicate Finder 226 39 files verified
    4 Line Merger 19 11 batches merged
    5 Cross-Reference Indexer 58 78 words, 9126 rows

    Total: 381 tool calls, 112 mutex acquires. No BSOD.

    WITHOUT mutex: BSOD

    Same system, same session. 2 Sonnet sub-agents launched to read 18 files concurrently ΓÇö BSOD 0x3B at 05:32 (Wof.sys WofPreDirectoryControlCallback). Earlier: 5 agents via WSL ΓÇö BSOD 0x20001 at 04:42 (HYPERVISOR_ERROR).

    What doesn't work

    Attempted fix Result
    Disable CompactOS (compact /compactos:never) Mitigation only ΓÇö reduced frequency, did not eliminate
    Windows Update (KB5079473) Did not update Wof.sys
    Norton AV exclusions Unrelated (separate nllNetHub.sys crash)
    Disabling WOF service DO NOT ΓÇö breaks Windows
    WSL without mutex Crashes Hyper-V instead (0x20001)

    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)

    Files

    File Description
    Mutex.jbang.kt Rate limiter daemon ΓÇö Kotlin, Ktor CIO, coroutine Mutex
    mutex-acquire.sh PreToolUse hook script ΓÇö curl blocks until mutex releases
    TestMutex.jbang.kt Test suite ΓÇö health, serialization, WireMock hook sim
    gen-repro-data.sh 1GB random data generator + 5 agent prompts

    Minidump downloads

    Timeline

    Date Event BSODs
    2026-03-06 First BSODs after Windows upgrade to Build 26200 7
    2026-03-09 Continued crashes 1
    2026-03-10 Attempted CompactOS disable, WOF disable (broke Windows) 5
    2026-03-11 Norton crash, Ntfs.sys crash identified 3
    2026-03-12 Bug reports filed (Feedback Hub, GitHub, MS Q&A) 3
    2026-03-14 Root cause proven: concurrent I/O. Mutex workaround tested. 4
    Total 23
    0 comments No comments

  5. David-M 109.6K Reputation points Independent Advisor
    2026-03-09T15:33:06.1833333+00:00

    Hi. I'm David, and I'm happy to help you.


    Please share the minidump files.

    These files are in C:\Windows\Minidump.

    Copy any files you have to your desktop and store them in a ZIP file. Then, upload the ZIP file to the cloud (OneDrive), choose to share it, and get the link.

    Then, post the link to the ZIP file here so I can have a look.


    I await your reply.


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.