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

## Summary
Windows kernel crash (BSOD, stop code 0x50 / PAGE_FAULT_IN_NONPAGED_AREA) occurring
3 times within ~1 hour, each time correlated with Cowork VM Service (cowork-svc.exe)
starting a new VM session. `!analyze -v` on the kernel dump points to a race condition
inside Windows' own `bindflt.sys` driver (`bindflt!BfMergeEnumerationContexts`), with
`python.exe` as the faulting process.

## Environment
- Claude Desktop: 1.52386.6.0 (Windows, x64)
- OS: Windows 10, build 19041.1 (KB5126256 batch installed 2026-09-09)
- Hyper-V: fully disabled; only `VirtualMachinePlatform` optional feature enabled
- Trigger: installing/connecting a Blender MCP extension (community `blender-mcp`,
launched via `uv run blender-mcp`) while Claude Desktop / Cowork was active

## Timeline (2026-09-15, all times local UTC+8)
- 11:25:06 CoworkVMService starts → 11:25:27 BSOD
- 11:35:42 CoworkVMService starts → 11:36:09 BSOD
- 12:19:22 CoworkVMService starts → 12:19:38 BSOD

Each crash happens 15-25s after `cowork-service.log` shows:
`Warning: failed to configure recovery actions (a crashed service will stay down
until reboot): open service: Access is denied.`
(this warning itself appears benign - logged on every service start since 2026-09-04
without incident - but the timing is a reliable marker of the crash window.)

## Suspected structural cause
The MCP extension's launcher sets its working directory **inside the same tree
Cowork bind-merges**:
```
cd /d "C:\Users\\AppData\Roaming\Claude\Claude Extensions\ant.dir.gh.blender.blender-mcp"
uv.exe run blender-mcp
```
`cowork-service.log` shows Cowork creating a VM session for the same root:
`Created new VM session for :C:\Users\\AppData\Roaming\Claude`

`uv run` performs directory enumeration (project discovery, venv check) in that
directory at startup. When this races against Cowork's `bindflt` merge-mount setup
for the same tree, `bindflt!BfMergeEnumerationContexts` dereferences a bad/freed
pointer and crashes the kernel - this is a bug in `bindflt.sys` itself, not in the
extension, but the concurrent-access pattern appears to be specifically induced by
how Cowork extensions are launched from within its own merged directory.

## !analyze -v key output
```
PAGE_FAULT_IN_NONPAGED_AREA (50)
Arg1: ffffc78aa633c42c (bad address, Read)
Arg3: fffff8075eb6b0a6 (faulting instruction)

PROCESS_NAME: python.exe
FAILURE_BUCKET_ID: AV_bindflt!BfMergeEnumerationContexts
MODULE_NAME: bindflt
IMAGE_NAME: bindflt.sys

STACK_TEXT:
nt!KeBugCheckEx
nt!MiSystemFault+0x1b70a3
nt!MmAccessFault+0x400
nt!KiPageFault+0x36d
bindflt!BfMergeEnumerationContexts+0xba
bindflt!BfPreDirectoryControl+0x550
FLTMGR!FltpPerformPreCallbacksWorker+0x36c
FLTMGR!FltpPassThroughInternal+0xca
FLTMGR!FltpPassThrough+0x541
FLTMGR!FltpDispatch+0x8b
nt!IofCallDriver+0x55
nt!IopSynchronousServiceTail+0x361
nt!NtQueryDirectoryFileEx+0xaf
```

## Possibly related
Community reports (Reddit r/Anthropic, r/ClaudeCode, and this repo's issues) mention
Cowork VM service failing to start / losing disk access after a Windows update
released around 2026-09-08, reportedly acknowledged by Anthropic as a
Microsoft-side regression under investigation. This crash may be a more severe
manifestation of the same underlying interaction, now with a concrete kernel-level
root cause. Haven't independently cross-checked those specific threads, flagging
for the team to correlate.

## Request
Could the Cowork team take a look at whether extension processes should avoid
enumerating directories inside Cowork's own bind-merged path while a VM session is
being created/torn down? Happy to provide the full raw `!analyze -v` output or the
kernel dump if useful.