### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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?

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

Description

Four 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.

All four minidumps have been analyzed and they are the same crash: identical bugcheck code, identical faulting instruction offset, and a byte-for-byte identical call stack. In all four, the faulting thread belonged to the claude.exe process.

The fault occurs inside bindflt.sys (Microsoft Windows Bind Filter Driver), reached through the file system filter manager (FLTMGR.SYS). bindflt.sys provides folder bind-mounting, which appears consistent with the desktop app's connected-folder / working-folder feature.

Because the faulting address is identical every time, this is a deterministic code-path bug — not random pool corruption and not faulty RAM.

Steps to reproduce

No deliberate reproduction steps found yet. Observed conditions:

• Crashes 1 and 2 (2026-09-04): Claude for Excel add-in in use inside Excel.


• Crash 3 (2026-09-07 15:02): typing a message in the Claude desktop app chat window.


• Crash 4 (2026-09-07 15:13, 11 minutes later): the Claude desktop app was the only application running. No Excel, no other user application open.

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 absent (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.

Uptime at crash was 18 min, 67 min, 7 h 10 min, and 10 min respectively — no long-uptime dependency.

Expected behavior

No system crash.

Actual behavior

Bugcheck 0x50 (PAGE_FAULT_IN_NONPAGED_AREA), immediate reboot, unsaved work lost.

Environment

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

Call stack (identical in all four dumps)

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      <-- 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

Analysis

1. 
   

   Deterministic, not hardware. Identical faulting offset (+0x27094) 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.

   
   


2. 
   

   Consistent invalid pointer shape. All four referenced addresses fall in the kernel pool range (0xffff80.., 0xffff9f.., 0xffffa9.., 0xffffc1..) and all four end in low nibble 1 (...811, ...c11, ...b61, ...f21). 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.

   
   


3. 
   

   Read access (Arg2 = 0) in all four, which is more typical of a use-after-free than of a buffer overrun.

   
   


4. 
   

   bindflt.sys is a Microsoft driver, but the I/O path here originates from claude.exe in every case.

   
   


5. 
   

   Ruled out as necessary conditions: other user applications (crash 4 had only Claude running), network/WebDAV-backed paths (mrxdav.sys absent in crash 4), long uptime, and hardware memory faults.

   
   


6. 
   

   The app appears to be MSIX-packaged. Windows uses bindflt.sys to bind-mount MSIX package content, so claude.exe 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.

   
   

Questions

• Does the Claude desktop app for Windows use bindflt.sys / Windows Container Isolation for its connected-folder sandbox, for its MSIX package mount, or both?


• Is there a known interaction issue on Windows 11 build 26100?


• 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?

Related issues

This is not a duplicate of the existing Windows BSOD reports — no issue in this repo names bindflt.sys as a faulting module, and none pairs bindflt with any bugcheck code. Cross-referencing the closest ones for triage:

• #91366 — 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).


• #30137 — umbrella issue for Claude-triggered Windows kernel BSODs (0x139, 0x1E, 0x50). Its 0x50 is attributed to Ntfs.sys, not bindflt.sys.


• #81154 — directory enumeration BSOD, 0x139 in Ntfs!FindNextIndexEntry2, with a secondary 0x50 in NTFS. Different driver and process.


• #32870 — claude.exe triggers BSOD via Wof.sys during directory listing. Same process context and same FLTMGR minifilter path, different faulting driver.


• #74093 — Write/Edit tools fail with spurious EEXIST on the sandboxed workspace, explicitly naming the bindflt + bfs sandbox pair. Same mechanism, user-mode failure only, no BSOD.


• #91265 — Cowork VM kernel pool leak via wcifs/bindflt minifilters. Confirms the connected-folder path runs through bindflt, but the failure mode is a pool leak rather than a page fault.

Distinguishing facts for this report: faulting module bindflt.sys (not Wof.sys / Ntfs.sys), fixed offset +0x27094, claude.exe process context in all four dumps, MSIX 1.46388.4.0, and Windows 11 build 26100 (24H2) — most existing reports are on 26200/25H2.

Additional notes

• 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.


• Minidumps are available on request and can be provided through Anthropic support rather than attached publicly, since they contain process and driver inventory data.


• A kernel memory dump can be captured if the issue recurs.

Current workaround

Not using the connected-folder feature of the Claude desktop app. This may not actually avoid the faulting code path, since the MSIX package mount also goes through bindflt.sys. Confirmation of whether it prevents recurrence is still pending.

Analysis caveat

Offsets above were derived by parsing the minidump headers, driver list, and raw kernel stack directly, without symbol files. Module attribution is reliable (base/size ranges), but exact function names were not resolved. A !analyze -v run against a symbol server is recommended for confirmation.

### 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

```shell

```

### 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.
2. 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.
3. The machine blue-screens with STOP 0x50 (PAGE_FAULT_IN_NONPAGED_AREA)
and reboots immediately.
4. 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_

Start with the reported Windows 11 build 26100 setup, Claude Desktop MSIX v1.46388.4.0, and the available minidumps; no source files or tests are named. Run symbolized dump analysis such as !analyze -v to confirm the bindflt.sys+0x27094 path and claude.exe context. Done means maintainers can identify the triggering path or workaround and verify it no longer produces the STOP 0x50 BSOD.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.