Everything Preview Handler Crashes Everything: How to Fix It

When selecting a file in voidtools Everything causes the preview pane to freeze, disappear, or crash the entire application, the search index is not necessarily broken. Everything finds filenames using its own indexes, but it relies on Windows preview handlers to render many file types. A damaged, incompatible, or slow handler can therefore crash Everything even while search itself continues to work correctly.

The most likely causes fall into a few categories: a file type-specific Windows preview handler, a third-party shell extension, an inaccessible network file, permissions under the current account, a problematic portable configuration, or an Everything setting that makes the symptom appear broader than it is. The safest approach is to reproduce the problem with a harmless file, isolate the affected file type, and change one setting at a time. Once previews work reliably, stop troubleshooting rather than rebuilding unrelated components.

1. Confirm the Symptom With a Small Safe Test

Start by determining whether previewing is the trigger. This distinction matters because Everything search and the Windows preview system perform different jobs. Everything builds and searches a filename index. The preview pane asks an installed Windows preview handler to open and render the selected file. Search can work perfectly while a preview handler fails.

1.1 Test a harmless text file

Create a small plain-text file in a local folder that you control, such as your Documents folder. Give it a simple name, add one line of text, and save it with the .txt extension. Search for the file in Everything and select it while the preview pane is visible.

Success means the file appears in the preview pane without a long delay, a freeze, or an application crash. If text previews work but selecting a PDF, image, archive, Office document, media file, or design file causes a crash, the failure is probably specific to that file type or its registered preview handler. Stop changing index settings at this stage because the index has already found the file successfully.

1.2 Turn off the preview pane for comparison

Temporarily disable the preview pane from Everything's View menu, then repeat the search and select the file that previously triggered the crash. Do not open the file. Merely select it and move through the result list.

If Everything remains stable with the preview pane disabled, the strongest suspect is the Windows preview path rather than filename indexing. Leave previews disabled temporarily if you need Everything to remain usable while investigating. This is a diagnostic workaround, not proof that every preview handler is defective.

If Everything still crashes with previews disabled, investigate other selection-related shell features, the specific file's location, the active configuration, and application logs. The problem may not be a preview-handler failure.

1.3 Identify the smallest repeatable pattern

Record exactly what causes the failure. Useful observations include:

• Only one file crashes the application.
• Every file with one extension causes a crash.
• Only files on a NAS or mapped drive fail.
• The first preview works, but moving rapidly through results causes a freeze.
• The installed build fails, while a clean portable test does not.
• Windows File Explorer also fails when previewing the same file type.

A repeatable pattern prevents unnecessary changes. If one malformed file is responsible, quarantine or replace that file instead of modifying Everything globally. If every PDF causes the issue, focus on the PDF preview provider. If only network files fail, test connectivity and account context before touching local preview handlers.

2. Check Everything Settings Directly Related to the Problem

Everything options can affect whether results appear and which locations are indexed, but they generally do not implement the preview renderer for third-party formats. Check settings that can explain the observed behavior without assuming that every crash is an index problem.

2.1 Verify the preview pane and active view

Toggle the preview pane off, close Everything normally, reopen it, and confirm that the problem file can be selected safely. Then enable the pane and test the harmless text file before selecting the problem format.

Success means the application remains stable with previews off and fails only when the affected format is rendered. At that point, stop changing search filters, indexes, or services. They are not the leading cause.

2.2 Clear search options and filters

If Everything results are missing as well as previews crashing, clear the search box and select the broadest standard filter, typically Everything. Check whether options such as Match Case, Match Whole Word, Match Path, Match Diacritics, or regular expression mode are enabled. A restrictive filter or search mode can make it seem as though the application stopped searching after a crash or restart.

Run a simple filename search without advanced operators. If the expected local text file appears, basic searching is operational. If it previews successfully too, add the original search syntax and file type back one element at a time.

2.3 Review indexes, exclusions, and result omissions

If a file cannot be found at all, inspect the relevant Everything Options pages for NTFS indexes, ReFS indexes where applicable, folder indexes, and exclusions. Confirm that the volume or folder containing the file is included and not excluded by path or pattern. Also check whether the current search uses syntax or filters that omit the result.

This check addresses Everything results missing, not a crash that occurs after a visible result is selected. Success means the expected file appears in the result list. Once it appears, return to preview-specific testing rather than rebuilding the index immediately.

2.4 Check the service and account context

Everything may use its service to access filesystem metadata and maintain indexes without requiring the main interface to run with elevated rights. Verify in Everything's options and Windows Services that the Everything service configuration matches the way you normally run the application. If the service is stopped unexpectedly, restart it through normal Windows administration controls and retest searching.

A healthy service can correct indexing or update problems, but it does not guarantee that a Windows preview handler can read a selected file. Success at this step means local results update normally after files are created, renamed, or deleted. If selecting a result still crashes the program, continue with preview-handler checks.

2.5 Review portable and command-line behavior

Portable users should confirm which configuration file and executable they are actually launching. A shortcut may specify command-line options, a different instance name, or an unexpected configuration location. Launching multiple instances with different settings can produce confusing differences in indexes, filters, and UI behavior.

For testing, launch the intended executable directly without an old shortcut or custom command-line arguments. Do not overwrite your working portable folder. Success means the same profile opens consistently and the preview behavior is repeatable. If a direct launch works but the shortcut fails, inspect the shortcut rather than altering Windows preview registrations.

2.6 Treat server options separately

ETP, HTTP, or other server-related configurations affect remote searching and access patterns. They are not a routine fix for a local preview-handler crash. If you use remote Everything features, compare a local file with a remote result and determine where the actual file content is read from.

Do not expose an Everything server to the public internet as a troubleshooting step. Keep remote access appropriately authenticated, firewalled, and limited to trusted networks. Success means local searches and previews can be tested independently from remote search infrastructure.

3. Check Windows Preview Handlers and File Type-Specific Crashes

Windows preview handlers are components registered for particular file types. Microsoft provides the preview-handler framework, while applications such as PDF readers, office suites, media tools, email clients, and graphics packages may install their own handlers. When Everything requests a preview, a faulty component can affect the host process.

3.1 Compare the same file in File Explorer

Enable File Explorer's preview pane and select the same harmless local file, followed by a copy of the problem file. Avoid testing an irreplaceable document first. If File Explorer also freezes, shows an error, or cannot preview that format, the issue is likely system-wide or handler-specific rather than unique to Everything.

If Explorer previews the file but Everything crashes, note the difference without assuming the handler is innocent. Hosting conditions can differ between applications. Update or repair the application that installed the relevant handler, and retest after a normal Windows restart if the installer requests one.

3.2 Isolate the affected file type

Test several known-good files with the same extension from a local folder. Do not rely on a single downloaded or partially synchronized file. Then test other common formats such as TXT, JPG, PNG, PDF, and a basic office document if the corresponding software is installed.

• If only one file fails, the file may be malformed, incomplete, encrypted, or unusually large.
• If every file of one type fails, suspect that type's registered preview handler.
• If many unrelated types fail, suspect a shared shell component, security interception, profile issue, or broader system damage.
• If only remote copies fail, test network access and latency.

Success means you can name a narrow failure condition, such as “local TXT and JPG previews work, but all PDFs fail.” Stop broad Everything troubleshooting and repair, update, or remove the implicated preview-providing application through its supported installer.

3.3 Investigate third-party shell extensions carefully

Preview handlers are part of the wider Windows shell-extension ecosystem. Software may add thumbnail providers, property handlers, context-menu extensions, and preview handlers. A recently installed archiver, document viewer, codec package, synchronization client, or file-management utility may be relevant.

Use the application's own repair or uninstall process first. Advanced administrators can use a reputable shell-extension inspection utility to identify non-Microsoft extensions, but they should disable only the specifically suspected component and document the change. Avoid bulk-disabling extensions because doing so makes the result difficult to interpret.

Success means previews work after the implicated extension is repaired, updated, or selectively disabled. Re-enable unrelated components and stop making changes once the crash no longer occurs.

4. Check Permissions, Network Shares, and Security Context

Network previews require more than a filename result. Everything may know that a file exists from an index or remote search source while the current interactive Windows account lacks permission to open its content. Previewing also transfers data across the network, which can expose latency, offline-file, or security-scanning problems that a filename search does not.

4.1 Compare local and network copies

Copy a non-sensitive test file from the share to a local folder, then preview both copies. If the local copy works and the network copy freezes, check the share path, NAS availability, name resolution, credentials, and file locks. Test the UNC path directly if you normally use a mapped drive, because drive mappings can differ between accounts and elevation levels.

Success means the network file opens and previews promptly under the same account that runs Everything. If local previews work reliably, do not rebuild the local Everything index to solve a network access problem.

4.2 Avoid mixed elevation and account contexts

A mapped drive visible in a normal desktop session may not be visible to an elevated process. Conversely, a service account may index metadata that the signed-in user cannot open. Run Everything in its normal recommended context for testing and verify access by opening the file through File Explorer under that same account.

If opening the file requests credentials or returns Access Denied, correct the share and NTFS permissions through normal administrative processes. Do not grant broad access merely to make previews work. Success means the intended user has least-privilege read access to the file and parent path.

4.3 Check firewall and antivirus behavior safely

A firewall can affect NAS or remote-server access, while antivirus or endpoint protection may scan files as preview handlers open them. Review product logs, quarantine history, and recent policy changes. If organizational policy allows a controlled test, use the security product's documented temporary diagnostic procedure or ask the administrator to test a narrowly scoped exclusion.

Never disable security tools permanently or exclude an entire drive without evidence. Success means logs identify a specific block, timeout, or process interaction that can be corrected with a vendor-supported update or narrowly tailored policy.

4.4 Consider filesystem and synchronization state

Files on NTFS, ReFS, removable media, optical media, cloud placeholders, Linux-backed NAS shares, and other network filesystems do not always behave identically. A cloud placeholder may need to download before previewing. A disconnected removable volume may leave an old result visible until the index updates. A NAS may delay while waking disks or generating file data.

Make the test file fully available locally, verify that it opens normally, and wait for synchronization to complete. Success means a complete, readable local file previews without delay. That result points away from Everything itself and toward the storage or synchronization path.

5. Use Diagnostics Without Destroying Useful State

Diagnostics should preserve evidence and separate search-index problems from preview-rendering problems. Do not delete the database as the first response. A preview crash caused by a Windows handler will usually remain after an unnecessary database rebuild.

5.1 Read the status bar and Options pages

Observe Everything's status bar before and after running a simple search. It can help confirm whether results are being returned, whether a search is still processing, and which items are selected. Review the relevant Options pages for indexed volumes, folder indexes, exclusions, services, and interface settings.

Success means the status information matches the expected search and the correct location is indexed. If the result is present and the crash begins only after selection with previews enabled, index diagnosis is complete.

5.2 Use Force Rebuild only for index evidence

A forced rebuild is appropriate when the index demonstrably contains stale or missing filenames and ordinary updates do not correct it. Before rebuilding, confirm the volume is included, exclusions are not responsible, the service is operational, and a simple search syntax test fails.

Force Rebuild is not a primary Everything preview handler crashes Everything fix. Rebuilding can consume time and temporarily remove useful results without changing the preview component. Success after a justified rebuild means newly created and renamed files appear correctly. It does not establish preview stability until you test selection separately.

5.3 Capture debug information and Windows crash records

If the failure is repeatable, use Everything's documented debugging facilities and note the exact steps, file extension, storage location, and time of the crash. Windows Event Viewer and Reliability Monitor may identify a faulting module. A module name belonging to a PDF reader, codec, graphics package, or shell utility is valuable evidence for repair or escalation.

Do not share filenames, paths, network names, or document contents publicly without redacting sensitive information. Success means you have a repeatable case and a relevant module or event that can be supplied to voidtools or the preview-handler vendor.

5.4 Review the Index Journal when results are stale

The Index Journal is useful when troubleshooting how index changes were processed. It may help explain missing or stale results, particularly after volume or service changes. It is not a direct record of what a third-party preview handler did while rendering a file.

Use it only when the problem includes indexing behavior. If the correct result is already shown and selection triggers the failure, prioritize application crash records and handler isolation.

6. Run a Clean Temporary Test Before Changing Many Settings

A clean test determines whether the active Everything profile contributes to the issue. It also protects your established filters, indexes, bookmarks, keyboard shortcuts, and server settings from unnecessary edits.

6.1 Prepare an isolated test

1. Close the normal Everything instance cleanly.
2. Back up its configuration using the documented method appropriate to your installed or portable setup.
3. Use a separate trusted copy or supported instance configuration in a new folder.
4. Do not point the test at public-facing server services.
5. Search for a harmless local text file and enable the preview pane.
6. Test a copy of the affected format from the same local folder.

If the clean instance also crashes on the affected file type, a Windows preview handler or system-level component is the stronger suspect. If the clean instance works, compare settings gradually rather than replacing the working configuration wholesale.

6.2 Change one variable at a time

Start with preview state, then file location, file type, account context, and profile. Keep a short record of each result. Avoid simultaneously reinstalling Everything, rebuilding indexes, changing permissions, removing security software, and disabling shell extensions. Multiple changes can hide the real cause and create new problems.

Success means you can reproduce both a working case and a failing case by changing one variable. Once you have that boundary, apply the smallest durable fix and stop.

7. Quick Fix Checklist

• Disable the preview pane and verify that selecting results no longer crashes Everything.
• Preview a harmless local TXT file to confirm that basic previewing works.
• Test several known-good files to determine whether one extension is responsible.
• Try the same file in File Explorer's preview pane.
• Repair or update the application that installed the failing preview handler.
• Check recently added third-party shell extensions and disable only the suspected component.
• Compare a network file with a local copy under the same Windows account.
• Verify share permissions, mapped-drive visibility, NAS availability, and synchronization state.
• Clear restrictive Everything filters and search options if results are missing.
• Confirm indexed volumes, folder indexes, exclusions, and service state.
• Use Force Rebuild only when there is evidence of a stale or damaged index.
• Run a clean temporary profile test before modifying many settings.
• Review Reliability Monitor, Event Viewer, and debug output for a faulting module.
• Stop when previews are stable and searches update normally.

8. Frequently Asked Questions

8.1 Why does Everything crash when I select a PDF or image?

Everything can ask a Windows-registered preview handler to render the selected file. If the handler installed by a PDF reader, media package, graphics tool, or other application is damaged or incompatible, selecting that file type may destabilize the application. Test multiple files of the same type and compare them in File Explorer before repairing the associated application.

8.2 Does a preview crash mean the Everything database is corrupt?

No. If the filename appears correctly and the crash starts only when the preview pane renders it, the index has already completed its primary job. Rebuild the database only when there is separate evidence of stale or missing indexed results.

8.3 Why do network files appear in results but fail to preview?

A filename index or remote search source can reveal that a file exists without granting the current desktop account permission to read its contents. The share may also be offline, slow, awaiting credentials, or using a mapped drive unavailable to an elevated process. Compare the network file with a local copy and verify access under the same account.

8.4 Can I leave the preview pane turned off?

Yes. Disabling the preview pane is a safe workaround if fast filename search is more important than inline previews. It does not disable Everything's core search capability. You can re-enable previews after repairing the responsible Windows handler.

8.5 What should I do if Everything search is not working too?

Clear the search and active filter, test a simple filename, inspect indexed volumes and folder indexes, review exclusions, and confirm the Everything service state. Check the status bar and Index Journal when results are stale. Treat this as a parallel indexing issue unless it occurs only after a preview-triggered crash.

8.6 When should I report the problem?

Report it when the crash is repeatable after a clean temporary test, particularly if you can identify the affected extension, whether the file is local or remote, and the faulting module recorded by Windows. Include the smallest safe reproduction steps and relevant debug output, but redact private filenames, paths, server names, and document contents.