Reproducible Windows BSOD — STOP 0x50 in bindflt.sys, always in claude.exe context

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?

<html>
<body>
<!--StartFragment--><html><head></head><body><h1>Reproducible Windows BSOD — STOP 0x50 in <code>bindflt.sys</code>, always in <code>claude.exe</code> context</h1>
<h2>Description</h2>
<p><strong>Four</strong> Windows blue screens over four days, all while using Claude products (Claude desktop app for Windows, and the Claude for Excel add-in). They occurred in two pairs — two on 2026-09-04, two on 2026-09-07 — with the second of each pair following the first within about an hour.</p>
<p><strong>All four minidumps have been analyzed and they are the same crash:</strong> identical bugcheck code, identical faulting instruction offset, and a byte-for-byte identical call stack. In all four, the faulting thread belonged to the <strong><code>claude.exe</code></strong> process.</p>
<p>The fault occurs inside <strong><code>bindflt.sys</code></strong> (Microsoft Windows Bind Filter Driver), reached through the file system filter manager (<code>FLTMGR.SYS</code>). <code>bindflt.sys</code> provides folder bind-mounting, which appears consistent with the desktop app's connected-folder / working-folder feature.</p>
<p>Because the faulting address is identical every time, this is a <strong>deterministic code-path bug — not random pool corruption and not faulty RAM.</strong></p>
<h2>Steps to reproduce</h2>
<p>No deliberate reproduction steps found yet. Observed conditions:</p>
<ul>
<li>Crashes 1 and 2 (2026-09-04): Claude for Excel add-in in use inside Excel.</li>
<li>Crash 3 (2026-09-07 15:02): typing a message in the Claude desktop app chat window.</li>
<li>Crash 4 (2026-09-07 15:13, 11 minutes later): <strong>the Claude desktop app was the only application running.</strong> No Excel, no other user application open.</li>
</ul>
<p>Crash 4 is notable for two reasons: it rules out interaction with any other user-mode application, and the VPN/RAS and WebDAV drivers that were loaded during the other three crashes were <strong>absent</strong> (the machine had just rebooted and the VPN had not reconnected). The crash still occurred, so neither a network-backed path nor another application is required to trigger it.</p>
<p>Uptime at crash was 18 min, 67 min, 7 h 10 min, and 10 min respectively — no long-uptime dependency.</p>
<h2>Expected behavior</h2>
<p>No system crash.</p>
<h2>Actual behavior</h2>
<p>Bugcheck <code>0x50</code> (<code>PAGE_FAULT_IN_NONPAGED_AREA</code>), immediate reboot, unsaved work lost.</p>
<h2>Environment</h2>

Item | Value
-- | --
OS | Windows 11, build 26100 (24H2), x64
CPU | 8 logical processors (Intel Lunar Lake)
Claude desktop app version | 1.46388.4.0
Install type | Appears to be an MSIX / Store package (Windows Settings shows a separate app/data size breakdown and an MSIX-style version string)
Claude for Excel add-in version | not exposed in the add-in UI
ntoskrnl.exe | base 0xfffff806c2200000, size 0x1450000
bindflt.sys | base 0xfffff80658be0000, size 0x2e000
FLTMGR.SYS | base 0xfffff80653eb0000, size 0x95000
Loaded kernel modules | 269–279

<h2>Call stack (identical in all four dumps)</h2>
<pre><code>ntoskrnl.exe+0x3132a0
ntoskrnl.exe+0x2be9e6
ntoskrnl.exe+0x20916c
ntoskrnl.exe+0x6b85cb
bindflt.sys+0xd5c0
bindflt.sys+0x2848e
bindflt.sys+0x1c071
ntoskrnl.exe+0x3f3b05
bindflt.sys+0x27094 &lt;-- faulting instruction
bindflt.sys+0x9998
bindflt.sys+0xd050
bindflt.sys+0x27b1a
bindflt.sys+0x99a8
FLTMGR.SYS+0xbc98
ntoskrnl.exe+0x2b0238
FLTMGR.SYS+0xb3b0
FLTMGR.SYS+0x9f00
FLTMGR.SYS+0x14bff
FLTMGR.SYS+0x1c5f0
FLTMGR.SYS+0x1c0c8
</code></pre>
<h2>Analysis</h2>
<ol>
<li>
<p><strong>Deterministic, not hardware.</strong> Identical faulting offset (<code>+0x27094</code>) and identical stack across four separate crashes on three different boots. Failing RAM or sporadic pool corruption would produce varying crash sites, so memory diagnostics are not indicated.</p>
</li>
<li>
<p><strong>Consistent invalid pointer shape.</strong> All four referenced addresses fall in the kernel pool range (<code>0xffff80..</code>, <code>0xffff9f..</code>, <code>0xffffa9..</code>, <code>0xffffc1..</code>) and all four end in low nibble <code>1</code> (<code>...811</code>, <code>...c11</code>, <code>...b61</code>, <code>...f21</code>). The same structure field appears to be read at the same offset each time, from a plausible-looking but unmapped pointer — consistent with a use-after-free or a stale pointer in the same code path.</p>
</li>
<li>
<p><strong>Read access</strong> (Arg2 = 0) in all four, which is more typical of a use-after-free than of a buffer overrun.</p>
</li>
<li>
<p><code>bindflt.sys</code> is a Microsoft driver, but the I/O path here originates from <code>claude.exe</code> in every case.</p>
</li>
<li>
<p><strong>Ruled out as necessary conditions:</strong> other user applications (crash 4 had only Claude running), network/WebDAV-backed paths (<code>mrxdav.sys</code> absent in crash 4), long uptime, and hardware memory faults.</p>
</li>
<li>
<p><strong>The app appears to be MSIX-packaged.</strong> Windows uses <code>bindflt.sys</code> to bind-mount MSIX package content, so <code>claude.exe</code> sits on the Bind Filter path by virtue of how it is installed — independent of whether a folder is connected. This is consistent with crash 4, where Claude was the only application running.</p>
</li>
</ol>
<h3>Questions</h3>
<ul>
<li>Does the Claude desktop app for Windows use <code>bindflt.sys</code> / Windows Container Isolation for its connected-folder sandbox, for its MSIX package mount, or both?</li>
<li>Is there a known interaction issue on Windows 11 build 26100?</li>
<li>Is there a way to avoid the bind-mount path as a workaround while this is investigated — for example a non-MSIX (plain installer) build?</li>
</ul>
<h2>Related issues</h2>
<p>This is <strong>not</strong> a duplicate of the existing Windows BSOD reports — no issue in this repo names <code>bindflt.sys</code> as a faulting module, and none pairs <code>bindflt</code> with any bugcheck code. Cross-referencing the closest ones for triage:</p>
<ul>
<li><strong>#91366</strong> — Claude Desktop (Windows/MSIX) recurring kernel BSODs. Same product surface; this report is a sibling signature, not a duplicate (that issue points at the Wof/Ntfs family).</li>
<li><strong>#30137</strong> — umbrella issue for Claude-triggered Windows kernel BSODs (0x139, 0x1E, 0x50). Its 0x50 is attributed to <code>Ntfs.sys</code>, not <code>bindflt.sys</code>.</li>
<li><strong>#81154</strong> — directory enumeration BSOD, 0x139 in <code>Ntfs!FindNextIndexEntry2</code>, with a secondary 0x50 in NTFS. Different driver and process.</li>
<li><strong>#32870</strong> — <code>claude.exe</code> triggers BSOD via <strong><code>Wof.sys</code></strong> during directory listing. Same process context and same FLTMGR minifilter path, different faulting driver.</li>
<li><strong>#74093</strong> — Write/Edit tools fail with spurious EEXIST on the sandboxed workspace, explicitly naming the <code>bindflt</code> + <code>bfs</code> sandbox pair. Same mechanism, user-mode failure only, no BSOD.</li>
<li><strong>#91265</strong> — Cowork VM kernel pool leak via <code>wcifs</code>/<code>bindflt</code> minifilters. Confirms the connected-folder path runs through <code>bindflt</code>, but the failure mode is a pool leak rather than a page fault.</li>
</ul>
<p>Distinguishing facts for this report: faulting module <strong><code>bindflt.sys</code></strong> (not <code>Wof.sys</code> / <code>Ntfs.sys</code>), fixed offset <strong><code>+0x27094</code></strong>, <code>claude.exe</code> process context in all four dumps, MSIX <strong>1.46388.4.0</strong>, and Windows 11 build <strong>26100 (24H2)</strong> — most existing reports are on 26200/25H2.</p>
<h2>Additional notes</h2>
<ul>
<li>This is a corporate managed machine with a deep third-party file system filter stack (endpoint protection and document-DRM products). Details can be shared privately if useful — they are omitted here because this is a public tracker.</li>
<li><strong>Minidumps are available on request</strong> and can be provided through Anthropic support rather than attached publicly, since they contain process and driver inventory data.</li>
<li>A kernel memory dump can be captured if the issue recurs.</li>
</ul>
<h2>Current workaround</h2>
<p>Not using the connected-folder feature of the Claude desktop app. <strong>This may not actually avoid the faulting code path</strong>, since the MSIX package mount also goes through <code>bindflt.sys</code>. Confirmation of whether it prevents recurrence is still pending.</p>
<h2>Analysis caveat</h2>
<p>Offsets above were derived by parsing the minidump headers, driver list, and raw kernel stack directly, <strong>without symbol files</strong>. Module attribution is reliable (base/size ranges), but exact function names were not resolved. A <code>!analyze -v</code> run against a symbol server is recommended for confirmation.</p></body></html><!--EndFragment-->
</body>
</html>

What Should Happen?

Claude should run without destabilizing the operating system. No matter what
file operations the app performs, they must not cause a kernel-mode page fault
in the Bind Filter driver, and must never result in a bugcheck / blue screen.

Error Messages/Logs

Steps to Reproduce

Note: This is a Claude Desktop (Windows, MSIX) issue, not Claude Code CLI.
Anthropic support directed me to file it here. CLI-specific fields are N/A.

No deliberate reproduction steps have been found — the crash is not triggered
by a specific user action, but all four occurrences happened while Claude was
running. What was observed:

1. Install Claude Desktop for Windows (MSIX package, v1.46388.4.0) on

Windows 11 build 26100 (24H2), x64.

1. Use Claude normally. In our case:

• Crashes 1 and 2 (2026-09-04): using the Claude for Excel add-in in Excel.
• Crash 3 (2026-09-07 15:02): typing a message in the Claude desktop chat window.
• Crash 4 (2026-09-07 15:13): Claude desktop app was the ONLY application

running. No Excel, no other user application open.

1. The machine blue-screens with STOP 0x50 (PAGE_FAULT_IN_NONPAGED_AREA)

and reboots immediately.

1. C:\Windows\Minidump\ contains a dump whose faulting instruction is

bindflt.sys+0x27094, reached via FLTMGR.SYS, in claude.exe process context.

Frequency: 4 crashes in 4 days, in two pairs. Uptime at crash was 18 min,
67 min, 7 h 10 min and 10 min — no long-uptime dependency.

All four minidumps are byte-for-byte identical in bugcheck code, faulting
offset and call stack, so this is a deterministic code path rather than
random corruption. Full analysis, bugcheck arguments and the call stack are
in the description above.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

N/A — Claude Desktop 1.46388.4.0 (MSIX), not Claude Code CLI

Platform

Other

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_