Everything Settings Reset After Restart: How to Fix It

If Everything settings reset after restart, the program is usually loading a different configuration, failing to write its configuration file, or being closed before its latest options are saved. Less commonly, another Everything instance, a security feature, cloud synchronization, or a startup command replaces the saved configuration. This guide focuses on global settings persistence in voidtools Everything, not Windows Search. Follow the tests in order and stop as soon as a setting survives a clean exit and relaunch.

1. Confirm the Symptom With a Small Safe Test

Before changing permissions, rebuilding an index, or reinstalling anything, verify that the problem is genuinely a settings-persistence failure. A missing result and a setting that reverts can look related, but they have different causes.

1.1 Change one harmless option

Open Everything and change a visible, low-risk option, such as a display preference. Avoid using an indexing change for this first test because rebuilding or refreshing an index can introduce unrelated delays.

1. Open the Everything Options window.
2. Change one easily recognizable interface preference.
3. Apply the change and close the Options window.
4. Exit Everything through its tray icon or the File menu.
5. Wait several seconds, then launch Everything normally.

Success means the test preference remains changed after a complete exit and relaunch. If it survives, global persistence is working and the original problem is likely limited to a filter, index, folder, exclusion, server, or startup option. Stop changing global configuration files and investigate only the affected feature.

1.2 Separate restart types

Test a program relaunch before testing a full Windows restart. If the setting disappears after merely closing and reopening Everything, focus on configuration location, write access, and multiple instances. If it survives a program relaunch but disappears after signing out or restarting Windows, focus on startup shortcuts, scheduled tasks, account context, synchronization, and shutdown behavior.

Also confirm that you are opening voidtools Everything each time. Windows Search is a separate Windows component with different indexing controls, storage, services, and troubleshooting procedures.

2. Check the Everything Setting Directly Related to the Problem

If the harmless option persists, examine the specific setting that appears to reset. This prevents an indexing symptom from being misdiagnosed as a global settings problem.

2.1 Search options and filters

Search behavior can change because of toggles such as Match Case, Match Path, Match Whole Word, Match Diacritics, or regular-expression mode. An active filter can also remove expected files from the results. Review the Search menu, clear the search box, and select the broadest appropriate filter before testing again.

Success means the expected files appear with a blank or simple search while the desired search switches remain selected after relaunch. If only one saved filter behaves incorrectly, inspect that filter rather than resetting the entire application.

2.2 Indexes, folders, exclusions, and omitted results

When Everything results are missing or the Everything index is not updating, open Options and review the relevant index pages. Confirm that the expected NTFS or ReFS volume is present, an added folder still exists, and no exclusion rule covers the missing path or filename. If result omission features are enabled, verify that they are not hiding the files you expect.

Mapped drive letters can differ by user session, and a network share may be unavailable when Everything starts. Folder indexes for NAS paths and network shares therefore need separate testing. Open the path in File Explorer under the same Windows account, then return to Everything and check whether the folder index can access it.

Success means the source remains listed after relaunch and its files become searchable after indexing completes. Once that happens, do not rebuild unrelated indexes.

2.3 Service, server, and command-line options

The Everything service helps the application index supported local volumes without requiring the graphical program to run with full administrative rights. It does not replace the user-level configuration file. Confirm the service state if local volume indexing fails, but do not treat service reinstallation as the first fix for every option reverting.

If you use an HTTP, ETP, or other Everything server feature, confirm that its setting is saved and that a local firewall rule permits only the access you intentionally need. Do not expose a search server directly to the public internet. Server reachability and global option persistence are separate tests.

Inspect every shortcut, startup entry, script, scheduled task, and launcher used to open Everything. A command-line option can select an instance, load a particular configuration context, or alter startup behavior. Compare the shortcut used at sign-in with the shortcut used during your manual test.

Success means the same executable, Windows account, instance, and intended arguments are used on every launch.

3. Verify Where Everything Stores Its Settings

The most common Everything settings reset after restart fix is identifying the configuration file actually used by the running process. Installed and portable setups may not use the same location.

3.1 Check the AppData configuration

A standard per-user setup commonly stores settings under the current user's application-data area, typically in a path such as %APPDATA%\Everything. Enter that path in File Explorer rather than manually browsing to a guessed user folder.

Locate the Everything INI configuration associated with the instance you are running. Note its modified time, make the harmless test change, exit Everything cleanly, and refresh File Explorer. The modified time should advance. Do not edit the file while Everything is running because the program may later overwrite manual edits with its in-memory configuration.

If no relevant file changes, check whether you launched Everything as another Windows user or with a different instance name. An elevated launch can also create confusion about account context, even when elevation itself is not required for ordinary use.

3.2 Test portable INI write permission

A portable copy generally needs permission to write its INI file in the directory from which it runs. Locations under protected program directories, read-only media, extracted archive viewers, software deployment folders, and tightly controlled network shares may prevent updates.

1. Exit Everything completely.
2. Copy the portable folder to a normal user-writable local folder.
3. Confirm that its files are not marked read-only.
4. Launch the copied executable directly.
5. Change the harmless option, exit cleanly, and relaunch it.

Success means the INI file receives a new modified time and the option remains selected. If so, keep the portable application in a writable location or correct the original folder's permissions. Do not grant broad write access to an entire protected system directory merely to make one application portable.

3.3 Close Everything cleanly from the tray

Closing the search window may leave Everything running in the notification area. Conversely, ending its process, forcing shutdown, terminating a remote session, or allowing a cleanup tool to kill it can prevent an orderly final write.

Use the tray icon's Exit command or the application's normal exit command for the diagnostic test. Wait for the process to disappear before restarting it. Success means the configuration file updates and the setting survives. If this resolves the issue, review shutdown scripts and process-management tools rather than repeatedly changing the option.

4. Check Windows and Environment Conflicts

4.1 Look for multiple Everything instances

Two running instances can hold different in-memory configurations. The instance that exits last may overwrite a configuration file written by the other, or each instance may use a separate instance-specific configuration. This often happens when a portable copy and an installed copy both start automatically.

Open Task Manager and identify all Everything processes. Check their executable paths and command lines where available. Then exit every instance, launch only the intended executable, apply one test change, exit it, and relaunch the same file.

Success means only the intended instance starts and its preference remains stable. Remove duplicate startup entries only after identifying which copy you need.

4.2 Review Controlled Folder Access and antivirus events

Microsoft Defender Controlled Folder Access or another endpoint-security product may block an application from changing files in protected locations. Antivirus software can also isolate or virtualize behavior when organizational policy considers the location untrusted.

Review Windows Security protection history and your security product's event log for a block occurring at the exact time Everything exits. If confirmed, use the product's narrow allow-list procedure for the trusted Everything executable or move a portable copy to an approved writable location. Do not permanently disable antivirus, ransomware protection, or firewall controls.

Success means no new block appears, the expected INI file updates, and the option persists through another clean relaunch.

4.3 Resolve cloud-synced configuration conflicts

Portable users sometimes place the entire application folder in OneDrive, Dropbox, or another synchronization service. If two computers update the same INI file, the service may restore an older copy or create a conflict. Backup and profile-management tools can cause similar rollbacks.

Temporarily copy Everything to a nonsynchronized local folder and repeat the one-option test. If the setting persists there, pause configuration synchronization only long enough to resolve the conflicting copy, or exclude the mutable configuration while continuing to back it up safely.

Success means the local test remains stable across relaunches and the synchronized location no longer replaces the current INI file.

4.4 Confirm the account, drive, and file system context

Settings saved under one Windows account do not automatically become settings for another. Compare the account used interactively with accounts used by Run as administrator, scheduled tasks, remote-management tools, or deployment systems.

For NAS users, remember that mapped drives are session-specific and may not exist in elevated, service, or scheduled-task contexts. Test the underlying UNC path where appropriate and verify share and NTFS permissions without granting unnecessary access.

Everything's fastest local indexing features depend on supported file-system capabilities, while folder indexing can cover other locations such as network shares. A file-system limitation may explain missing results, but it does not by itself explain why an unrelated display option reverts.

5. Use Built-In Diagnostics Without Destroying Useful State

5.1 Read the status bar and Options pages

The status bar can reveal whether Everything is indexing, sorting, or returning a limited result set. Options pages show the configured volumes, folder indexes, exclusions, services, and other active features. Record what is present before changing anything.

For an Everything search not working issue, test a known exact filename and then a path-restricted query. If a simple filename works but a complex expression does not, simplify the search syntax one operator at a time. This distinguishes an index problem from a query problem.

5.2 Use Force Rebuild only when the index is the problem

Force Rebuild can be appropriate when a configured index is stale or inconsistent. It is not a reliable cure for a read-only or overwritten INI file. Before rebuilding, confirm that the desired volume or folder remains configured and accessible.

After a rebuild, allow indexing to finish and retest a known file. Success means current files appear and remain available after relaunch. If global options still revert, return to configuration-path and write-permission checks.

5.3 Collect debug information and inspect the Index Journal

Everything's debugging facilities can help show which configuration, instance, or indexing path is being used. The Index Journal can help explain index changes and omissions. Enable diagnostic output only for the time needed to reproduce the problem, avoid sharing logs that expose sensitive filenames or paths, and disable extra logging afterward.

A useful diagnostic captures launch, one option change, a normal exit, and the next launch. Look for access-denied messages, unexpected configuration paths, duplicate instances, inaccessible folder indexes, or startup arguments.

6. Run a Clean Temporary Test

If the cause remains unclear, create a temporary test without modifying or deleting your working database and configuration. This is safer than immediately reinstalling or wiping indexes.

1. Exit all Everything processes.
2. Download or copy a trusted portable build into a new local, user-writable folder.
3. Do not place it in a synchronized folder or protected program directory.
4. Launch it directly without your usual shortcut or startup script.
5. Change one harmless option and exit normally.
6. Relaunch the same executable and check the option.

If the temporary copy works, Windows can persist Everything settings and the fault lies in the original folder, configuration, launcher, account, synchronization process, or competing instance. Compare those items one at a time.

If the clean copy also fails, examine security events, profile permissions, cleanup software, and forced process termination. Stop changing settings once the test option survives two clean relaunches and one Windows restart. At that point, return to the original feature and test it separately.

7. Quick Fix Checklist

• Change one harmless option and test a normal exit before doing anything destructive.
• Confirm whether the problem affects all settings or only a filter or index option.
• Check the active AppData or portable INI location and its modified time.
• Move portable Everything to a normal local folder with write permission.
• Exit through the tray or File menu instead of terminating the process.
• Close duplicate instances and verify every executable path and startup command.
• Review Controlled Folder Access and antivirus logs for a specific blocked write.
• Test outside cloud-synchronized folders to rule out file rollback conflicts.
• Verify the Windows account and mapped-drive context used at startup.
• Rebuild an index only after proving that indexing, not settings persistence, is faulty.

8. Frequently Asked Questions

8.1 Where are Everything settings stored?

Per-user installations commonly use the current user's application-data area, including %APPDATA%\Everything. Portable configurations may use an INI file beside the executable. The decisive test is to watch which configuration file changes after a normal exit.

8.2 Why do settings reset only after rebooting Windows?

A startup shortcut, scheduled task, second instance, different user context, synchronization client, or forced shutdown may be involved. First prove that settings survive a manual exit and relaunch. Then compare the executable and command used after Windows starts.

8.3 Should I delete the Everything database?

Not as an initial step. Deleting or rebuilding an index does not repair an unwritable settings file. Use Force Rebuild only when configured sources are correct but indexed results are stale or inconsistent.

8.4 Why are Everything results missing even though settings persist?

Check active filters, search switches, exclusions, omitted-result rules, volume indexes, folder indexes, network availability, and search syntax. Missing results are often an indexing or query issue rather than a global persistence failure.

8.5 Can multiple portable copies overwrite each other's settings?

They can create confusing results if they share configuration paths, use the same instance context, or are launched by different shortcuts. Exit every copy and test one executable from one writable folder before restoring automatic startup.

8.6 Is Everything the same as Windows Search?

No. Everything is a filename-search application from voidtools, while Windows Search is a separate Windows indexing and search platform. Changing Windows Search settings will not usually fix Everything's INI write permissions, instance selection, or portable configuration.