File Explorer Crashing or Freezing in Windows 11/10?

File Explorer crashing the moment you type into the search box is almost never the search feature's fault — it is Windows killing and restarting explorer.exe because something feeding it results (the search index, a corrupted profile folder, or a third-party context-menu add-in) just threw an error. The fix that actually works is to find which of those three is misbehaving, not to keep re-searching and hoping.

Here's what's actually happening under the crash. Explorer.exe isn't one single fragile program — it's the process that draws your desktop, taskbar, and every file window. When a search kicks off, Explorer hands the query to the Windows Search service and waits for results to stream back. If that handoff throws an unhandled error — a damaged index, a shell extension that can't parse the result set, a profile folder with broken permissions — Windows doesn't let the whole OS lock up. It kills the Explorer process and immediately relaunches it. That's the "crash," and it's a deliberate self-healing behavior, not a system failure.

That distinction matters because it tells you where to look. You're not chasing a mystery bug; you're chasing whichever of three things is feeding Explorer bad data the moment a search starts.

Windows 11: rebuild the index first

On Windows 11 25H2, the search index is far and away the most common cause. Here's the sequence, in order:

Step 1: run the built-in troubleshooter

Settings > System > Troubleshoot > Other troubleshooters > Search and Indexing > Run. It's easy to dismiss as a placebo, but it does check for one real thing that isn't obvious anywhere else: whether the Windows Search service itself has stopped responding, separate from index corruption.

Step 2: rebuild the index

Press Win + R to open the Run box — a small "type a command and hit enter" window that skips having to click through Settings menus. Type control /name Microsoft.IndexingOptions and press Enter. Click Advanced, then Rebuild. This deletes the entire index and regenerates it from scratch, which on a large drive can take a couple of hours in the background — you can keep using the PC while it runs.

Windows 11's right-click menu trap

If your next move is going to be disabling a shell extension (below), you'll hit this immediately: Windows 11's right-click menu is condensed down to a handful of icons. The full legacy menu — where "Open with" and other classic options live — is hidden behind Show more options at the bottom of that shortened menu (or press Shift+F10 to jump straight to it). Almost nobody documents this, and it's the single most common reason people give up on a "right-click and select…" instruction halfway through.

When the rebuild doesn't fix it

If Explorer still crashes on search after a full index rebuild, the problem isn't the index. It's one of two things:

A third-party shell extension

Some programs install add-ins that hook into every Explorer window — cloud-sync clients, old antivirus context menus, disc-burning tools, some Adobe installers. When search results appear, Explorer asks every installed shell extension how it wants to draw a preview icon for each result, and a broken one can crash the whole process. A free tool called ShellExView from NirSoft lists every installed shell extension and lets you disable them one at a time without uninstalling the program — disable anything non-Microsoft, test search, and re-enable them in batches until the crash comes back.

A corrupted user profile

This is the one the original version of this guide landed on back in 2017, and it's still valid today for the same reason: your Windows profile folder stores per-user settings for how Explorer renders search results, and if that folder gets damaged, every search crashes regardless of the index's health. Creating a new local user account and moving your files over sidesteps the damaged settings entirely rather than fixing them — which is exactly why it worked.

Which fix matches your situation

Windows 10: the same fix, one extra step

On Windows 10, the index rebuild and the shell-extension check work exactly the same way — the Run box command, the Advanced > Rebuild path, and ShellExView all behave identically. The one difference: Windows 10's right-click menu was never condensed, so you won't hit the "Show more options" trap above.

The cases that don't fit the pattern

It only crashes when searching a specific external or network drive. That drive likely isn't included in the search index at all — unindexed locations get searched "live," which is slower and far more crash-prone on large drives. Add the drive under Indexing Options > Modify if you search it often; otherwise expect live search there to be fragile and use it sparingly.

It crashes specifically opening the Downloads or Quick Access view, not a typed search. This is usually a corrupted entry in your Quick Access recent-files history, not the search index at all. Open Explorer's ribbon > View > Options > General tab > Privacy section > Clear, which wipes the recent/frequent history Quick Access is trying to render.

It only crashes searching for one specific file type — PDFs, say. Content indexing for a file type depends on that app's "iFilter" being registered correctly. Reinstalling the app that owns that file type (a PDF reader, for instance) usually re-registers its filter and fixes search for that type specifically, without touching anything else.

If you're on Windows 11 or 10 Home

Some older guides for this problem tell you to adjust search behavior through Group Policy Editor (gpedit.msc) — a settings tool with far more granular options than the regular Settings app, built into Windows for managing shared or business PCs. It only exists on Pro, Enterprise, and Education editions. If you're on Home and gpedit.msc won't open, everything in this guide above still applies without it; you never needed it for the index rebuild or the shell-extension check.

The next question: how do you know it's actually fixed?

Once search stops crashing, the natural next worry is whether it'll come back next week. You don't have to wait and see — Windows already keeps a record. Press Win + R, type perfmon /rel, and press Enter. That opens Reliability Monitor, a day-by-day graph of every application crash on the machine going back weeks. Look for red "X" markers labeled Windows Explorer — if the graph is clean from the day you applied the fix onward, it's actually fixed, not just quiet for now.

If you want the exact technical cause rather than just confirmation, Event Viewer has it. Open Event Viewer, go to Windows Logs > Application, and filter for Source "Application Error." Each Explorer crash logs an entry naming the faulting module — if that's explorer.exe itself, it points back to the index or profile; if it names a different .dll, that DLL belongs to whichever shell extension is actually at fault, which narrows down the ShellExView search considerably.

Automating this, if you manage more than one PC

If this is a machine you're responsible for — a shop PC, a family member's laptop you support remotely — it's worth setting up an early-warning system instead of waiting for the next complaint.

Turn the crash log into an alert

Task Scheduler can trigger directly off the same Event Viewer entry described above. Open Event Viewer, find one of the "Application Error" events for explorer.exe, right-click it, and choose Attach Task to This Event. Walk through the wizard and point the action at sending an email or displaying a message. From then on, a repeat crash on that PC notifies you the same day instead of whenever the person finally mentions it.

Don't automate the index rebuild itself

It's tempting to schedule a monthly index rebuild as preventive maintenance. Don't — a healthy index doesn't need rebuilding, and doing it on a schedule just means the machine spends hours re-indexing for no reason while search is temporarily slower. Rebuild reactively, when a crash actually points at the index, not on a calendar.

FAQ

Will rebuilding the index delete my files?

No. The index is just a searchable catalog of file names and content, kept separately from the files themselves. Rebuilding it only means searches are slower until it repopulates.

Why does it only crash on search and not when I just browse folders?

Browsing a folder only asks Explorer to read that one folder's contents. Search asks it to combine live results from the index, several running shell extensions, and (for unindexed locations) a live disk scan all at once — more moving parts means more chances for one of them to throw an error.

Is this the same as Explorer being generally slow or laggy?

No — general sluggishness is usually a resource or driver issue and has its own set of fixes. This guide covers Explorer actually closing and reopening during a search, which is a distinct crash-and-restart event you'll see reflected in Windows' Reliability Monitor.

How do I know which shell extension is the problem?

ShellExView disables them one at a time (or in batches, using a binary-search approach if you have many installed) so you can isolate the exact one without uninstalling anything. Event Viewer's faulting-module name will often point you straight at it, too.

Do I need to reinstall Windows?

Almost never for this. A profile recreation is a much smaller, faster step than a full reinstall, and it's rarely needed once you've ruled out the index and shell extensions first.

Can I search without triggering the crash at all, as a workaround?

Searching from the Start menu's search box, rather than inside an open Explorer window, uses a different results pane and can work even while Explorer's own search is crashing — useful as a stopgap while you work through the fixes above.

Does this happen more often on OneDrive-synced folders?

Yes, somewhat — cloud-sync clients add their own shell extension to every Explorer window to draw those sync-status icons, and a stuck or outdated sync client is a common contributor. It's worth disabling the sync client's shell extension specifically in ShellExView as an early test.

Can antivirus software cause this?

It can, particularly older or third-party antivirus suites that add their own scan/context-menu shell extension. Temporarily disabling that specific extension in ShellExView (not the antivirus itself) is a safer test than turning off real-time protection.

Will a Windows Update eventually fix this on its own?

Occasionally — Microsoft does patch specific Explorer crash bugs in cumulative updates from time to time. But a recurring crash tied to your specific index, profile, or installed software won't resolve itself just by waiting for updates; it needs one of the steps above.

Does Safe Mode help me figure out the cause?

Yes — it's a genuinely useful diagnostic. Safe Mode loads Windows with third-party drivers and startup extensions disabled. If search doesn't crash in Safe Mode, that confirms a third-party shell extension as the cause rather than the index or a system file.

Is there a log I can check for the exact cause?

Yes — Event Viewer, Windows Logs > Application, filtered for Source "Application Error." Each entry for explorer.exe names the specific faulting module, which tells you whether to look at the index/profile or at a specific shell extension's DLL.

Should I be worried this is malware?

Repeated Explorer crashes on their own aren't a typical malware symptom — malware more often hides its presence rather than causing visible crashes. If you're concerned, a scan with your existing antivirus is a reasonable check, but the fixes above address the far more common legitimate causes first.

Revision note. Originally published March 21, 2017, back when Windows 10 was new and the fix we found — a fresh user account — genuinely worked. It still does, for the same reason it did then: profile corruption is profile corruption, on any version of Windows. What's changed since is that the index-rebuild path and the shell-extension check now catch most cases before you'd ever need to touch a user account at all, so we've put those first. If you landed here mid-crash with something important open, we hope you got it back before you needed to close the tab.