Everything DB Corrupted: How to Fix It

When an Everything database is corrupted, voidtools Everything may fail to start normally, display an error about Everything.db, return stale or incomplete results, repeatedly rebuild its index, or stop preserving its index between sessions. Similar symptoms can also come from an active filter, an excluded volume, insufficient permissions, a disconnected network share, or a mismatch between the account running Everything and the account running its service.

This guide focuses on the database file itself while helping you rule out settings and Windows conditions that can look like database damage. Begin with small, reversible tests. Do not delete Everything.db immediately, and stop troubleshooting as soon as Everything starts cleanly, finishes indexing, and returns current results after a restart.

1. Confirm the Symptom With a Small Safe Test

Before rebuilding anything, determine whether the problem affects the database, one index source, or only the current search. Everything is a filename search application with its own indexes. It is not the Windows Search service, and rebuilding the Windows Search index generally will not repair Everything.db.

1.1 Signs that Everything.db may be corrupted

Database corruption is more likely when you see one or more of these symptoms:

• Everything displays an explicit error while loading, reading, or saving Everything.db.
• The program fails during startup but opens after its database is renamed.
• Everything rebuilds the same index after every normal restart.
• Results are broadly damaged or missing across indexed volumes, not just one folder.
• The database has an implausible size, cannot be read, or was interrupted during a write.
• Everything works during one session but cannot preserve current results after a clean exit.

Stale results on one mapped drive are less likely to indicate a globally corrupted database. Likewise, a blank result list caused by a restrictive filter or search expression does not require a rebuild.

1.2 Create and search for a test file

Create a harmless file with a distinctive name, such as everything-db-test-4821.txt, in a local folder that should be indexed. Wait briefly, clear the search box, select the Everything filter, and search for the exact filename.

If the file appears quickly and disappears after you delete it, the live local index is functioning. If older results are wrong but the test file updates correctly, allow pending indexing to finish before making changes. If the test never appears, check whether its drive or folder is actually included.

1.3 Read the status bar before changing settings

The status bar can reveal whether Everything is indexing, sorting, scanning a folder index, or showing a limited number of results. A busy index is not necessarily broken. Let the current operation complete unless Everything reports an error or remains stuck with no observable progress.

Success at this stage means the test file appears under an unrestricted search and the displayed result count is plausible. If that happens, stop treating the database as corrupted and investigate the affected drive, folder, or query instead.

2. Check the Options That Can Mimic Database Corruption

Many reports of Everything search not working are caused by a search option or index setting. Review the relevant setting directly rather than resetting every preference.

2.1 Clear the search and select the Everything filter

Remove the current query and select the broad Everything filter. Turn off temporary matching options that could narrow the search, such as Match Case, Match Path, Match Whole Word, or regular expressions. The exact menu placement can differ by configuration, so inspect the Search menu and filter selector.

Then try simple tests:

• * to request a broad result set.
• A known filename without punctuation or advanced operators.
• A full or partial path from a local indexed volume.
• ext:txt to test a basic Everything search function.

If ordinary searches work after an option is cleared, the database does not need to be removed. Stop and restore only the search options you intentionally use.

2.2 Verify NTFS volume indexing

Open Tools, Options, Indexes, and inspect the relevant volume pages. Confirm that the local volume containing the test file is included. A volume can be present in Windows but omitted from Everything's index because of an exclusion, a changed drive configuration, or an account-context issue.

Everything is best known for using NTFS metadata and the NTFS change journal to maintain fast filename indexes. Windows Search instead crawls configured locations and can index file contents. Restarting or rebuilding Windows Search is therefore not a substitute for checking Everything's own volume index.

Success means the expected local volume is listed, indexing completes, and newly created or renamed files appear without requiring a program restart.

2.3 Inspect folder indexes and network locations

Network shares, NAS folders, mapped drives, and file systems that are not being indexed as local NTFS volumes may rely on folder indexing. Open the Folder index settings and confirm that the path still exists, is enabled, and can be opened under the same Windows account that runs Everything.

A folder index is normally updated by rescanning according to its configured behavior. It may not reflect changes as instantly as a local NTFS index. A disconnected share can therefore produce stale entries without damaging Everything.db.

Test the underlying path in File Explorer. If it is a mapped drive, also test its UNC form, such as \\server\share. Mapped drive letters can differ between elevated and non-elevated processes or between user sessions.

2.4 Review exclusions and omitted results

Check the exclusion settings for drive letters, folders, filename patterns, hidden items, and system items. Also inspect any result-omission features you intentionally configured. A broad wildcard exclusion or an old excluded path can make Everything results missing from one location while the rest of the database remains healthy.

Temporarily disable only the suspicious exclusion, repeat the distinctive-file test, and then restore or correct the rule. Do not clear the entire exclusion list unless you have recorded it first.

2.5 Check server and command-line behavior

If you use an Everything server feature, a named instance, a custom database location, or startup command-line options, verify that the shortcut launches the intended instance and profile. Two instances can have different indexes, settings, and database files. A shortcut that points to an old portable directory may appear to show a stale database even though a newer instance is working correctly.

Inspect the shortcut target, startup scripts, scheduled tasks, and management tools that launch Everything. Remove a questionable option only after recording it. Do not expose an Everything network service directly to the public internet. Limit remote access to trusted networks and use appropriate firewall controls.

3. Check Windows Access and Storage Conditions

A healthy database cannot be loaded or saved reliably if the containing folder is read-only, unavailable, synchronized at the wrong moment, or controlled by another process.

3.1 Identify the active database location

The location of Everything.db depends on how Everything is installed and launched. A portable copy commonly keeps its data alongside the executable, while an installed configuration commonly uses a per-user application-data location. Custom command-line options, named instances, and settings can alter which files are active.

Do not assume that the first Everything.db found by Windows is the live one. Check the current instance and its configuration, then compare file modification times after a clean exit. Portable-app users should also confirm that they did not accidentally launch a second copy from a downloads folder or removable drive.

3.2 Avoid cloud-synced database folders

Do not keep an actively written Everything.db in OneDrive, Dropbox, or another cloud-synchronized directory if it can be avoided. Sync clients can create conflicts, placeholders, temporary locks, or competing versions. A database is application state, not a document that benefits from live multi-device synchronization.

Move the portable application and its active database to a normal local folder where the user has write permission. If you need a backup, copy the files only after Everything has exited cleanly.

3.3 Verify write permission and free space

Check that the current Windows account can create, rename, and delete a small test file in the database directory. Confirm that the volume has adequate free space and is not mounted read-only. Do not solve a permission problem by granting broad access to every user. Give the intended account only the access it needs.

If Everything runs elevated at one time and normally at another, the account context and accessible mapped drives can change. Use a consistent startup method. Where the Everything service is used, confirm that the service is running and that the desktop application can communicate with it.

3.4 Treat antivirus detections and locks carefully

Security software may quarantine an executable, restrict an application-data folder, or hold a file briefly during inspection. Review the security product's event history and Windows Security protection history for a specific event involving Everything or its database.

Do not disable antivirus permanently. If a trusted, digitally verified Everything installation is being blocked, use the product's documented allow-list process with the narrowest practical path or application rule. If no security event exists, continue troubleshooting rather than assuming antivirus is responsible.

3.5 Check the file system after abnormal shutdowns

Database damage can follow a power loss, forced termination, removable-drive disconnect, or underlying storage error. Review Windows logs and drive health if other files are also becoming unreadable. Use Windows file-system checking tools according to Microsoft's guidance, preferably after backing up important data.

If corruption returns repeatedly after successful rebuilds, stop rebuilding and investigate storage reliability, unexpected shutdowns, permissions, and synchronization. Recurrent database failure is a symptom of an unresolved cause.

4. Rebuild the Database Safely

Once search options, index scope, and write access have been checked, rebuilding is appropriate. A rebuild discards the generated filename index and creates it again from configured sources. It does not delete the files being indexed.

4.1 Use Force Rebuild first

Open Everything's index options and use Force Rebuild. This is preferable to manually deleting Everything.db because Everything remains aware of the operation and uses the current configuration to reconstruct its indexes.

During rebuilding, result counts can be incomplete. Avoid changing exclusions, folder indexes, services, and startup options at the same time. Let the rebuild finish, then repeat the distinctive-file test.

Success means indexing completes, expected volumes and folders return, the test file appears, and Everything opens normally after a clean restart. At that point, stop changing settings.

4.2 Exit safely before touching Everything.db

If Force Rebuild is unavailable, fails immediately, or Everything cannot start far enough to use it, close the application cleanly before manipulating its database:

1. Record or capture the current index and folder settings if Everything opens.
2. Use File, Exit or the tray icon's Exit command rather than closing only the search window.
3. Open Task Manager and confirm that the relevant Everything desktop process has ended.
4. Do not terminate the process while it is actively saving unless it is completely unresponsive.
5. Leave unrelated services alone unless the documented procedure for your setup requires otherwise.

A clean exit matters because the application may save database state during shutdown. Renaming a database while it is open can create another failure or cause your change to affect the wrong file.

4.3 Rename the database instead of deleting it

After confirming the active instance has exited, rename Everything.db to a reversible name such as Everything.db.bad. Start Everything again and allow it to create a new database.

Renaming is safer than deletion because it preserves the old file for diagnosis or rollback. Do not restore the old database merely because it contains more results. Those results may be stale, and Everything should regenerate them from the actual indexed sources.

If a new database fixes startup and survives a clean restart, the old database was likely damaged or unusable in that environment. Keep the renamed copy only as long as needed, then remove it while Everything is closed.

4.4 Back up settings separately from the database

Everything.db is a generated index, not the only file that matters. Settings, filters, bookmarks, macros, named-instance configuration, and other preferences may be stored separately. Back up the applicable configuration files or exportable settings before resetting a profile.

Do not copy a suspected damaged database into the backup you plan to restore. Label configuration backups separately from generated index files. For portable installations, inspect the portable directory carefully because the executable, INI configuration, database, and logs may be located together.

5. Use Diagnostics When Rebuilding Does Not Hold

If Everything works immediately after rebuilding but breaks again at the next startup, investigate why the database cannot be saved or reloaded. Repeating Force Rebuild without identifying the cause wastes time and can hide a permissions or storage problem.

5.1 Compare behavior before and after a clean restart

1. Start Everything and wait for indexing to finish.
2. Create and locate the distinctive test file.
3. Exit Everything through its Exit command.
4. Confirm the database file has a current modification time.
5. Start the same shortcut and instance again.
6. Search for the test file and inspect the index status.

If the database timestamp never updates, focus on write permissions, the active path, security controls, or a read-only portable location. If it updates but cannot be loaded, inspect logs and storage health.

5.2 Use debug output and logs selectively

Everything provides diagnostic and debugging facilities documented by voidtools. Enable them only long enough to reproduce the failure, and record the first relevant database, volume, journal, folder-index, or access error. Debug output can contain local paths and filenames, so review and redact it before sharing publicly.

Do not infer corruption from every warning. A disconnected network folder may generate an access error while the local database remains valid. Match the message to the source that is actually missing.

5.3 Inspect change-journal and index behavior

For local NTFS indexing, Everything uses file-system metadata and change information to keep results current. If the required journal state is unavailable or has changed, Everything may need to rescan or rebuild that volume. This can be a normal recovery action rather than proof that Everything.db is corrupt.

Where available, inspect the Index Journal and index status for repeated resets, inaccessible volumes, or scanning that never completes. If only one volume repeatedly fails, isolate that volume rather than resetting every folder index and preference.

6. Run a Clean Temporary Test

A clean temporary test separates database damage from persistent configuration. It should not overwrite your normal settings or database.

6.1 Prepare an isolated portable test

Download Everything only from the official voidtools website. Place a portable copy in a new, local, non-synchronized folder where your account has write access. Do not place it over the existing installation, and do not copy the old Everything.db or configuration into the test folder.

Close the normal Everything interface before starting the isolated copy. If you use advanced instance options, choose a distinct named instance according to the official command-line documentation so that the test does not connect to or modify the normal profile.

6.2 Interpret the result

• If the clean copy starts and indexes correctly, the normal profile, database path, or startup command is the likely cause.
• If both copies fail on the same volume, investigate permissions, service access, file-system health, or security controls.
• If local files work but a NAS share does not, focus on folder indexing, credentials, connectivity, and scan timing.
• If the clean copy works until restart, verify that its directory remains writable and its database is being saved.

Once the test identifies the failing layer, make one correction in the normal setup and test again. Avoid copying all old settings into the clean profile at once because that can reintroduce the problem without revealing its source.

7. Quick Fix Checklist

1. Clear the query and choose the Everything filter.
2. Create a uniquely named local test file and search for it.
3. Check the status bar and allow active indexing to complete.
4. Confirm the relevant volume or folder index is enabled.
5. Review exclusions, omitted results, and advanced search options.
6. Verify the service state and the account used to launch Everything.
7. Confirm network paths and mapped drives are accessible in that account context.
8. Identify the active Everything.db rather than editing the first copy found.
9. Check database-folder write permission, free space, and security events.
10. Move portable data out of cloud-synchronized or read-only locations.
11. Use Force Rebuild and wait for it to finish.
12. If necessary, exit safely and rename Everything.db instead of deleting it.
13. Restart the same instance and repeat the test-file search.
14. Run an isolated portable test if rebuilding does not survive restart.

The repair is complete when Everything starts without a database error, finishes indexing, finds newly created files, removes deleted files from results, and retains correct results after a clean exit and restart. Once those conditions are met, stop changing options.

8. Frequently Asked Questions

8.1 Does deleting Everything.db delete my files?

No. Everything.db is a generated filename index, not the indexed files themselves. Removing it does not intentionally delete documents, media, or folders. However, renaming it after a clean exit is safer than immediate deletion because the change remains reversible.

8.2 Should I use Force Rebuild or remove Everything.db?

Use Force Rebuild first when Everything opens and the command is available. It is the controlled repair path. Rename the database only when Everything cannot load it, Force Rebuild fails, or you need to confirm that a fresh database resolves startup. Always exit the application first.

8.3 Why is the Everything index not updating on my NAS?

A NAS path is usually handled as a folder index rather than as a directly monitored local NTFS volume. Check share availability, credentials, UNC paths, folder-index settings, exclusions, and rescan behavior. A stale NAS folder index alone does not prove that the main database is corrupt.

8.4 Where is Everything.db in portable mode?

A portable setup commonly keeps Everything.db in the portable application's directory, but custom instances and command-line options can change active paths. Confirm which executable and instance are running before renaming any file. Keep the portable directory writable and outside cloud-sync folders.

8.5 Will rebuilding Windows Search fix Everything?

No. Everything and Windows Search maintain different indexes and use different mechanisms. Repair Everything through its own index options, database handling, service configuration, and folder indexes. Rebuild Windows Search only for a separate Windows Search problem.

8.6 Why does Everything work until I restart it?

The database may not be saving, the next startup may launch a different instance, or a sync tool may replace the file. Check the active database path, its modification time after a clean exit, directory permissions, shortcut options, named instances, and security history. If a fresh database repeatedly fails, investigate storage and shutdown reliability rather than rebuilding again.