Everything Wildcard Search Not Working: How to Fix It

When wildcard searches in voidtools Everything return too many files, too few files, or no files at all, the index is not necessarily broken. The most common causes are wildcard mode being disabled, the whole-filename wildcard option changing how patterns are interpreted, an active filter, an overly restrictive search modifier, or the target location not being indexed. Network shares, portable configurations, account context, and remote-search clients can introduce additional complications. This guide isolates wildcard behavior first, then moves through indexing and Windows-related checks without deleting the database or changing many settings at once.

1. Confirm the Symptom With a Small Safe Test

Begin with a controlled test against files you can see in File Explorer. This separates wildcard interpretation from indexing, permissions, and network availability.

1.1 Create a simple filename test

Create a temporary folder on a local drive and add three empty files:

• report.txt
• report-final.txt
• report1.txt

Open Everything, clear the existing search, and make sure the status bar indicates that searching has completed. Search for the exact filename report.txt. If that file does not appear, the immediate problem is not wildcard matching. Everything may not be indexing the location, the file may be excluded, or a filter may be hiding it.

If the exact filename appears, test these patterns:

• report*.txt should match names beginning with “report” and ending in “.txt”
• report?.txt should match a name with exactly one character between “report” and “.txt,” such as report1.txt
• *.txt should match text files when wildcard processing is active

An asterisk represents zero or more characters. A question mark represents one character. Therefore, report*.txt can match report.txt, while report?.txt cannot because the latter requires one additional character.

Success means the three test patterns behave consistently with those rules. Once they do, stop changing global wildcard settings. Any remaining problem is probably tied to the original query, filter, extension condition, or indexed location.

1.2 Clear hidden restrictions before testing

A wildcard test is unreliable if an old filter or search option is still active. Clear the search box, choose the Everything filter, and temporarily turn off options such as Match Case, Match Path, Match Whole Word, and regular-expression mode unless the test specifically needs them.

Also inspect the status bar. It can reveal that a filter is active, that only a small result set is being searched, or that Everything is still processing an index update. The exact status presentation can vary by configuration, but a completed local search should respond immediately.

2. Check the Wildcard Options That Change Matching

If exact filenames work but wildcard patterns do not, inspect wildcard processing before rebuilding an index. Indexes store filenames and paths. Search options determine how a query is interpreted.

2.1 Enable wildcard processing

Everything provides a wildcard search option and search modifiers that can enable or disable wildcard interpretation. Check the Search menu and ensure wildcard matching is enabled for the test. If you prefer not to change the global state, add the wildcards: modifier to the query.

For example, test wildcards:report*.txt. This explicitly requests wildcard processing for that search. If this works while report*.txt does not, the index is healthy and the problem is the current wildcard option or a saved search state.

Conversely, nowildcards: can disable wildcard interpretation. Remove that modifier if it appears in a bookmark, macro, saved search, command-line argument, or copied query.

Success means the explicit wildcards: test returns the expected files. At that point, decide whether to keep using the modifier or enable wildcard matching through the interface. Do not rebuild the database.

2.2 Understand whole filename wildcard matching

The “Match whole filename when using wildcards” option is a frequent source of apparently missing results. When whole-filename matching is enabled, a wildcard expression is expected to match the complete filename rather than merely a portion of it.

Suppose a file is named annual-report-final.txt. Depending on the option state, the query report* may fail because the actual filename begins with “annual,” not “report.” A broader pattern such as *report* accounts for text before and after the word.

Use these comparisons:

• report* targets filenames beginning with “report” under whole-filename matching
• *report* targets filenames containing “report” anywhere
• *report*.txt targets text filenames containing “report”

If adding the leading asterisk restores the expected result, Everything is working correctly. The earlier pattern was anchored by whole-filename wildcard behavior. Stop troubleshooting the index and adjust the pattern or the relevant option according to your preferred workflow.

2.3 Search for literal wildcard characters safely

On standard Windows file systems, the asterisk and question mark are reserved filename characters. Normal Windows filenames cannot contain them. As a result, a request to find a local filename containing a literal * or ? is usually based on a displayed label, archive member, remote-system name, or search expression rather than a real Windows filename.

If you need wildcard symbols treated as ordinary query text rather than operators, disable wildcard interpretation for that portion of the search with nowildcards: or turn off wildcard matching. Quoting is useful for phrases and spaces, but it should not be treated as a universal substitute for disabling wildcard parsing. If the target comes from a non-Windows system, verify how the name is represented after it is exposed through Windows or a network client.

2.4 Combine wildcards with ext correctly

The ext: search function is often clearer than putting an extension into a wildcard pattern. For example, use wildcards:*report* ext:txt to find text files whose names contain “report.”

Keep a space between the filename condition and ext:. The space acts as an AND condition, so both requirements must match. For multiple extensions, use the extension syntax supported by Everything rather than writing a single malformed wildcard.

Test each part separately:

1. Search *report* and confirm the filename portion works
2. Search ext:txt and confirm text files appear
3. Combine them as *report* ext:txt

If each individual condition works but the combination returns nothing, no indexed file currently satisfies both conditions. That is valid search behavior rather than a wildcard failure.

3. Check Filters, Omissions, and Indexed Locations

When wildcard syntax works in the temporary folder but not in the real location, determine whether Everything knows about that location and whether results are being omitted.

3.1 Reset filters and result omissions

Select the Everything filter rather than Audio, Documents, Executables, Pictures, or a custom filter. A custom filter can append unseen search conditions, making a correct wildcard appear broken.

Check whether result omission features, temporary exclusions, or bookmarks are affecting the search. Start from a new window if necessary. Avoid testing through a bookmark until the raw query works, because bookmarks can store search text, filters, sort choices, and other state.

Success means the missing file appears after choosing the Everything filter or removing an omission. Restore only the restrictions you actually need.

3.2 Verify that the drive or folder is indexed

Everything can index local NTFS volumes efficiently through file-system metadata. Other file systems, selected folders, removable media, and network shares may require folder indexing or another configured mechanism. Everything is not Windows Search, and changing Windows Search indexing options does not repair an Everything index.

Open Everything’s Options and inspect the Indexes pages. Confirm that the relevant local volume or configured folder is included. Then search for the exact full filename without wildcards. If no exact result exists, wildcard changes cannot make it appear.

Also review exclusion settings. A drive, folder, filename pattern, hidden item category, or system item category may have been excluded deliberately. Remove only the exclusion responsible for the missing location.

Success means a newly created test file in the target location appears by its exact name and then responds correctly to a wildcard pattern.

3.3 Check whether the index is updating

If old files appear but new files do not, the issue is an index update problem rather than wildcard syntax. Compare an existing indexed file with a newly created file in the same directory. Check the Index Journal, where available, and look for recent changes or signs that updates are paused or unavailable.

Use Force Rebuild only after confirming that the correct volume or folder is configured and that ordinary refresh behavior has failed. A rebuild can be useful, but it should not be the first response to one misunderstood wildcard expression. Do not manually delete the database as an initial step.

Success means new files begin appearing automatically. Once they do, retest the original wildcard and stop making index changes.

4. Check Services, Accounts, Network Shares, and Portable Settings

Local wildcard behavior and file discovery are separate layers. If the pattern works locally but not on a NAS, mapped drive, remote server, or portable installation, check how that source reaches Everything.

4.1 Verify service and startup state

Everything can use its service to access local NTFS indexing information without requiring the user interface to run with unnecessary elevation. In Options, confirm the intended service configuration and check Windows Services if the service is expected but unavailable.

A service problem usually affects indexing or access, not the meaning of * and ?. Test an exact filename first. Restarting the Everything application or its service may restore an interrupted configuration, but repeated restarts will not correct a pattern that conflicts with whole-filename matching.

4.2 Account for mapped drives and network shares

Mapped drive letters belong to a user session. A service or application running under another account may not see the same mappings. If a mapped drive is missing, test the UNC path, such as \\server\share, and verify that the account running the relevant process can access it.

For NAS content, confirm that the share is configured for folder indexing if required and that the share is online during updates. Check permissions by opening the target folder in File Explorer under the same Windows account. Do not expose an Everything HTTP, ETP, or other search server directly to the public internet merely to solve a local search problem.

Success means an exact filename from the share appears, followed by the expected wildcard result. If the exact name remains absent, continue troubleshooting share access or indexing rather than search syntax.

4.3 Review firewall and security software narrowly

A local wildcard query normally does not require a firewall exception. Firewall checks become relevant when the client connects to an Everything server, a remote endpoint, or a network share. Verify the configured host, port, network profile, and server availability.

Security software can also interfere with application files, configuration files, interprocess communication, or network connections. Review its event history and create a narrow, documented exception only if there is evidence of blocking. Do not disable antivirus or firewall protection permanently.

4.4 Compare installed and portable configurations

A portable copy can load a different configuration from an installed copy. That configuration may have different wildcard settings, filters, exclusions, indexes, or command-line arguments. Confirm which executable is running and where its configuration is stored.

Inspect shortcuts and startup entries for parameters that load another configuration, connect to a server, disable a feature, or prepopulate a search. Launch the intended executable directly for a clean comparison.

If one copy handles wildcards:*report* ext:txt correctly and another does not, compare their search and index options instead of rebuilding both databases.

5. Use Diagnostics Without Losing a Working Configuration

Diagnostics are most useful after the small test has identified whether the failure concerns parsing, indexing, or access.

5.1 Read the status bar and Options pages

The status bar provides an immediate result count and can expose unexpected search scope. Options shows which volumes and folders are indexed, which paths are excluded, and how search features are configured. Record the current settings before changing them.

Make one change, repeat the same query, and note the result. This method is slower than changing five options at once, but it identifies the real cause and avoids creating a second problem.

5.2 Use debug information when behavior remains unexplained

Everything provides diagnostic and debugging facilities that can help reveal parsed searches, configuration activity, index updates, and connection problems. Enable diagnostics only long enough to reproduce the issue, then review the output for errors related to the target volume, folder, server, or query.

Logs may contain filenames, paths, server names, and search terms. Treat them as sensitive, especially on business systems. Redact private information before sharing diagnostic output with support staff or community forums.

5.3 Rebuild only when evidence points to the index

A Force Rebuild is appropriate when configured locations are correct, exact filename searches fail, changes are not entering the index, and simpler refresh or service checks have not helped. It is not appropriate merely because report* did not match annual-report.txt under whole-filename matching.

After a rebuild, success means the exact target filename appears and new files update normally. If exact results are still absent, recheck exclusions, volume selection, folder-index configuration, permissions, and source availability.

6. Run a Clean Temporary Test

Before resetting your main configuration, run a temporary clean test. Use a separate portable copy or temporary configuration in a folder you control. Do not point it at sensitive network services or overwrite your normal settings.

1. Create a local test folder with the three example files
2. Start the temporary Everything instance with a clean configuration
3. Ensure the test location is indexed
4. Choose the Everything filter
5. Test wildcards:report*.txt
6. Test wildcards:*report* ext:txt
7. Compare whole-filename wildcard behavior

If the clean instance works, the cause is likely a setting, filter, exclusion, bookmark, startup parameter, or configuration difference in the normal instance. Compare settings methodically rather than replacing the working profile immediately.

If the clean instance also fails to find an exact filename, focus on indexing eligibility, permissions, file-system type, or access to the source. Stop changing wildcard options because they cannot fix a file that is absent from the searchable index.

7. Quick Fix Checklist

• Confirm an exact filename appears before testing wildcards
• Select the Everything filter and clear the existing query
• Test wildcards:report*.txt on a local sample file
• Remember that * matches zero or more characters
• Remember that ? matches exactly one character
• Try *report* when whole-filename wildcard matching is enabled
• Remove an unintended nowildcards: modifier
• Test *report* and ext:txt separately before combining them
• Check active filters, exclusions, and result omissions
• Verify the target volume, folder, or share is indexed
• Check whether new files enter the index automatically
• Verify service, account, mapped-drive, and portable-profile context
• Use Force Rebuild only when exact-name indexing is demonstrably broken
• Stop changing settings as soon as the controlled test succeeds

8. Frequently Asked Questions

8.1 Why does an asterisk return no results?

Wildcard processing may be disabled, a filter may be active, or whole-filename matching may require a leading asterisk. Try wildcards:*report* with the Everything filter selected. If an exact filename also fails, inspect the index rather than the wildcard setting.

8.2 Why does the question mark miss a filename I expected?

A question mark matches exactly one character, not zero or more. The pattern report?.txt can match report1.txt, but it does not match report.txt or report12.txt. Use * when the number of characters can vary.

8.3 Does ext: support wildcard searches?

The ext: function can be combined with a separate wildcard condition. For example, wildcards:*invoice* ext:pdf searches for indexed PDF files with “invoice” in the filename. Test each condition independently if the combined query returns nothing.

8.4 Why do wildcard searches work locally but not on my NAS?

The NAS content may not be indexed, the share may be offline, or the Everything process may run under an account that cannot access the share. Verify an exact filename first, then confirm folder indexing, UNC access, credentials, and update behavior.

8.5 Should I delete the Everything database?

No, not as an early troubleshooting step. First test an exact filename, reset filters, inspect exclusions, verify indexed locations, and check service or folder-index status. Use the built-in Force Rebuild option only when evidence indicates that the index itself is stale or incomplete.

8.6 Is Everything the same as Windows Search?

No. Everything is a separate filename search application with its own indexes, services, filters, syntax, and settings. Changing Windows Search indexing locations generally does not change Everything’s results. Troubleshoot the configuration inside Everything and the Windows access needed for the relevant files.