Everything Run History Not Updating: How to Fix It

When Everything run history is not updating, filenames may still appear instantly while the Run Count and Date Run columns remain blank, stale, or unchanged. This usually does not mean the main filename index is broken. Run history is a separate feature that records items opened through voidtools Everything, so the most likely causes are a disabled history setting, opening files outside Everything, settings that cannot be saved, automatic history clearing, an unexpected instance or profile, or sorting that makes updated values difficult to see.

This guide focuses specifically on run history in Everything for Windows. It distinguishes run-history problems from missing search results and Windows Search problems, then walks through safe tests before more disruptive troubleshooting. After each change, perform the same controlled test. Once the Run Count increases and Date Run changes, stop adjusting unrelated settings.

1. Confirm the Symptom With a Small Safe Test

Begin with a file you can safely open, such as a local text document. Using one known file prevents network delays, application failures, exclusions, and duplicate filenames from obscuring the result.

1. Create a text file in your Documents folder with a distinctive name, such as run-history-test-unique.txt.
2. Open Everything and search for the complete filename.
3. Confirm that exactly one expected result appears.
4. Show the Run Count and Date Run columns if they are hidden. Right-click the result-list column header and enable the relevant columns.
5. Open the file from the Everything result list, normally by double-clicking it or selecting it and pressing Enter.
6. Return to Everything and inspect Run Count and Date Run.
7. Open the same result once more and check whether Run Count increases again.

Success means Date Run reflects the recent launch and Run Count increases after each successful opening from Everything. A short display delay or refresh may occur, but the values should not remain permanently unchanged.

1.1 Why Opening Through Everything Matters

Everything run history is not a system-wide record of every file opened in Windows. It records launches performed through Everything. Opening the test file from File Explorer, a desktop shortcut, an application's recent-files menu, or a command prompt does not provide a valid run-history test.

Everything is also different from Windows Search. Everything builds and queries its own filename indexes, while Windows Search uses Windows indexing services and can index file content and other properties. Rebuilding the Windows Search index will not repair Everything run history.

1.2 Separate History Problems From Search Problems

If the test file appears but its Run Count and Date Run do not change, search indexing is working and the problem is limited to history recording or persistence. If the file does not appear at all, investigate an Everything index, exclusion, folder-index, drive, server, or result-omission issue first. History cannot update for a result that Everything cannot find and launch.

2. Check Run History Settings and Result Behavior

2.1 Enable Run History

Open Everything's Options window and locate the Run History settings. Verify that run history is enabled. The exact placement can differ between Everything editions or builds, so use the Options search or browse the History-related page rather than relying on a memorized menu path.

Apply the setting, close the Options window, and repeat the local text-file test. If Run Count advances and Date Run changes, the issue is fixed. Do not rebuild indexes or change service settings after this point.

2.2 Check Retention and Privacy Clearing

Run history can be deliberately cleared for privacy. Review any history-retention, clearing, or exit-related behavior available in the installed build. Also consider whether a cleanup utility, logoff script, profile-reset tool, kiosk policy, or portable-app launcher removes Everything's settings or history data.

A retention problem often has a recognizable pattern: values update during the current session but disappear after Everything closes, Windows restarts, or a scheduled cleanup runs. Test this carefully by opening the file through Everything, confirming the changed count, exiting Everything normally, reopening it, and checking the same result.

If the value survives a normal restart, persistence is working. If it disappears only after a cleanup task or sign-out, investigate that event rather than changing the filename index.

2.3 Confirm That the Launch Actually Succeeds

Everything should be able to pass the selected path to Windows or the associated application. If a file association is broken, a removable disk is offline, credentials are unavailable, or the target has been removed, an attempted launch may not behave like a normal successful opening.

Use a local TXT file with a working association to rule out those variables. Once local history works, repeat the test with the original file type or network location.

2.4 Check Sorting by Run History

Sorting affects presentation, not whether history is recorded. Click the Run Count or Date Run column header to sort by that field. Confirm the sort direction, because ascending order can place the most recently used item far from the visible rows.

Also clear any active search that relies on run-history properties while testing. A restrictive query can remove an item from view immediately after its value changes. Search for the exact filename alone, update it, and then inspect its columns.

3. Check Settings Write Permissions and Profile Context

3.1 Verify That Everything Can Save Its Data

If run history works only until Everything exits, the process may be unable to write its settings or history storage. This is especially common with portable copies placed under protected directories, read-only media, controlled enterprise folders, synchronized locations, or folders owned by another account.

Check where the active Everything instance stores its configuration. An installed per-user setup commonly uses the user's application-data location, while a portable configuration may keep files beside the executable depending on its settings. Do not assume the visible executable is using the configuration file beside it, particularly when multiple installations exist.

Close Everything normally and inspect the relevant folder's permissions and read-only state. The current user should have permission to create and modify files there. A safe diagnostic is to place a portable test copy in a folder owned by your account, such as a new folder inside Documents, rather than granting broad permissions to Program Files or running Everything as administrator permanently.

Success means the test count remains after Everything is closed and reopened under the same account.

3.2 Look for Multiple Instances or Accounts

Everything can be launched through startup entries, shortcuts, portable launchers, scheduled tasks, or named instances. Two instances may use different settings and history. Likewise, an elevated process and a standard desktop process can run under different contexts, and a service may run independently from the user interface.

Exit all visible Everything windows, inspect the notification area and Task Manager, then launch one known executable from one known shortcut. Check its Options and repeat the test. If the behavior changes depending on the shortcut used, consolidate your startup entries or configure the intended instance consistently.

On shared or managed computers, test under the same Windows account that normally runs Everything. Run-history values should not be expected to follow automatically between unrelated user profiles.

3.3 Review Command-Line and Portable Launchers

A shortcut or launcher can supply command-line options that select an instance, configuration, database, startup behavior, or other mode. Review the shortcut's Target field and any batch file or portable-app launcher used to start Everything. Compare it with a direct launch of the intended executable.

Do not remove options blindly. Save a copy of the original command, then test without the launcher in a user-writable temporary folder. If direct launching preserves history but the launcher does not, the launcher or selected profile is the boundary of the problem.

4. Handle Network Shares, Services, and Missing Results Correctly

4.1 Understand What the Everything Service Does

The Everything service primarily helps Everything index local NTFS volumes without requiring the user interface to run with administrative rights. It is not normally responsible for recording a user's file launches. Restarting or reinstalling the service is therefore not a first-line Everything run history fix when local results appear correctly.

Use the local text-file test to prove this distinction. If the local file is found and its history updates, the service and basic history mechanism are adequate. Concentrate on the original location or launch path.

4.2 Test Mapped Drives and Network Shares

Mapped drive letters can differ by Windows account and elevation level. A share available to a standard desktop session may not be visible to an elevated process, service account, scheduled task, or different user. NAS credentials may also expire or reconnect after Everything starts.

If the affected result is on a NAS, confirm that the exact path shown by Everything opens under the same account and process context. Compare the mapped path with its UNC form where appropriate. Avoid exposing an Everything server or file-search interface directly to the public internet. Remote access should use trusted networks, proper authentication, and established secure access controls.

Firewalls and antivirus products are relevant only when a remote Everything server, network protocol, or security block is actually involved. Review logs and allow the specific trusted program or connection if required. Do not disable security software permanently.

4.3 Check Folder Indexes, Exclusions, and Result Omissions

Run history and indexing are separate, but indexing matters when the underlying symptom is Everything results missing. In Options, verify that the affected volume or folder is included and available. Review folder indexes, exclusions, omitted results, offline volumes, and any active filters.

NTFS volumes can usually use Everything's native indexing approach. Other file systems, NAS shares, and some mapped locations may require folder indexing or a remote Everything server. Folder indexing may update on a schedule or after change monitoring, depending on the configuration.

Success at this stage means the intended file appears under a plain exact-filename search. Only then should you test whether opening that result changes its history.

5. Use Targeted Diagnostics Without Destroying Useful Data

5.1 Read the Status Bar and Simplify the Search

The status bar can reveal whether a query returns no objects, whether a filter is active, and whether Everything is still processing work. Reset to an unfiltered filename search and remove advanced syntax temporarily. Select the Everything filter if a narrower filter is active.

Search for the exact test filename, then add run-history syntax only after the columns visibly update. This distinguishes recording failures from query mistakes. Search syntax and property availability can vary by Everything generation, so consult the documentation for the installed edition instead of guessing property names.

5.2 Use Debug Logging for a Reproducible Failure

If the controlled test still fails, enable Everything's supported debug or diagnostic logging, reproduce one launch, and inspect the messages around that action. Record the executable path, Windows account, whether the process is elevated, the target path, and whether the value survives restart.

Logs can help reveal configuration paths, access failures, unexpected instances, and launch errors. They may also contain filenames or paths, so review and redact private information before sharing them.

5.3 Treat Force Rebuild as an Index Tool

Force Rebuild recreates Everything's filename index. It can be appropriate when indexed results are demonstrably stale or missing, but it is not the normal remedy for Run Count or Date Run failing to change. Rebuilding can consume time on large systems and distract from a settings-persistence problem.

Before rebuilding, verify the affected volume, folder-index configuration, exclusions, and availability. Never delete Everything's database as an initial run-history step. If the exact local file already appears, the filename database has done its job.

5.4 Use the Index Journal When Results Are Stale

If files are missing or changes are not reaching the index, the Index Journal and related diagnostics can help show indexing activity. This is useful for Everything index not updating, but it does not directly prove that run-history data is being written.

Use the correct diagnostic for the symptom: the journal for filename-index changes, and the Run Count and Date Run columns plus a restart test for history persistence.

6. Run a Clean Temporary Test Before Broad Changes

A clean test can isolate configuration corruption, unwritable storage, startup arguments, and profile-specific policies without damaging the working installation.

1. Download or use a trusted copy of Everything from voidtools.
2. Create a temporary folder inside a location your account can write to.
3. Place the portable test files there, keeping them separate from the normal installation.
4. Exit other Everything user-interface instances to avoid confusion.
5. Start the temporary copy without the normal launcher or custom command line.
6. Enable run history in that test profile.
7. Search for and open the local test text file through the result list.
8. Confirm Run Count and Date Run, close normally, reopen, and check persistence.

If the clean profile works, Windows can record history and the original profile, launcher, permissions, or cleanup behavior is responsible. Compare settings methodically instead of replacing everything at once. If the clean profile also fails, collect debug information and confirm the exact build and launch method before requesting support.

Keep the test isolated. Do not overwrite the original configuration or delete its database and history files merely because a temporary profile works.

7. Quick Fix Checklist

• Enable Run History in Everything's Options.
• Open a known local file from Everything, not from File Explorer.
• Display the Run Count and Date Run columns.
• Search by exact filename without restrictive filters or history syntax.
• Confirm the selected item launches successfully.
• Check whether the value survives a normal Everything restart.
• Verify that the active settings location is writable by the current user.
• Check for multiple instances, startup shortcuts, and portable launchers.
• Review privacy tools or policies that clear history.
• Use a local test before troubleshooting mapped drives or NAS paths.
• Investigate indexing only when the file itself is missing or stale.
• Avoid Force Rebuild or database deletion for a history-only symptom.
• Stop changing settings as soon as counts update and persist.

8. Frequently Asked Questions

8.1 Why Does Run Count Stay at Zero?

The most common reasons are that run history is disabled, the file was opened outside Everything, the launch did not complete normally, or the active instance cannot save history. Enable the feature and open one local file directly from Everything to identify which category applies.

8.2 Why Does Date Run Update but Disappear After Restart?

This strongly suggests a persistence problem. Check write permissions for the active configuration location, portable-folder restrictions, multiple profiles, and privacy or cleanup tools. If history survives within one session but not a restart, rebuilding the filename index is unlikely to help.

8.3 Does Everything Track Files Opened From File Explorer?

No. Everything run history is associated with items launched through Everything. It is not a complete Windows-wide usage audit. Test by launching the result from the Everything window itself.

8.4 Can Sorting Stop Run History From Updating?

No. Sorting only changes where results appear. However, sorting in the unexpected direction or using a run-history filter can make a changed result move out of view. Search for the exact filename and inspect its columns directly.

8.5 Should I Rebuild the Everything Index?

Only when filenames are missing or stale after you have checked the relevant volume, folder index, exclusion, and availability settings. If the file appears correctly and only its Run Count or Date Run is wrong, focus on run-history settings and write persistence.

8.6 Why Does History Work Locally but Not for NAS Files?

The NAS path may be unavailable in the current account context, mapped under a different drive letter, indexed through a different instance, or failing to launch because credentials have expired. Confirm that the exact result path opens from the same Everything process. Local success proves that the basic history feature works, so stop changing global history settings and investigate the network path.