File Explorer keeps crashing? Find the trigger before you repair Windows

Do not wipe out the best clue

Explorer crashes often look alike after the window disappears. The action just before the crash is what makes the case useful. A context-menu extension, a preview handler, an unreachable network location, and a wider Windows shell failure can all close an Explorer window, but they do not call for the same fix.

Skip registry cleaners, package re-registration scripts, mass cache deletion, and “disable everything” advice. Those steps change several variables at once. If the crash involves a removable drive, a cloud folder, a mapped drive, or files you cannot replace, stop repeated testing until the data path is safe.

Match the crash to one pattern

Start with the description that fits what you can reproduce:

• Explorer will not open at all. Pressing Windows key + E does nothing, or a window appears and closes immediately.
• Explorer opens, then crashes in a loop. The desktop or taskbar may blink as explorer.exe restarts.
• Right-click causes the crash. The trigger may be every item, one file type, the desktop, or one navigation-pane location.
• Preview or thumbnail view causes the crash. Note the file type and whether Details or List view stays stable.
• One folder or drive causes it. Other local folders work, but one path hangs or closes Explorer.
• A cloud or network path causes it. The failure appears only in a sync folder, mapped drive, network share, or disconnected location.
• The whole shell is affected. Start, the taskbar, desktop icons, or the signed-in session fail with Explorer.

If one application freezes while Explorer and the rest of Windows remain responsive, use the app-not-responding guide. If the pointer, keyboard, audio, and every window stop together, start with the whole-system freeze guide.

Build a small crash evidence card

Write down these details before a restart changes the timeline:

• the exact clock time of the crash
• Windows edition, version, and OS build
• the action that triggered it and the full affected path
• whether it happens with every item or one file type
• whether Preview, thumbnails, or the context menu was open
• whether the taskbar, Start, or desktop also restarted
• recent Windows, cloud-client, archiver, security, graphics, storage, or shell changes
• the Application log entry or reliability report at the same time, including the faulting application and module if shown

Crash logs can contain user names, file paths, device names, and account details. Collect only what you need, and review it before sharing it.

Use one normal restart as a clean comparison

Microsoft’s supported first steps for File Explorer not opening are to install available Windows updates and restart the device. Save your work, restart once, and repeat the same small test. A one-time recovery tells you the symptom cleared for now. It does not prove what caused it.

If the crash returns, stop cycling Explorer or rebooting over and over. Preserve the new crash time and continue with the matching trigger branch. Do not jump straight from “restart did not hold” to a Windows reset.

If right-click or Preview triggers the crash

Microsoft documents shell extension handlers as in-process components that load inside Explorer. A crash or hang in one of those handlers can take Explorer down with it. That makes a repeatable right-click, file-type, thumbnail, or Preview trigger meaningful evidence, but it does not name the responsible extension.

Start with inventory. Microsoft Sysinternals Autoruns can list Explorer add-ons, shell extensions, codecs, services, and other auto-start locations. Save the relevant entries, publishers, file paths, versions, and timestamps before changing anything.

If the crash began after one app added a context-menu, preview, archive, sync, security, or media component, test only the narrow item supported by the timing and trigger. Keep a record so you can restore it. If you cannot identify one candidate, use a controlled clean boot instead of guessing through the registry.

If only one folder, drive, cloud path, or share fails

Compare a known-safe local folder with the failing path. Do not copy, move, rename, delete, or repeatedly enumerate the affected data just to make the crash happen again.

• One local folder: record the view mode, file types, recent additions, and whether Preview changes the result.
• One internal or external drive: note unusual sounds, disconnects, storage warnings, and whether another safe folder on that drive works. Stop if the data may be at risk.
• One cloud location: save the sync-client status, account scope, and whether the item is local, online-only, or still syncing. Do not unlink the account before you know which files are actually stored on the PC.
• One network path: record the share name, connection state, whether other users or paths are affected, and whether the computer is managed. Avoid credential, offline-file, or mapping changes without the owner or administrator.

If low space or unexplained storage growth is part of the problem, use the Windows storage accounting guide before deleting anything.

Separate an Explorer window crash from a shell failure

Explorer also participates in the desktop shell. If the taskbar and desktop disappear with the window, record whether they return on their own and whether Start still opens. A black desktop after sign-in belongs in the black-screen session guide. A taskbar-only problem and a Search-only problem have their own narrower paths.

Do not assume that every explorer.exe event means the same layer failed. The trigger, faulting module, affected Windows surfaces, and recent change still decide the next test.

Use clean boot as a temporary isolation test

A clean boot starts Windows with essential drivers and startup programs so you can test whether another service or startup item is involved. It is useful when the crash is repeatable but no single extension or app has earned a focused test.

Follow Microsoft’s clean-boot steps exactly: hide Microsoft services, record what you disable, expect some features to stop temporarily, and restore normal startup afterward. If Explorer works in clean boot, Microsoft recommends re-enabling items in groups to isolate the conflict. Do not leave the PC in a reduced startup state and call the problem fixed.

Run DISM and SFC only after narrower checks

System-component repair is reasonable when Explorer fails broadly and the trigger matrix, current updates, restart, and controlled isolation do not explain it. Microsoft’s current sequence runs DISM before sfc /scannow. Let each command finish and save the exact result.

“No integrity violations,” “files repaired,” and “files could not be repaired” are different outcomes. Even a successful repair does not prove that damaged Windows files caused the crash. Retest the same action and compare the result.

Do not manually replace protected system files from another computer based on a generic guide. That path requires exact version matching and belongs with qualified support.

Keep reset and reinstall as late recovery choices

Microsoft lists PC reset as a later option when Explorer still will not open. Before that step, back up important data, save the trigger evidence, confirm the affected scope, and understand what the selected recovery option keeps and removes.

A reset can make Explorer open again without telling you whether the original cause was an extension, a cloud path, a drive, a profile, a managed policy, or damaged system files. If the crash involves one data location, solve the data-risk question before starting system recovery.

Choose the next step from the trigger

• No-open or immediate close: save the build and crash time, update Windows, restart once, then check the matching Application event.
• Right-click, Preview, or one file type: inventory shell extensions and handlers before one controlled isolation test.
• One folder or drive: protect the data and stop repeated access if storage symptoms appear.
• Cloud or network path: preserve sync, connection, account, and administrator context before unlinking or remapping anything.
• Explorer plus Start, taskbar, or desktop: treat it as a wider shell or session problem, not just a folder window.
• Broad failure after narrower checks: use clean boot, then component repair, and keep reset for the end.

Where OmniMend fits

OmniMend can help collect and organize the trigger, affected path, Windows build, crash time, recent changes, and results from one reversible comparison. It does not delete extensions, unlink storage, reset Windows, or guarantee that a crash can be repaired automatically.

The OmniMend help article library keeps Explorer, Search, black-screen, storage, application, and whole-system problems in separate evidence paths so one symptom does not trigger an unrelated repair.