Everything High CPU Usage: How to Fix It

Everything by voidtools normally provides fast filename search with modest background overhead. If Everything is using more CPU than expected, the cause is usually an active initial index, repeated folder or network-share scanning, an expensive search, property or content gathering, file-system changes, security software interaction, or a configuration that repeatedly restarts work. The safest approach is to identify what Everything is doing before rebuilding indexes or changing several settings.

This guide focuses specifically on CPU usage by Everything on Windows. Everything is not Windows Search: Windows Search maintains its own index and can inspect file contents and properties, while Everything primarily delivers rapid filename indexing and search. Depending on your configuration and Everything edition, it can also index folders, query content, gather properties, or connect to servers. Those additional operations can require substantially more CPU and input/output activity.

1. Confirm the Symptom With a Small Safe Test

Begin by confirming that Everything itself is consuming CPU. Open Task Manager, select the Processes or Details page, and find Everything.exe. If you use the Everything service, you may also see Everything.exe running under another account or a service-related process. Sort by CPU and watch the value for several minutes rather than relying on one brief spike.

A short burst during startup is not automatically a fault. Everything may be loading its database, reading an NTFS change journal, processing accumulated file-system changes, scanning folder indexes, or restoring a search. CPU usage should generally settle after the active work finishes. The exact normal percentage depends on the processor, storage, index size, and enabled features.

1.1 Run a blank-search test

Click the search box, press Ctrl+A, delete the current query, and wait. Also reset any active filter to Everything. A content query, regular expression, property search, or restrictive filter can continue evaluating files and make the application appear busy.

If CPU usage falls after clearing the query, the index is probably healthy. The issue is more likely the search expression or a feature invoked by it. Stop changing index and service settings at this point. Reintroduce the query one component at a time to find the expensive term.

1.2 Compare startup activity with persistent activity

Close Everything normally, reopen it, and observe the CPU timeline. Distinguish these patterns:

• A startup spike that declines indicates database loading, initial indexing, or change-journal processing.
• Regular spikes at a predictable interval suggest folder or network-share rescans.
• High CPU only with one query suggests content, property, regex, or broad search evaluation.
• CPU that never settles can indicate repeated indexing, inaccessible locations, rapid file changes, or software interaction.

Success means identifying a repeatable trigger. Once you can make the CPU rise and fall predictably, address that trigger instead of applying unrelated Windows performance tweaks.

2. Check Everything Settings Directly Related to CPU Usage

2.1 Check the current search and active work

Inspect the status bar and any visible indexing or job indicators. The wording and menu locations vary between stable and preview builds, but look for evidence that Everything is indexing, scanning, sorting, gathering properties, or evaluating content. A large result count is not necessarily a problem because filename results normally come from the index. However, sorting a huge result set by a property that must be gathered can be expensive.

Clear the search, switch back to a basic filename-oriented view, and remove unnecessary property columns. If CPU falls, add columns or search operators back individually. Success is a stable idle state with the required search still working.

2.2 Separate initial indexing from ongoing monitoring

Initial indexing reads information needed to build the database. This can produce temporary CPU and disk activity, especially with millions of files or multiple volumes. Ongoing monitoring should usually be lighter because Everything can process file-system changes instead of scanning every file again.

If each launch behaves like a fresh initial index, review the index and database-related options. Check whether the database can be saved in the configured location, whether the application is being closed cleanly, and whether portable mode is using a writable folder. A portable copy launched from read-only media, a protected directory, or a location cleaned at sign-out may be unable to preserve its state.

Success means a later restart loads the existing index or processes only accumulated changes instead of repeating a full build. Once that happens and CPU settles, do not force another rebuild.

2.3 Review folder indexing

Folder indexing is different from native NTFS change-journal indexing. It is useful for locations that cannot be indexed through the normal local-volume method, including some network shares and non-NTFS file systems. However, folder indexes may need scheduled or triggered rescans. A large directory tree can therefore create recurring CPU and network activity.

Open Everything's Options and inspect the folder-index settings. Look for duplicated paths, overlapping parent and child paths, aggressive rescan intervals, unavailable locations, and shares that contain frequently changing files. Remove only entries you do not need. For required shares, choose a rescan schedule appropriate to how quickly results must update.

Success looks like a folder scan completing and CPU returning to idle. If reducing the scan frequency solves the symptom, stop there. Do not rebuild unrelated local indexes.

2.4 Check content search and property gathering

Everything's core strength is filename search. Content searches must open candidate files and inspect data, while some properties must be obtained from files or Windows property handlers. These operations can be CPU-intensive and may also trigger antivirus scanning.

Review the current query for content-related functions, property conditions, regular expressions, or broad wildcards. Limit the scope first by adding a path, extension, size, or date condition that can reduce the candidate set. For example, searching the contents of a specific project folder is safer than applying content search across every indexed volume.

Also check whether the result view is gathering expensive properties for thousands of files. Temporarily switch to basic columns such as name, path, size, and modified date. Success means the same practical task completes against a smaller candidate set without sustained CPU usage.

2.5 Review filters, exclusions, and result omissions

An unexpected filter can cause users to repeat searches or assume that the index is broken. Conversely, missing exclusions can make Everything monitor temporary build directories, caches, backup trees, or other locations with constant file churn.

Set the active filter to Everything, then test a known filename in a known local folder. Review exclusions and any result-omission options if that file is missing. Excluding a high-churn directory may reduce processing, but confirm that you do not need its results. Success means expected files appear and rapidly changing, irrelevant locations no longer generate unnecessary work.

2.6 Inspect server and command-line options

If you use an Everything server, ETP, HTTP access, an SDK integration, or command-line automation, determine whether a client or script is submitting repeated expensive queries. Do not expose an Everything search service directly to the public internet. Restrict access with appropriate host firewall rules, authentication where supported, and a trusted network or secure tunnel.

Check scheduled tasks, login scripts, monitoring tools, and shortcuts for command-line options that force reindexing, start a server, load an alternate configuration, or execute a search at launch. Temporarily start Everything from its normal shortcut without optional arguments. Success means CPU remains low until the external client, script, or special option is restored.

3. Check Windows and Storage Conditions

3.1 Verify the service and account context

The Everything service can provide the interface with access to local NTFS indexing information without requiring the user interface to run elevated. Problems can arise when multiple copies use different accounts, configurations, or databases.

Check Task Manager and the Services console for duplicate or unexpected instances. Confirm whether you intended to use the service and whether the user interface is connecting as expected. Avoid randomly switching between elevated and non-elevated launches because this can change accessible locations and configuration context.

For portable installations, confirm which INI file and database location are actually being used. Success means one intended configuration is active, local volumes appear once, and restarting under the normal account does not launch another complete indexing cycle.

3.2 Test mapped drives and network shares by UNC path

Mapped drive letters belong to a Windows logon session. A service or elevated process may not see the same mappings as the interactive user. If a folder index points to an unavailable mapped drive, Everything may repeatedly encounter delays or failed scans.

Open the location in File Explorer under the same user context. When practical, configure the share with its UNC path, such as a server and share path, rather than relying on a mapped letter. Verify name resolution, credentials, and NAS availability. Do not repeatedly rescan an offline NAS while troubleshooting.

Success means the share opens promptly, one scan finishes, expected files appear, and CPU activity stops. If CPU remains low while the share is removed but rises when it returns, focus on that share's size, accessibility, change rate, and rescan schedule.

3.3 Account for file-system type

NTFS local volumes can support efficient indexing through file-system metadata and change tracking. Other file systems, removable storage, and network shares may require folder indexing or another supported method. Treating every location as though it behaves like a local NTFS volume can lead to unnecessary rescans.

Check the file-system type in the drive's Windows properties. Then review how that location is included in Everything. If a removable disk is frequently disconnected, avoid a schedule that continually attempts to scan it. Success is an indexing method appropriate to the storage type and update requirements.

3.4 Check antivirus interaction without disabling protection permanently

Content search, property gathering, database writes, and large folder scans can cause security software to inspect many file operations. This may increase CPU in Everything, the antivirus process, or both. Use Task Manager to compare their activity and check your security product's event or protection history for repeated scans or blocks.

Do not permanently disable antivirus protection. First update both products, finish a controlled small-scope test, and determine whether filename-only searches remain fast. If an exclusion is genuinely necessary, use the narrowest path or process rule allowed by your organization's policy, document it, and avoid excluding broad user-data or download locations.

Success means normal protection remains enabled and Everything can complete its legitimate indexing work without repeated scanning loops.

4. Use Diagnostic and Recovery Tools Carefully

4.1 Test known files with simple syntax

Create or choose a harmless, uniquely named test file in a local indexed folder. Search for its exact filename with no content operator, regex mode, or special filter. Then rename the file and verify that the result updates.

If the original file appears and the rename updates promptly, basic indexing and monitoring work. Stop investigating the core local index and focus on the specific query, network location, or optional feature that causes high CPU.

4.2 Examine the Index Journal and debug output

If your Everything build provides an Index Journal, debug console, or logging option, use it briefly while reproducing the issue. Look for the same volume, folder, query, or operation repeating continuously. Logging itself can add overhead, so disable it after collecting a short sample and avoid sharing logs without checking them for private paths and filenames.

A useful finding is a repeating action correlated with each CPU spike. If the log is quiet while CPU remains high, capture the exact process, account, query, and timing before seeking support.

4.3 Use Force Rebuild only after safer checks

A rebuild is appropriate when a known local file is consistently missing, index updates have stopped, or diagnostics indicate index corruption. It is not the first response to every CPU spike because rebuilding deliberately creates indexing work.

Before using Force Rebuild, clear the query, let current jobs finish, verify writable configuration storage, and check folder-scan schedules. Then rebuild once and allow it to complete without repeatedly restarting Everything. Success means the test file appears, renames update, and CPU settles after the rebuild. If repeated rebuilds are required, the underlying storage, permission, shutdown, or configuration problem remains unresolved.

5. Run a Clean Temporary Test

When no single setting explains the problem, test with a temporary clean configuration rather than changing the working profile repeatedly. Exit the existing instance and preserve its configuration. Launch a separate portable copy or clean profile in a writable temporary folder, making sure it does not reuse the production database or start duplicate servers.

1. Index one small local NTFS volume or test folder.
2. Leave the search blank and wait for initial work to finish.
3. Run a simple filename search for a known file.
4. Add one required folder index, share, filter, column, or server feature.
5. Observe CPU after every addition.

If the clean test remains quiet, the original configuration or one optional feature is responsible. Compare settings methodically instead of replacing everything. If the clean test also shows persistent CPU with only a small local scope, record the Everything build, Windows version, storage type, process CPU, and reproduction steps for voidtools support.

Stop changing settings as soon as CPU settles after initial work and the known-file test updates correctly. Low idle CPU, accurate results, and one completed indexing cycle are stronger signs of success than making every option match a generic recommendation.

6. Quick Fix Checklist

• Confirm Everything.exe is the process using CPU and observe it for several minutes.
• Clear the search box and reset the active filter to Everything.
• Wait for legitimate initial indexing or journal processing to complete once.
• Remove content, regex, and expensive property operations from the test query.
• Check folder indexes for duplicates, overlaps, unavailable paths, and frequent rescans.
• Test network shares separately and prefer stable UNC paths where appropriate.
• Confirm portable configuration and database locations are writable and persistent.
• Check for duplicate instances, unexpected account contexts, scripts, and command-line options.
• Compare Everything and antivirus activity without permanently disabling protection.
• Use a simple known-file rename test to verify ongoing monitoring.
• Run a clean temporary profile before modifying many production settings.
• Force a rebuild only when evidence points to an index problem.

7. Frequently Asked Questions

7.1 Why does Everything use high CPU immediately after startup?

It may be loading its database, building an initial index, processing file-system changes accumulated while it was closed, or scanning configured folders. Let one cycle finish while watching the status indicators. If CPU settles and later starts are lighter, the behavior was temporary. If every launch repeats a full cycle, check whether the database and portable configuration can be saved.

7.2 Why does CPU rise only when I search?

The query may invoke content inspection, regular expressions, properties, complex sorting, or a very broad candidate set. Clear the query, confirm that filename-only search is fast, then narrow the path and file type before restoring the expensive operator. This isolates an expensive search from an indexing fault.

7.3 Can network shares cause Everything high CPU usage?

Yes. Folder indexing a large share can require recursive scans, and an unavailable or frequently changing NAS can make the work recur. Check the rescan schedule, remove duplicate paths, verify the share under the correct account, and test the location independently. Successful troubleshooting ends with one completed scan and predictable update behavior.

7.4 Why is my Everything index not updating?

Test a uniquely named local file and rename it. If local NTFS results update but a network share does not, investigate that share's folder-index schedule and connectivity. If local updates also fail, check the service state, account context, exclusions, writable database location, and journal diagnostics before performing one Force Rebuild.

7.5 Why are Everything results missing?

Common causes include an active filter, an exclusion, result-omission settings, an unindexed volume, an offline folder index, or a query that is more restrictive than intended. Reset the filter, use a plain exact-filename test, and confirm that the file's location is included. Missing results alone do not prove that the database must be deleted.

7.6 Is Everything the same as Windows Search?

No. Everything is a separate voidtools application designed primarily for very fast filename search. Windows Search is a Windows component with its own indexing service and broader content and property integration. High CPU in SearchIndexer.exe should be diagnosed as a Windows Search issue, while high CPU in Everything.exe should be traced through Everything's searches, indexes, folders, servers, and configuration.