I've been wrestling with one of the most frustrating bugs I've encountered in a while on Windows 11. The scenario is simple: I'm in an application like VS Code or another editor, I go to File > Open, and the moment the File Explorer dialog appears, the entire application instantly crashes. 💥 No warning, no error message, and worst of all, absolutely nothing is recorded in the Event Viewer. It's as if the app just vanishes into thin air.
When a problem doesn't leave a trace, you start to feel like you're chasing a ghost. My investigation so far has led me down a few different paths.
Prime Suspect #1: Rogue Context Menu Handlers
My first thought was that a third-party application might be injecting a faulty shell extension into the File Explorer process, which would only be triggered when called from another app. The context menu—the menu that appears when you right-click a file—is a common culprit for this kind of instability.
To investigate this, I used Nirsoft's excellent ShellExView tool. This utility lists all the shell extensions installed on your system and allows you to disable them individually. I went through the list and started disabling non-Microsoft context menu handlers one by one to see if I could isolate a problematic one. It's a tedious process of disabling an entry, restarting, and trying to reproduce the crash.
Prime Suspect #2: Network Drives and \\wsl$
Another potential source of the problem could be related to network locations. The File Explorer dialog has to quickly scan and populate all available drives, including mapped network drives and other locations. If it tries to access a location that is slow, unresponsive, or has credential issues, it can sometimes hang or, in a worst-case scenario, cause a crash.
This theory gained some traction when I considered my setup. I use Windows Subsystem for Linux (WSL2) heavily, and Windows provides a special network path, \\wsl$, to access the Linux filesystem directly from File Explorer. It’s an incredibly useful feature, but it has occasionally been known to cause performance issues or hangs in Explorer if the WSL virtual machine isn't running or is slow to respond. It's plausible that the "Open File" dialog was tripping over this special network location.
After disabling some of the more suspect context menu items and unmapping a few network drives, the problem seems to have cleared up. For now.
An Uncertain Resolution
The frustrating part is that I'm not 100% sure which action was the silver bullet. Was it a misbehaving shell extension? Was it the file dialog struggling to access a mapped drive or the \\wsl$ path?
For the moment, my editors are stable again. But without a definitive cause, it feels more like a temporary truce than a permanent fix. I'll be keeping a close eye on it, and if the phantom crasher returns, the investigation will continue. We shall see.