Main process crash closes all windows: access violation in unloaded explorerframe.dll (BEX64, 0xc0000005), recurring since June 2026

## Summary

The VS Code **main process** crashes with an access violation in an **unloaded** `explorerframe.dll`, closing all open windows at once. This has happened 8 times since 2026-06-21 on this machine (roughly weekly, sometimes in clusters), always with the identical WER signature. The crash typically fires while the app is idle, ~10–13 minutes after the last user interaction.

## Environment

- VS Code: 1.128.0 (user setup), commit `fc3def6774c76082adf699d366f31a557ce5573f`, x64
- OS: Windows 11 Home 10.0.26200
- Faulting module per WER: `explorerframe.dll_unloaded`, version 10.0.26100.8737
- No shell customization tools installed (no ExplorerPatcher / StartAllBack / Start11)

## Crash signature (Windows Event Log, ID 1000, 2026-07-11 16:03:20)

```
Faulting application name: Code.exe, version: 1.128.0.0, time stamp: 0x6a303f3f
Faulting module name: explorerframe.dll_unloaded, version: 10.0.26100.8737, time stamp: 0xe30a4fb1
Exception code: 0xc0000005
Fault offset: 0x000000000007423e
Faulting application path: C:\Users\...\AppData\Local\Programs\Microsoft VS Code\Code.exe
```

WER event 1001: `EventType=BEX64`, P9=`0000000000000008` (DEP/execute fault → call into unmapped code of the unloaded DLL). A minidump exists in the local WER ReportArchive (bucket hash `4eb42ab45b0dc90a686347c1439e83d5`, report ID `e238626e-f7dc-4532-9cf3-9440009ba32d`); I can attach it on request.

## Occurrence history (all BEX64, c0000005, explorerframe.dll_unloaded)

| Date | Fault offset |
|---|---|
| 2026-06-21 | 0x73a6e |
| 2026-06-22 | 0x73a6e |
| 2026-06-23 | 0x73a6e |
| 2026-06-28 | 0x7423e |
| 2026-06-29 | 0x7423e |
| 2026-07-07 (2×) | (report not readable, same AppCrash bucket family) |
| 2026-07-11 | 0x7423e |

`explorerframe.dll` was serviced by a Windows update on 2026-06-24; the fault offset changed accordingly (0x73a6e → 0x7423e) and the crash persisted across DLL versions.

## Analysis

- `_unloaded` means code was executed inside a DLL image that had already been unmapped. `explorerframe.dll` hosts the common file dialog / shell UI that gets loaded into the main process.
- In the latest crash, the last user activity in `main.log` was at 15:50 and the crash hit at 16:03 — consistent with COM's delayed free of unused libraries (`CoFreeUnusedLibrariesEx`, ~10 min). This suggests a dangling callback / window subclass / timer that still points into `explorerframe.dll` after COM unloads it, e.g. left over from an `IFileDialog` use.
- Ruled out on this machine: `Start_TrackDocs=0` (it is set to 1 and crashes continue), third-party shell extensions of the ExplorerPatcher family (not installed).
- Possibly OS-side rather than VS Code-side: there are reports of `explorerframe.dll` faults in file pickers of other apps on current Win11 builds (e.g. https://learn.microsoft.com/en-us/answers/questions/2805633/explorer-crashes-due-to-explorerframe-dll). Filing here for triage since the VS Code main process is the victim and takes down all windows/sessions with it.

## Steps to reproduce

No deterministic repro. Pattern: long-lived VS Code instance with several windows, use of a native file dialog, then idle ~10 minutes → intermittent crash of the entire application.

---
_Diagnostics for this report were collected with the help of Claude Code (event log, WER archive, VS Code logs)._