Everything DB Not Saving: How to Fix It

When the Everything database is not saving correctly, voidtools Everything may rebuild its index at every launch, forget indexed folders, lose recent filename changes, or start with unexpectedly empty results. This is a database-persistence problem, not the same as Windows Search failing. Everything maintains its own filename index and normally saves that index as an Everything.db file so it can be loaded quickly during the next session.

The most likely causes are an unwritable database location, a portable installation running from read-only media, a crash or forced shutdown before the database is saved, confusion about the active settings profile, interference from synchronization or security software, or launching Everything under a different account or instance. Start with a controlled test. Once Everything survives a normal exit and restart without rebuilding or losing results, stop changing settings.

1. Confirm the Symptom With a Small Safe Test

Before changing permissions or rebuilding the index, verify that the problem is database persistence. A search can appear broken because of an active filter, unusual search syntax, exclusions, or an unavailable network folder even when Everything.db is being saved normally.

1.1 Run a controlled restart test

1. Open Everything and wait until indexing activity has settled.
2. Search for a filename that you know exists on a locally indexed NTFS volume.
3. Note the number of displayed results and any indexing message in the status bar.
4. Create a uniquely named test file, such as everything-persistence-test.txt, in a local indexed folder.
5. Confirm that the file appears in Everything.
6. Exit Everything normally through its File menu or notification-area icon.
7. Wait several seconds, restart Everything, and repeat the search.

Success means Everything opens with its previous index, finds the test file, and does not begin a full rebuild on every launch. If the test file remains visible but a network or folder result is missing, investigate that specific index source instead of treating the entire database as lost.

1.2 Rule out a misleading search state

Clear the search box, select the Everything filter, and temporarily turn off options such as Match Case, Match Whole Word, Match Path, and regular-expression searching. Look for an active filter in the Search menu and check whether the status bar indicates that only a subset of results is being shown.

A simple known-name search is more useful than a complex query during diagnosis. If clearing the filter restores the expected files, the database was not lost. Stop there and correct the saved filter or search syntax rather than rebuilding the index.

2. Check Where Everything Is Saving Its Database

The active database location depends on how Everything was installed, whether it is portable, whether settings and data are stored in AppData, and whether a named instance or command-line option is being used. Do not assume the Everything.db beside the executable is the active file.

2.1 Understand the common database locations

For a conventional per-user configuration, Everything commonly stores its database under the current user’s local application-data area, typically in %LOCALAPPDATA%\Everything. A portable configuration may keep Everything.db in the same folder as Everything.exe. Named instances can use instance-specific settings and database names, so files belonging to one instance may not represent the instance you are currently running.

Open Everything’s Options pages and inspect the settings related to data storage and the database rather than relying only on Windows Explorer. You can enter %LOCALAPPDATA%\Everything in the Explorer address bar to inspect the current user’s local data folder. Check the database file’s modified time after a normal Everything exit.

Success means the active Everything.db has a recent modification time, remains present, and is loaded after restart. Once this happens consistently, do not move or delete it merely because another stale Everything.db exists elsewhere.

2.2 Check Store settings and data in AppData

The Store settings and data in AppData choice is especially important for portable users. When enabled, Everything can keep user-writable settings and data in the Windows application-data location instead of requiring write access beside the executable. When disabled in a portable setup, the program folder must permit the current user to create, replace, and rename its data files.

If Everything.exe is under Program Files, on read-only media, inside a protected deployment folder, or in a folder controlled by another account, storing data beside the executable can fail. Using AppData is usually the safer arrangement for an installed copy. A genuinely portable copy should reside in a normal writable folder owned by the user.

After changing this option, exit normally, restart, and repeat the controlled test. Do not keep toggling the option once the same database loads successfully across restarts.

2.3 Avoid synced and transient database locations

Do not place the live database in a cloud-synchronized folder unless you have a specific, tested reason. Synchronization clients can delay writes, create conflict copies, restore older versions, or temporarily lock files while Everything is exiting. The same concern applies to removable drives, temporary folders, roaming-profile paths, and network shares that may be unavailable during logon or shutdown.

Keep the active database on a stable local disk with sufficient free space. Synchronize backups only when Everything is not writing the file. Success means no conflict copy appears, the modification time advances after exit, and the next launch loads without rebuilding.

3. Verify Exit Behavior, Startup Context, and Permissions

Everything’s database is saved during normal operation and shutdown behavior, but an abrupt termination can prevent the final state from being committed properly. A crash, forced process termination, sudden power loss, portable-drive removal, or Windows shutdown that closes the application too quickly can make the next launch rebuild or load older data.

3.1 Test save on exit behavior

Use Everything’s normal Exit command instead of ending it in Task Manager. Wait briefly before signing out, shutting down Windows, or removing a portable drive. Then inspect the active database file’s timestamp and reopen the application.

If normal exits work but forced shutdowns do not, the database path is probably writable. The immediate fix is to avoid terminating the process abruptly and to investigate why Everything is being killed. Check scheduled tasks, shutdown scripts, application-management tools, or cleanup utilities that may end processes or erase user data.

3.2 Confirm the Windows account and elevation context

A database stored in one user’s AppData is not automatically shared with another Windows account. Likewise, launching Everything from a scheduled task, service wrapper, administrative shortcut, remote session, or deployment system can give it a different profile and environment.

Compare how Everything is started when it works and when it fails. Check the shortcut target for instance names or command-line arguments. Confirm that the same Windows user launches it each time and that the startup entry points to the intended executable.

Running as administrator once is not a durable permissions fix. It can create files owned or accessible under a different context and hide the real problem. The goal is for the normal user to write the intended database directory without elevation.

3.3 Test folder write permission safely

Open the folder containing the active database and create a small text file there using the same Windows account. Rename it, save changes to it, and delete the test file. This checks more than simple folder visibility because applications often need permission to create and replace files during a safe save.

If the test fails, review the folder’s Security properties, ownership, read-only media status, and inherited permissions. Move a portable installation to a user-writable local folder if appropriate. Do not weaken permissions across an entire drive or grant broad access to all users just to make one application work.

Success means the user can create, modify, rename, and remove a test file, and Everything.db updates after a normal exit.

4. Check Index Sources Without Confusing Them With Persistence

An intact database can still contain incomplete results. Before concluding that Everything DB is not saving, inspect the index source that should contain the missing filename.

4.1 Check NTFS volumes and the Everything service

Everything can use the Everything service to obtain the access needed for low-level NTFS volume indexing while the desktop application runs under a standard user account. If the service is stopped or misconfigured, a volume may not index as expected. However, the service state and database persistence are separate issues: fixing the service restores volume access, while fixing the database path preserves the resulting index between launches.

Open the NTFS section of Everything’s Options and confirm that the expected local volumes are included. Then check Windows Services for the Everything service if your configuration uses it. Start or repair the service through Everything’s supported options rather than exposing an Everything server to the internet.

Success means the expected volume is listed, current filenames appear, and the results remain after a normal restart.

4.2 Inspect folder indexes and network shares

NAS locations, mapped drives, non-NTFS storage, and selected directories may be indexed as folder indexes. These sources can look stale if the share is unavailable, credentials have expired, the mapped drive exists only in another account context, or the update schedule does not run.

In the Folders section of Options, verify the exact path, update settings, and current availability. Prefer a UNC path when a mapped drive letter is missing in elevated sessions or scheduled launches. Confirm that Windows Explorer can access the share under the same account before asking Everything to update it.

If local results persist but NAS results disappear, troubleshoot the folder index and network access. Moving Everything.db onto the NAS will not correct an inaccessible source and may introduce an additional persistence problem.

4.3 Review exclusions and result omissions

Check the Exclude section for excluded folders, files, extensions, hidden items, or system items. Also review active filters and any result-omission settings available in your configuration. An exclusion can be saved correctly and consistently hide the same files, which can be mistaken for an outdated database.

Temporarily disable only the relevant exclusion, rerun a simple filename search, and restore it if it was intentional. Success means the expected result appears immediately or after the appropriate index update. A full rebuild is unnecessary when a filter or exclusion explains the omission.

4.4 Check server and command-line options

Everything can be launched with command-line switches or connected to an Everything server. A shortcut that selects another instance, database, configuration, or server can produce a completely different result set. Compare the shortcut’s Target field with a plain launch of the intended Everything.exe.

If a server is involved, first test local indexing without changing firewall exposure. Confirm the server address, authentication, listening scope, and network reachability according to your organization’s policy. Do not publish an Everything server directly to the public internet as a troubleshooting shortcut.

Success means repeated launches use the same instance and source. When that is established, stop changing index settings.

5. Use Built-In Diagnostics in a Controlled Order

Diagnostics are most useful when each step answers one question. Changing the database path, exclusions, service configuration, and folder indexes simultaneously makes the original cause difficult to identify.

5.1 Read the status bar and Options pages

The status bar can reveal whether Everything is indexing, updating, or displaying a filtered result count. Review the Database, Indexes, NTFS, Folders, Exclude, Service, and related Options pages available in your installation. Record the original values before changing anything.

Look specifically for an index that repeatedly starts from scratch, a missing volume, an unavailable folder path, or a database path that differs from the file you were monitoring.

5.2 Use Force Rebuild only after basic checks

A Force Rebuild can repair an index that is stale or internally inconsistent, but it does not fix an unwritable destination. If Everything cannot save the rebuilt database, it will repeat the same problem at the next launch.

Before forcing a rebuild, confirm the destination is local and writable, the correct instance is active, and there is enough free disk space. Then run one rebuild, allow it to finish, exit normally, and restart.

Success means the rebuild completes once and the rebuilt index loads on the next launch. If rebuilding occurs again, return to the database location, permissions, exit behavior, and startup-context checks rather than rebuilding repeatedly.

5.3 Capture debug information and inspect the Index Journal

If the failure remains intermittent, use Everything’s supported debugging facilities to capture what happens during startup, database loading, indexing, and exit. Reproduce the problem once, then review messages concerning database opening, saving, access denial, invalid paths, or unavailable volumes.

The Index Journal can help determine whether Everything is receiving and applying filename changes. If a newly created file appears in the journal and results during the session but vanishes only after restart, persistence is the leading suspect. If the change never reaches the active index, investigate the volume, folder index, service, exclusions, or update schedule instead.

A debug log can contain local paths and filenames. Store and share it carefully, especially on business systems.

6. Run a Clean Temporary Test

A clean temporary test separates an installation-wide problem from a damaged or confusing profile. It should not overwrite the working profile or require deleting the existing database.

1. Exit the normal Everything instance cleanly.
2. Create a new writable local folder under your user profile.
3. Place a separate portable copy of the official Everything application there, or use a distinct named instance supported by Everything.
4. Configure the test to index only a small, non-sensitive local source.
5. Allow indexing to finish and create a uniquely named test file.
6. Exit normally, wait, and restart the same test instance.
7. Check whether the test database and result persist.

If the clean instance saves correctly, Windows and the application can write a database. The original profile likely has a path, instance, command-line, exclusion, or source configuration problem. Compare settings methodically instead of replacing everything at once.

If the clean instance also fails, focus on permissions, security controls, disk health, available space, profile redirection, and process termination. Security software may block or quarantine unfamiliar portable executables or database writes. Review its event or protection history and create a narrowly scoped exception only if your security policy permits and the official executable has been verified. Never disable endpoint protection permanently.

7. Quick Fix Checklist

• Clear the search and select the Everything filter before diagnosing missing results.
• Confirm the active database path through Everything’s settings.
• Use AppData for an installed copy that cannot write beside its executable.
• Keep a portable copy in a local folder where the user has full file-operation rights.
• Move the live database away from cloud-sync, temporary, removable, or unreliable network locations.
• Exit Everything normally and wait before shutting down or removing portable media.
• Launch Everything under the same user, instance, shortcut, and command-line context each time.
• Verify the Everything service and NTFS volume selection when local volumes are absent.
• Check folder-index availability and credentials when NAS results are missing.
• Review exclusions, filters, result omissions, and search syntax before rebuilding.
• Run Force Rebuild once only after confirming that the destination is writable.
• Use a clean temporary instance if the original profile remains ambiguous.

Stop troubleshooting when a known test file appears, Everything.db receives a current modification time after a normal exit, and the same result returns after two or more restarts without an unnecessary rebuild.

8. Frequently Asked Questions

8.1 Where is Everything.db stored by default?

In a conventional per-user setup, it is commonly stored in the current user’s local application-data folder under %LOCALAPPDATA%\Everything. A portable configuration may store it beside Everything.exe. Named instances and custom options can change the name or location, so verify the active settings instead of assuming that the first Everything.db found by Explorer is in use.

8.2 Why does Everything rebuild its database every time it starts?

The usual reasons are that the database was not saved, cannot be reopened, is being written to an unstable location, or belongs to a different user or instance. Confirm folder permissions, normal exit behavior, available disk space, the AppData storage choice, startup arguments, and whether a sync or cleanup tool is replacing the file.

8.3 Is Everything the same as Windows Search?

No. voidtools Everything maintains its own filename index and search interface. Windows Search uses separate Windows indexing components and can index file content and other properties. Restarting or rebuilding the Windows Search index generally does not repair Everything.db, and an Everything persistence problem does not necessarily indicate that Windows Search is damaged.

8.4 Should I delete Everything.db to fix missing results?

Not as the first step. First check filters, exclusions, index sources, the service, folder availability, permissions, and the active database location. Use Everything’s Force Rebuild option only after those checks. Manual deletion removes diagnostic evidence and will not fix a destination that remains unwritable.

8.5 Why are NAS files missing even though local files work?

NAS content is generally handled as a folder index or through another configured source rather than the local NTFS indexing path. Check that the share is reachable under the same account, credentials are valid, the UNC or mapped path is correct, and the folder-index update settings are appropriate. This is often a source-availability issue rather than a failed local database save.

8.6 Can antivirus or ransomware protection prevent saving?

Yes, security controls can block an executable from writing to protected folders or can quarantine files, but confirm this in the product’s event history before making exceptions. Prefer a trusted local AppData location and a verified official executable. If an exception is required, keep it narrow and follow organizational policy rather than disabling protection.