Everything Hangs at Startup: How to Fix It

When Everything hangs at startup, the window may remain unresponsive while the application loads its database, builds an initial index, scans configured folders, or waits for an unavailable network resource. This is different from a crash: Everything remains open but appears stuck, takes unusually long to become usable, or never finishes updating its index. The most common causes are an oversized folder index, an offline network path, a database stored on slow or unavailable storage, a service or permission mismatch, or a damaged configuration. Start with small, reversible tests so you can identify the cause without deleting the database or changing several settings at once.

1. Confirm the Symptom With a Small Safe Test

First, determine whether Everything is genuinely frozen or still performing useful work. A large initial index, especially one involving folder indexing or network storage, can make startup slow without indicating a fault.

1.1 Let the initial index finish

Open Everything and watch the status bar at the bottom of the window. If it reports scanning, indexing, loading, or updating activity, leave the application open for several minutes. Systems with millions of files, slower disks, or extensive folder indexes may need longer.

Avoid repeatedly closing Everything during the initial index. Interrupting the same operation on every launch can create the impression that it never completes.

Success means the status bar eventually becomes idle, the result count stabilizes, and searches respond quickly. Once that happens, stop troubleshooting. A completed initial index followed by normal performance usually means no repair is necessary.

1.2 Test a simple local search

Clear the search box, disable any active filter, and enter the name of a file that you know exists on a local NTFS drive. Use a plain filename fragment without regular expressions, macros, path modifiers, or complex search operators.

• Select the Everything filter instead of Audio, Documents, Executables, or another restricted filter.
• Turn off Match Case, Match Path, Match Whole Word, and Regex unless you intentionally need them.
• Clear any result omissions or temporary exclusions that may hide expected files.
• Check that the status bar does not show an active operation that is still progressing.

If a simple local query works but a saved or complex query does not, startup may be fine. The apparent Everything search not working problem is more likely a filter or search option.

1.3 Distinguish Everything from Windows Search

Everything is a filename search utility from voidtools. Its fast local results normally come from indexing filesystem metadata, particularly NTFS volumes. Windows Search is a separate Windows component that can index filenames, properties, and file contents. Rebuilding the Windows Search index generally will not fix Everything hanging while loading its own database or scanning configured folders.

2. Check the Everything Settings Most Closely Related to Startup

If the application remains busy or unresponsive, inspect settings that trigger work during startup. Change one category at a time and relaunch Everything after each test.

2.1 Review folder indexes and large folder scans

Open Tools, Options, and Indexes, then inspect the Folders page. Folder indexing is commonly used for non-NTFS filesystems, network shares, NAS folders, mapped drives, removable media, or locations that Everything cannot index through the NTFS change journal.

A folder index containing a very large directory tree may require a substantial scan. A network folder can take even longer because every directory request depends on the network, server, authentication, and storage response time.

1. Note every configured folder index before changing anything.
2. Temporarily disable or remove one suspected folder, preferably the largest or slowest network path.
3. Restart Everything and wait for the local index to become ready.
4. Add or enable the folder again only after confirming that startup works without it.

Success means Everything opens promptly after the suspected folder index is disabled. You can then narrow the problem to that path, reduce its scope, adjust its rescan schedule, or restore connectivity before enabling it again.

2.2 Test unavailable network paths

Mapped drives and UNC paths can delay startup when the NAS is asleep, a VPN is disconnected, credentials have expired, DNS is slow, or the server is unavailable. Windows may spend significant time waiting for a network timeout, during which Everything can appear to hang.

Perform a temporary disconnect test. Disconnect from the network or disable only the relevant folder index, then launch Everything. Alternatively, confirm in File Explorer that the same UNC path opens promptly under the same Windows account.

If Everything starts normally without the network path, stop changing unrelated local index settings. Restore the network connection, correct the share or credentials, and then test the folder index again. Do not expose an Everything server or a Windows file share directly to the public internet as a workaround.

2.3 Check the database location

Everything can save its database so it does not need to reconstruct all index information at every launch. Problems arise when the configured database location is on a slow USB device, a sleeping hard drive, a disconnected share, a synchronized cloud folder, or a location where the current account lacks write permission.

Check the database location in Everything's options. If it points to removable or network storage, temporarily move it to a fast local folder that the current user can write to. Keep the original database until the test succeeds. There is no need to delete it as the first step.

Success means Everything loads normally with its database on local storage and can close cleanly while saving its state. At that point, leave the database local unless you have a specific operational reason to place it elsewhere.

2.4 Review folder_update_rescan_asap

The advanced setting named folder_update_rescan_asap affects how Everything handles folder index rescans that are due or have been missed. In an environment with large folder indexes, enabling immediate catch-up behavior can cause substantial scanning soon after startup.

If startup delays coincide with scheduled folder rescans, review this setting together with each folder's update schedule. As a controlled test, prevent an immediate rescan or temporarily disable the affected folder index, then restart Everything. Do not change unrelated advanced settings at the same time.

Success means startup completes without immediately launching a long folder scan. You can then schedule rescans for a suitable time or divide an oversized folder index into smaller, manageable locations.

2.5 Check exclusions, result omissions, and index selection

If Everything opens but expected results are missing, the problem may not be a hang. Review the Indexes and Exclude options, along with any enabled result omission settings. Confirm that the relevant volume or folder is actually included in the index.

Also clear the search and select the Everything filter. A filter, exclusion, or omission can make an otherwise healthy index look empty. Success means a known local filename appears in a simple search. Stop once results return, rather than forcing an unnecessary rebuild.

3. Check Windows, Service, and Account Context

Everything's behavior can differ depending on whether it uses the Everything Service, runs as administrator, starts under a standard account, or accesses resources through a different security context.

3.1 Verify the Everything Service state

Open Tools and Options, then review the service-related settings. You can also open the Windows Services console and verify that the Everything service is present and running when your configuration expects it.

A service mismatch can prevent normal NTFS indexing or cause repeated startup work. If the service is installed but stopped, start it and test again. If company policy controls services, ask an administrator before changing its startup configuration.

Success means Everything can access its configured local volumes without requiring repeated elevation, and the index reaches an idle state. Avoid alternating randomly between service mode, administrator mode, and standard-user mode because that makes permission problems harder to isolate.

3.2 Compare the interactive user and startup account

A network share that opens in File Explorer may still be unavailable to a service or scheduled startup process. Mapped drive letters are associated with a user session and may not exist in another account or elevated context. UNC paths are generally clearer for diagnosing network folder indexes, but they still require valid permissions.

Launch Everything manually after signing in. If manual startup works but automatic startup hangs, inspect the shortcut, Startup folder entry, scheduled task, service context, and command-line arguments. Confirm that the startup method uses the intended configuration and database location.

Success means manual and automatic launches use the same expected settings and neither waits for an inaccessible resource.

3.3 Consider the filesystem type

NTFS volumes can normally use Everything's fast metadata-based indexing. FAT, exFAT, many removable devices, Linux-backed shares, and NAS locations usually require folder indexing or another supported access method. Folder indexing must enumerate directories, so it is more sensitive to storage speed and network latency.

Do not assume that a long scan of a NAS folder indicates a broken NTFS index. Identify which index method applies to each location, then troubleshoot the slow component specifically.

3.4 Test firewall and antivirus interference carefully

Security software can delay database access, executable startup, inter-process communication, or network share enumeration. Check security logs and quarantine history for Everything-related events. If organizational policy permits, use a brief, controlled test or a narrowly scoped exclusion for the trusted Everything executable or local database file.

Do not disable antivirus or firewall protection permanently. Do not broadly exclude entire user profiles, network shares, or system drives. If a temporary test changes startup behavior, restore protection and create the smallest vendor-approved rule that resolves the verified conflict.

4. Use Everything's Diagnostic and Recovery Tools

4.1 Read the status bar before rebuilding

The status bar helps distinguish an active index operation from a search or display issue. Note the operation shown, how long it runs, and whether the item count changes. A changing count suggests progress. A fixed state that always stops at the same point suggests a repeatable path, permission, or database problem.

Record the last visible status before closing the application. This information is more useful than describing the window as merely frozen.

4.2 Use Force Rebuild only after safer checks

If local results remain incomplete or the index appears inconsistent after the service, volumes, folder paths, and permissions have been verified, use Force Rebuild from the Indexes options. A rebuild is appropriate when the index itself is suspected, but it should not be the first response to an unavailable NAS or slow database location.

During the rebuild, allow Everything to finish. Success means the indexed item count stabilizes and known files appear. If the rebuild hangs at the same stage, the underlying volume, folder index, or access problem still needs attention.

4.3 Inspect debug output and the Index Journal

Everything provides diagnostic capabilities that can reveal repeated rescans, database activity, service communication, and troublesome paths. Use the documented debug options or debug logging, reproduce the startup delay once, and inspect the final repeated operation or path.

The Index Journal can also help explain recent index changes and whether Everything is processing updates. Avoid posting debug logs publicly without reviewing them because filenames, usernames, drive layouts, and network paths may be sensitive.

4.4 Test search syntax separately

If startup completes but searches appear empty, test with a known filename and no operators. Then add filters or syntax one element at a time. This separates Everything results missing because of query logic from an index that is not updating.

For example, clear Regex, Match Path, case matching, active filters, and result omissions. If the basic search works, the database and core index are likely healthy. Focus on the query rather than rebuilding the index.

5. Run a Clean Temporary Test

A clean profile is the fastest way to determine whether the voidtools Everything fix belongs in configuration or in the wider Windows environment. Use a separate temporary Everything configuration or a fresh portable copy from the official source. Do not overwrite your working configuration.

1. Close the existing Everything instance completely.
2. Back up or record important settings, especially folder indexes and server options.
3. Start a clean temporary instance without the existing database and custom folder indexes.
4. Allow the initial local index to finish.
5. Run a simple search for a known local file.
6. Add one folder index or custom option at a time until the delay returns.

Be careful with command-line options. A startup shortcut may specify a different configuration file, database path, instance name, service mode, startup state, or search. Test the executable without the custom shortcut to determine whether an argument triggers the behavior.

Also review server options such as ETP, HTTP, or other enabled interfaces if your setup uses them. Confirm that the configured port is available and that firewall rules apply only to trusted networks. A clean local test should not require publishing a search server to the internet.

Success means the clean instance opens, finishes its initial index, and returns local results. That proves the executable and basic Windows indexing path work. Reintroduce settings individually and stop when the responsible option is identified.

6. Quick Fix Checklist

• Wait once for the initial index to finish and watch for visible progress.
• Clear the query, select the Everything filter, and search for a known local file.
• Temporarily disable the largest folder index and restart Everything.
• Test with unavailable NAS, UNC, VPN, and mapped-drive paths removed.
• Move the database from slow or removable storage to a writable local folder.
• Review folder rescan schedules and folder_update_rescan_asap.
• Confirm the Everything service is running under the intended configuration.
• Compare manual startup with the automatic shortcut or scheduled launch.
• Check exclusions, result omissions, indexed volumes, and active filters.
• Use Force Rebuild only after path, storage, service, and permission checks.
• Capture debug information if the process repeatedly stalls at the same point.
• Use a clean temporary profile to isolate configuration problems.

After each change, restart Everything and look for one clear success condition: the status becomes idle, the result count stabilizes, and a known file appears promptly. When that happens, stop changing settings. Multiple simultaneous changes may hide the real cause and make the problem return later.

7. Frequently Asked Questions

7.1 Why does Everything hang while loading the database?

The database may be large, stored on slow media, unavailable over the network, blocked by permissions, or being inspected by security software. Test a writable local database location before deleting anything. If local storage fixes the delay, retain the original database until the configuration is stable.

7.2 Why does Everything freeze when my NAS is offline?

A configured folder index may be waiting for the NAS, mapped drive, UNC path, DNS response, VPN, or authentication timeout. Temporarily disable that folder index and restart Everything. If startup becomes normal, correct connectivity or scheduling for that path instead of rebuilding healthy local indexes.

7.3 How long should I let the initial index run?

There is no single correct duration because it depends on file count, storage speed, filesystem type, and folder-index scope. Continue waiting while the status or item count shows progress. Investigate further when the same operation remains unchanged for an unusually long period or stalls consistently on every launch.

7.4 Should I delete the Everything database?

Not initially. First test network paths, folder indexes, database location, service state, permissions, filters, and a clean temporary profile. Force Rebuild is safer and more informative when an index repair is justified. Preserve the existing database until you know it is the cause.

7.5 Why is the Everything index not updating?

Possible causes include a stopped service, an excluded volume, a disconnected folder index, insufficient permissions, a paused or scheduled rescan, or a query that hides valid results. Check the status bar, indexed volumes, exclusions, folder schedules, and a plain search before forcing a rebuild.

7.6 Why do files remain missing after Everything starts?

Confirm that the file's volume or folder is indexed and that no filter, exclusion, result omission, regex option, or path-matching rule is active. If a plain search still fails after indexing becomes idle, verify the relevant index source and then consider Force Rebuild. Missing results alone do not prove that startup is hanging.