BSOD (PAGE_FAULT_IN_NONPAGED_AREA / bindflt.sys) triggered by Cowork VM Service starting while a Python-based MCP extension (uv run) scans its own directory under %APPDATA%\Claude

Same crash here, and the faulting instruction matches: three BSODs in one evening, all 0x50 PAGE_FAULT_IN_NONPAGED_AREA in bindflt.sys, and the faulting instruction ends in ...b0a6 every time. That is the same offset as the Arg3 in your !analyze output (bindflt!BfMergeEnumerationContexts+0xba).

Environment

• Windows 10 Pro 22H2, build 19045.7725 (bindflt.sys 10.0.19041.5678)
• Claude Desktop MSIX 2.9939.2.0 (auto-updated from 2.7032.0.0 at 11:57 on the same day), Claude Code 2.1.281
• WSL 2.7.14 installed, Codex desktop app also installed
• No MCP extension under %APPDATA%\Claude\Claude Extensions was involved as far as I can tell. Cowork itself had not been used for weeks, and the VM was never booted ([VM] VM already stopped).

Bugchecks (2026-09-26, local time UTC+2)

| Reboot | Arg1 (read address) | Arg3 (faulting IP) | Arg4 |
|---|---|---|---|
| ~20:33 | ffffca8732620d65 | fffff8061f89b0a6 | 0 |
| ~20:41 | ffffe78eb383a863 | fffff80489cab0a6 | 2 |
| ~23:50 | ffff9e0795cba49b | fffff8065696b0a6 | 2 |

Correlation with cowork-service.log

• 20:37:06 Created new VM session for <SID>:C:\Users\<user>\AppData\Roaming\Claude, then BSOD, then reboot at 20:41:16
• 23:45:46 same line, then BSOD, then reboot at 23:50:22
• For the first crash there was no fresh session start right before it. The service had been running since the app update at 11:57.

So on my machine the crash came about 4 minutes after session creation, not 15 to 25 seconds. I could not open MEMORY.DMP without elevation, so the faulting process is unconfirmed on my side.

Workaround, and a detail others will hit

• Setting the startup type to Disabled does not work in services.msc, even when elevated. The field stays greyed out because the package service's security descriptor only grants SERVICE_CHANGE_CONFIG to the service SID.
• Stopping the service alone is not enough either: Claude Desktop restarted it within minutes.
• What worked was an elevated Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService -Name Start -Value 4 followed by a stop (Authenticated Users have SERVICE_STOP). With that the service stays stopped, and the app can no longer start it. I expect an app update to re-register the service and reset this.

It would help to have a supported way to turn Cowork off entirely (so the service is not registered or started) for users who do not use it, at least until the bindflt race is fixed.

Hitting what looks like the same bug. Adding a data point because in my case no Cowork VM session was involved — the trigger seems to be any per-user Python launched by Claude Code inside Claude Desktop.

Environment

• Windows 10 Home 22H2, build 19045.7725 · bindflt.sys 10.0.19041.5678
• Claude Desktop 2.16120.0.0 (MSIX) · Claude Code 2.1.284 sessions running inside Desktop
• Python 3.13.15, per-user install under %LOCALAPPDATA%\Programs\Python\Python313

Crashes

• 6 × 0x50 PAGE_FAULT_IN_NONPAGED_AREA since 2026-09-09 (the first one happened before that month's cumulative update was installed). Arg3 ends in …b0a6 every time.
• Two dumps analyzed (2026-10-01, 16 minutes apart): faulting IP = bindflt+0x1b0a6 = function start 0x1afec + 0xba, which matches BfMergeEnumerationContexts+0xba reported here (I had no symbols loaded, so the name is inferred from the offset).
• Stack in both: user-mode directory query → nt!IofCallDriver → FltMgr → bindflt+0x1b870 → bindflt+0x1b0a6. The faulting instruction (mov r15d,[rax+r14], rax=0x3c, rdx=0x5e) looks like it is reading FileNameLength of a FILE_BOTH_DIR_INFORMATION entry through a stale pointer.
• Faulting process in both: python.exe (Python313) enumerating its own …\Python313\Lib\ directory, i.e. just Python starting up / importing.
• Process tree at crash time (from the kernel dump): Claude.exe (MSIX) → claude.exe (Claude Code CLI) → bash.exe → python.exe → pyftsubset.exe → python.exe (faulting). A second Claude Code session was running another python.exe at the same time. No vmwp.exe / vmcompute.exe / vmmem was running; cowork-svc.exe was only idling as a service.

Why every Claude Code subprocess goes through bindflt's merge path

• The Claude Code CLI image is physically at %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude-code\2.1.284\claude.exe.
• From a shell spawned by Claude Code, %APPDATA%\Claude\claude-code\2.1.284\claude.exe exists; from a cmd.exe started via WMI (outside the container) it does not. GetCurrentPackageFullName() returns APPMODEL_ERROR_NO_PACKAGE in the Claude Code shell, yet that shell still sees the Desktop container's merged AppData view.
• So anything under %APPDATA% / %LOCALAPPDATA% that Claude Code's subprocesses enumerate goes through BfMergeEnumerationContexts. A per-user Python install does that on every start, which seems to be enough to hit the race, especially with several sessions running Python in parallel.

Workaround I'm applying

• Moving Python out of AppData (so stdlib/site-packages are no longer under the merged root), and running heavy Python batches from a terminal outside Claude Desktop.

Possible fix on the Desktop side: spawn Claude Code and its tool subprocesses fully outside the MSIX file-system virtualization, or install claude-code outside the package's LocalCache. Happy to pull more details from the dumps if useful.

Another data point for this issue, same driver but a different function (BfPreCreate here, BfMergeEnumerationContexts in the original report), on Windows 11 24H2 rather than Windows 10.

Summary

Four kernel crashes in ~17 hours, all 0x50 PAGE_FAULT_IN_NONPAGED_AREA, all at the same instruction in Microsoft's bindflt.sys (BfPreCreate+0x1864), all with the same faulting process: a GoogleTest binary (assistant_tests.exe) from a C++ project, launched via ctest -j by a Claude Code session. Every crash came within one to two minutes of a parallel ctest run starting.

bindflt only inspects/redirects file opens when bind mappings exist. On this machine the only known source of mappings is the Claude desktop app's Cowork VM Service (cowork-svc.exe), whose log shows a live VM session during three of the four crashes. The Cowork feature itself was never used here: the only thing in use was the Claude desktop app, running Claude Code from its Code tab in ultracode mode. The service still created a VM session each time the desktop app connected to it. After a reboot on which the service was never started, the same full suite (3,221 tests, 260 s) ran clean on the first attempt, the first full run to survive since the crashes began.

This is a Microsoft driver bug (missing empty-string check), but it is only reachable on machines where something has set up bind mappings, which Cowork does.

Environment

| | |
|---|---|
| OS | Windows 11 Pro 24H2, kernel 10.0.26100.9457 (KB5129195 / KB5126052 installed 2026-09-15) |
| bindflt.sys | 10.0.26100.9278 |
| CPU | AMD Ryzen 9 9950X3D (16C/32T) |
| Claude Desktop | 2.16120.0.0 (MSIX, Claude_pzs8sxrjxfjjc) |
| Claude Code | 2.1.284, run inside the Claude desktop app (Code tab) in ultracode mode; Cowork never used |
| CoworkVMService | running as LocalSystem, app\resources\cowork-svc.exe |
| Also present | VMware Workstation 17.6.4, WSL (no distros), Hyper-V/VBS enabled, ESET 19.2 |
| Not present | Docker, Windows Sandbox package |
| Dumps | Kernel minidumps only; full MEMORY.DMP failed every time (volmgr event 161, BugCheckProgress 0x20063) |

Timeline (local, UTC+1)

| # | Crash | Cowork state (from C:\ProgramData\Claude\Logs\cowork-service.log) | Test activity (from Claude Code session log) |
|---|---|---|---|
| 1 | 2026-09-30 23:41:08 | Service running; sessions created 12:27, 12:47, 17:41; idle timeout at 21:04 | ctest with 7 parallel assistant_tests.exe; crash mid-run |
| 2 | 2026-10-01 14:19:42 | Session created 10:47 (...\Roaming\Work), still active | ctest -j started 14:17:48 |
| 3 | 2026-10-01 15:06:50 | Session created 14:48 (...\Roaming\Second), active | ctest -j 6 started 15:06:08 (42 s before crash) |
| 4 | 2026-10-01 16:57:29 | Session created 15:43; service stopped 15:51, not restarted | ctest started 16:56:41 (48 s before crash) |
| after | 2026-10-01 16:58 reboot onwards | Service never started this boot (disabled) | Full suite 3,221 tests / 259.66 s 100% passed at 18:07; smaller runs also clean; 0 crashes |

Crash 4 happened after the service was stopped but before a reboot. The simplest reading is that the mappings created by the 15:43 session outlived the service process until the 16:58 reboot cleared them.

Session paths in the log are of the form
<SID>:C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\<profile>.

!analyze -v (crash 1; crashes 2 to 4 are identical apart from addresses)

PAGE_FAULT_IN_NONPAGED_AREA (50)
Arg1: fffffffffffffffe, memory referenced.
Arg2: 0000000000000000, read
Arg3: fffff8036430b284, instruction address  (bindflt!BfPreCreate+0x1864)
Arg4: 0000000000000002

PROCESS_NAME:        assistant_test          (assistant_tests.exe, name truncated by kernel)
IMAGE_NAME:          bindflt.sys
IMAGE_VERSION:       10.0.26100.9278
SYMBOL_NAME:         bindflt!BfPreCreate+1864
FAILURE_BUCKET_ID:   AV_bindflt!BfPreCreate
Failure.Hash:        {03a249e6-2d07-f180-942e-a56e2fc1c65b}

STACK_TEXT:
  nt!KeBugCheckEx
  nt!MiSystemFault+0x661
  nt!MmAccessFault+0x646
  nt!KiPageFault+0x38b
  bindflt!BfPreCreate+0x1864
  FLTMGR!FltpPerformPreCallbacksWorker+0x331
  FLTMGR!FltpPassThroughInternal+0xc0
  FLTMGR!FltpCreate+0x1d2
  nt!IofCallDriver+0x84
  nt!IopParseDevice+0xf5f
  nt!IopParseFile+0xc7
  nt!ObpLookupObjectName+0x1360
  nt!ObOpenObjectByNameEx+0x224
  nt!IopCreateFile+0x4d6
  nt!NtCreateFile+0x79
  nt!KiSystemServiceCopyEnd+0x28
  0x00007ffc`606c1864                      (ntdll NtCreateFile stub, user mode)

All four dumps:

| Dump | Time | Arg1 | Arg3 | Process | Bucket |
|---|---|---|---|---|---|
| 093026-23750-01.dmp | 09-30 23:41 | fffffffffffffffe | fffff803'6430b284 | assistant_tests | AV_bindflt!BfPreCreate |
| 100126-23796-01.dmp | 10-01 14:19 | fffffffffffffffe | fffff806'7ab4b284 | assistant_tests | AV_bindflt!BfPreCreate |
| 100126-24031-01.dmp | 10-01 15:06 | fffffffffffffffe | fffff807'6645b284 | assistant_tests | AV_bindflt!BfPreCreate |
| 100126-24140-01.dmp | 10-01 16:57 | fffffffffffffffe | fffff800'69d2b284 | assistant_tests | AV_bindflt!BfPreCreate |

(Arg3 low 16 bits are b284 every time = same offset 0x1b284 in bindflt.sys, different load base per boot.)

What the faulting code is doing

Disassembly around the fault (bindflt.sys 10.0.26100.9278):

bindflt!BfPreCreate+0x1837:
  mov   rcx,r13
  mov   qword ptr [r13+28h],rdi            ; CallbackData->TagData = buffer
  call  FLTMGR!FltSetCallbackDataDirty
  mov   dword ptr [r13+18h],104h           ; CallbackData->IoStatus.Status = STATUS_REPARSE
  mov   eax,dword ptr [rdi]
  mov   qword ptr [r13+20h],rax            ; IoStatus.Information = tag
  mov   rax,qword ptr [r14+20h]            ; FLT_FILE_NAME_INFORMATION*
  movzx ecx,word ptr [rax+58h]             ; FinalComponent.Length
  mov   rax,qword ptr [rax+60h]            ; FinalComponent.Buffer
  shr   rcx,1
bindflt!BfPreCreate+0x1864:
  cmp   word ptr [rax+rcx*2-2],5Ch         ; <-- fault: last char of FinalComponent == '\' ?
  jne   +0x1875
  mov   rax,qword ptr [r13+28h]
  add   word ptr [rax+6],2                 ; TagData->UnparsedNameLength += 2

The filter has matched a bind mapping and is completing the create with STATUS_REPARSE. While adjusting the reparse tag's unparsed-name length it reads the last character of the name's final component without checking for an empty one. Here FinalComponent.Buffer == NULL and Length == 0, so the read hits 0 + 0 - 2 = 0xFFFFFFFFFFFFFFFE.

So the user-mode trigger is a NtCreateFile whose path falls under a bind mapping and has an empty final component (e.g. a name ending in \). The exact path is not recoverable from the minidumps (trap frame holds only volatile registers; the callback data is not in the dump). The test suite does ordinary file I/O via std::filesystem, std::fstream and CreateFileW.

Why this differs from #94454

• Different function: BfPreCreate (file open) vs BfMergeEnumerationContexts (directory enumeration).
• No race with VM session creation needed: crashes 2 to 4 happened 20 minutes to 3.5 hours after the last session was created. The mapping simply being present appears sufficient; the test suite's file opens then hit the bug.
• The crashing process is an ordinary user application, not an MCP extension under %APPDATA%\Claude.
• Windows 11 24H2 (26100), not Windows 10.

Other things ruled out

• CPU affinity: one of the four crashes followed a SetProcessAffinityMask call on the test processes; the other three had no affinity change.
• Other concurrent Claude Code sessions: present during crashes 1 and 4, absent during 2 and 3.
• Claude Code's own process sandbox: no bindflt/bindlink references in the CLI or desktop package binaries; no bindfltapi.dll loaded in any claude.exe.
• Hardware/RAM: faulting address is a deterministic -2, same instruction four times.