Microsoft published a Windows quality update late last week with a notable admission buried in the details: File Explorer needs foundational architectural improvements. A candid admission for a company that typically describes quality work in neutral terms. They’re committing to reducing hangs, improving responsiveness, and making Explorer “loved”, and that’s genuinely welcome news, but long overdue.
Windows Explorer — not the browser, but the shell, the file picker, the thing that opens every time you double-click a file or try to attach something to an email — is the most-used component in the OS. It touches every workflow, every day, for every Windows user.
And it’s been quietly unreliable for years. Here’s why, and what you can do about it today while Microsoft works on the fix.
What Actually Happens
You know this feeling. You’re attaching a file to an email. The file picker opens. You navigate to a folder. Nothing. The spinning blue circle appears. Five seconds. Eight seconds. You click somewhere else. Explorer hangs. You wait. Or you force-quit and start over.
Or you double-click a download. Nothing happens for six seconds. Then the file opens.
Or you right-click on the desktop and the context menu takes four seconds to appear — because something injected into the shell is doing something you didn’t ask it to do.
Or Explorer crashes entirely. The desktop goes black for a moment. The taskbar disappears. Then everything reappears, and you have no idea what just happened or why.
These aren’t edge cases. They’re daily occurrences for Windows power users. And they add up to a significant, measurable productivity drain.
The Full Picture: What Goes Wrong with Explorer
The failure modes fall into a few categories:
File system and browsing
- Spinning blue circle / “Not Responding” on folder open
- Slow or hanging file picker in open/save dialogs — affects every application
- Delayed right-click context menu (3–10 second wait)
- Thumbnail generation hanging on large folders or corrupt files
- Network path resolution delays bleeding into local Explorer performance
- Slow directory enumeration on folders with 100,000+ files
- Address bar becoming unresponsive mid-navigation
- File copy and move operations hanging mid-transfer, “Calculating time remaining” spinning indefinitely
Shell extensions and third-party hooks
- Overlay icon conflicts — OneDrive, Dropbox, Git clients, and antivirus all competing for the same limited overlay slots
- Context menu handlers loading synchronously, blocking the entire UI thread
- DLL injection from third-party tools causing sustained high CPU spikes
- Explorer memory leaks from poorly written shell extensions — process grows significantly over days without a restart
- Crash loops — Explorer crashes, auto-restarts, crashes again
- Shell extensions deadlocking on file access, causing the entire shell to freeze
CPU and memory
- Explorer consuming unexpectedly high CPU at idle due to background shell extension activity
- Memory growth over time without a restart, degrading overall system performance
- High disk I/O from thumbnail caching and Windows Search indexing conflicts
- SearchIndexer interaction causing Explorer to slow mid-browse
User-visible symptoms
- Spinning blue circle (pre-hang indicator) appearing constantly during routine tasks
- Desktop going black when Explorer crashes and auto-restarts
- Taskbar freezing when the Explorer process hangs — keyboard shortcuts stop working
- Start menu becoming unresponsive (it runs inside the Explorer process)
- File associations breaking temporarily after an Explorer crash
- The persistent, maddening impression that Windows itself is slow
Why Explorer Is Uniquely Vulnerable
Windows Explorer isn’t just a file manager. It’s the Windows shell — the host process for the desktop, the taskbar, the file picker, the context menu, and dozens of other UI surfaces. It’s also one of the most extensible components in the OS.
That extensibility is both its strength and its Achilles heel.
Shell extensions are COM objects that register themselves into Explorer’s process space. Every time you install Dropbox, OneDrive, 7-Zip, a PDF viewer, an antivirus, a version control client, or dozens of other third-party tools, they inject DLLs directly into the Explorer process. These DLLs run in-process, with full access to Explorer’s memory and execution context.
To be fair to the teams in Redmond, maintaining 30 years of backward compatibility while allowing virtually any third-party application to hook into the UI is an architectural tightrope walk that few other operating systems even attempt.
When one of those DLLs has a bug — a deadlock, a memory leak, an unhandled exception — Explorer pays the price. Not the third-party tool. Explorer.
Explorer hangs, crashes, or slows to a crawl, and you have no idea which shell extension caused it. The Windows Event Log might give you a DLL name if you know where to look. Most users don’t.
The Usual Suspects
Shell extensions that commonly cause Explorer instability:
- Cloud storage clients (OneDrive, Dropbox, Google Drive) — overlay icons and sync status checks run on every file system access
- Antivirus and security software — real-time scanning hooks into every file open, creating synchronous latency
- Version control clients (TortoiseSVN, TortoiseGit) — overlay icons per-file, expensive on large directories
- Archive managers (7-Zip, WinRAR) — context menu extensions that load on every right-click
- PDF and document viewers — thumbnail generators that can deadlock on corrupt files
- Screenshot and screen recording tools — shell hooks that monitor window state
- Old or orphaned shell extensions — registered by software that was uninstalled years ago but left COM registrations behind
Two I’ve dealt with personally
Two tools I had to deal with directly: Adobe Acrobat and SnagIt.
Adobe Acrobat registers shell extensions for PDF thumbnail generation, preview, and context menu entries. On machines with large directories containing PDF files, this alone can cause Explorer to hang noticeably on folder open. I’ve seen right-click menus take 5+ seconds on folders with Acrobat installed. Removed the shell extension via ShellExView, problem gone immediately. Acrobat’s shell integration issues aren’t new, either. I wrote about one of its more persistent quirks back in 2019: Adobe’s perpetual confusion between Save and Save As. They fixed it, then quietly brought it back.
SnagIt (TechSmith) is a productivity tool that ironically degraded my productivity through its shell hooks. The SnagIt printer and capture hooks register into Explorer’s process space. Less notorious than Acrobat but just as real. Disabling the SnagIt shell extension was one of the first things I did on a fresh Windows install.
These tools are industry standards for a reason. They offer deep integration. But in a synchronous environment like the current Explorer, even the best-intentioned features can become bottlenecks. They accumulate, they conflict, and they run synchronously in a process that was never designed to host dozens of third-party DLLs.
The Perception Problem
This is the most damaging part.
When Explorer hangs, users don’t think “a third-party shell extension is deadlocking the UI thread.” They think “Windows is slow.” There’s no error message. No indication of cause. No remediation path visible to a normal user. The OS takes the blame for a DLL Microsoft didn’t write.
And the fix — auditing COM registrations, disabling shell extensions, checking Event Viewer for faulting module names — is completely invisible to most users. It requires tools most people have never heard of and knowledge that takes years to accumulate.
So they reinstall Windows. Or they switch platforms.
The irony is that a freshly installed Windows with no third-party software runs Explorer reliably. The problem accumulates over time as software installs layer shell extensions on top of each other. By the time the system feels unusably slow, there’s no obvious path back.
This is one of the most significant reasons Windows has a reputation as a slow, bloated, legacy platform. Not because the OS itself is fundamentally broken, but because its extensibility model makes it uniquely vulnerable to third-party quality problems, and there’s no feedback mechanism that tells users what went wrong.
Practical Fixes
1. Audit and disable non-essential shell extensions
ShellExView (NirSoft, free) is the best tool for this. It lists every shell extension registered on your system, shows which ones are currently loaded in Explorer, and lets you disable them individually to isolate the culprit. Start by disabling overlay icon extensions from cloud storage clients — these are the most common cause of sustained Explorer slowness.
2. Check the Windows Event Log for the faulting module
Open Event Viewer → Windows Logs → Application. Filter for events with source “Application Error” where the faulting application is explorer.exe. The faulting module name is the DLL that caused the crash — that’s what to target for removal or update.
3. Use Process Monitor to catch hangs in real time
Sysinternals Process Monitor captures every file system and registry access Explorer makes. Filter by explorer.exe and sort by duration. Long-running operations with no result are your hanging shell extensions. This is the most precise diagnostic available.
4. Restart Explorer without rebooting
When Explorer hangs, you don’t need to reboot. Open Task Manager, go to the Details tab, right-click explorer.exe, and select End Task. Then use File → Run new task, type explorer, and click OK. This restores the shell cleanly and clears accumulated memory leaks without losing your work in other applications.
# Restart Explorer from PowerShell
Stop-Process -Name explorer -Force
Start-Process explorerThe Bigger Picture
Microsoft is finally naming the problem publicly. “Foundational architectural improvements” is candid language for a company that typically describes quality work in neutral terms. The acknowledgment that Explorer needs to be made “loved,” not just functional, signals they understand the reputational damage this has caused.
That’s meaningful. Public acknowledgment matters because it sets expectations and creates accountability. But architectural improvements take time and ship incrementally. The root cause: 30 years of extensibility decisions that allowed third-party DLLs to run in-process inside the shell. That’s not something a few updates will fully resolve.
In the meantime, the tools and fixes in this post are the practical path to a more stable Explorer today. Audit your shell extensions, disable what you don’t need, and know where to look when things go wrong. Microsoft is working on the foundation. You can improve what’s running on top of it right now.