Windows Search finds nothing, or eats the disk: the index, its database, and the rebuild you should almost never do blindly

A user tells you search is broken. They type a filename they can see in File Explorer, and the Start menu returns nothing. Or the opposite: the disk light never goes out, SearchIndexer.exe is at the top of Task Manager, and a laptop that used to last a day now lasts four hours. Both tickets get the same reflex answer from most helpdesks: rebuild the index. That reflex is wrong far more often than it is right, and it is expensive when it is wrong. This post explains what the Windows Search index actually is, where it lives on disk, what decides whether a folder is even eligible to be searched, and the order in which you should check things so that a rebuild is the last thing you do rather than the first.

The problem: two very different tickets, one wrong answer

Windows Search failures arrive in two shapes, and they have almost nothing in common.

The first shape is a silent miss. The file exists. The user can open it. Search does not return it. This is almost never database damage. It is nearly always that the folder holding the file is not in the index at all, so there is nothing to return.

The second shape is resource consumption. The indexer is reading and writing constantly, the database has grown to several gigabytes, and the machine feels slow. This is a capacity and scope problem: too much content is in scope, or the content in scope is enormous.

The reflex fix for both is the Rebuild button in Indexing Options. Microsoft's own performance guidance tells you what that costs: "Let the Indexer run for up to 24 hours to rebuild the index database." During that window search results are incomplete by design. On a laptop that sleeps and runs on battery, the real elapsed time is longer, because the indexer throttles itself when the device is busy or unplugged.

Why it happens: a service, a crawler, a scope list and a database

Before you can triage this you need to know what the moving parts are. There are four, and they fail in different ways.

The chain, from trigger to result

Here is the order of operations. Each arrow is a real process boundary.

1. The Windows Search service (short name WSearch) starts and hosts SearchIndexer.exe. Nothing else happens until this service is running.
2. The gatherer inside the indexer reads the crawl scope: the list of locations that are in and out of scope. It gets that list from the registry, from user choices in Indexing Options, and from Group Policy.
3. For each location, a protocol handler is loaded to enumerate items. Handlers run out of process in SearchProtocolHost.exe so a bad handler cannot take the indexer down with it.
4. For each item, a filter handler is loaded to extract text and properties. A filter handler is an implementation of the IFilter COM interface. These run in SearchFilterHost.exe, again out of process, for the same reason.
5. The extracted properties and text are written into the catalog database on disk.
6. A query from Start, File Explorer or an application goes through tquery.dll and the Search OLE DB provider into that same database.

Notice what that chain means for triage. A missing result can be caused at step 2 (not in scope), step 3 (location unreachable), step 4 (no filter for that file type, so no content was extracted) or step 5 (damaged data). Only the last of those is fixed by a rebuild.

Where the database lives, and what it is called

This is the single most common factual error in older guidance. Microsoft's troubleshooting article is explicit that the file name changed with Windows 11.

The first is Windows 11. The second is Windows 10. Both live in the same folder. Microsoft also tells you to read its size using the Size on disk property rather than Size, because the indexer uses sparse and compressed files and the plain Size value can be wildly misleading.

Alongside the main catalog you will see companion files created by the same engine. On a Windows 11 24H2 device the folder held Windows.db, Windows-gather.db and Windows-usn.db, each with -wal and -shm sidecars. The gather database tracks crawl state. The USN database tracks the NTFS change journal position, which is how the indexer knows what changed without re-walking the disk. Those file names are observed on a live device and are not documented by Microsoft. Do not build detection logic on them, because an undocumented internal file layout can change in any update.

The crawl scope: the thing that actually decides what is searchable

Scope is where most of your tickets live. There are three sources of scope rules, and they have a documented order of precedence.

Microsoft's Group Policy documentation for Windows Search states the precedence explicitly, from strongest to weakest: prevention policies, then user excludes, then user includes, then default excludes, then default includes. Read that once more, because it is the whole game. A prevention policy beats everything. If policy prevents a path, the user cannot re-add it in Indexing Options, and the option to do so is blocked in the interface.

On disk, the scope lives under the crawl scope manager. Here is what a Registry Editor session looks like on a healthy device.

Read it like this. DefaultRules holds the rules Windows ships with, which is why your temp folders and C:\Windows are never in the index. WorkingSetRules holds the live effective set. Include set to 0 means exclude; 1 means include. Policy set to 1 means the rule came from Group Policy and the user cannot override it. That single DWORD is often the answer to the whole ticket.

Registry reference for the whole feature area

Everything below shares one parent key.

Policy values land in a separate tree. This is the one you check when a user swears they never excluded anything.

Microsoft's Search Policy CSP documentation names that exact key as the registry target for the machine policies, and the archived Windows Search Group Policy article confirms the matching user hive at HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Windows Search. Windows only creates the subkey when a policy is actually applied, so an absent key means no policy, not a read failure.

System files and DLLs in the flow

All of these live in C:\Windows\System32 and were confirmed present on a Windows 11 24H2 device. Where the table quotes a file description in italics, that string was read from the binary's own version resource, not inferred. Microsoft does not publish a component map for this feature area, so treat the internal role of each library as informed reading rather than documented fact.

The filter handler model is worth a moment because it explains a whole class of "the file is indexed but searching its contents finds nothing". A filter handler is registered per file extension through a persistent handler in the class registry. You can read the registration directly.

Microsoft publishes the GUIDs for its own shipped filters in that policy article, which makes them a useful known-good baseline: Plain Text is {c1243ca0-bf96-11cd-b579-08002b30bfeb}, HTML is {e0ca5340-4534-11cf-b952-00aa0051fe20}, XLSX is {4887767F-7ADC-4983-B576-88FB643D6F79}. If a persistent handler for a common Office extension has been replaced by a third-party GUID, you have found your content-extraction problem.

Event log: the channel is not where you expect

Your prompt, and a great deal of community guidance, will tell you to open Microsoft-Windows-Search/Operational. That channel does not exist. Enumerating the registered providers on a Windows 11 device gives this mapping.

Microsoft does not publish a consolidated Event ID reference for Windows Search on Windows client. The nearest official page, "Event Log Messages", documents the retired Indexing Service, not this component. The IDs below were read from the provider message resource in tquery.dll on a Windows 11 24H2 device, and the ones marked as observed were also seen as real records in the Application log on that device. Treat them as a triage aid, not a contract.

Log files

The gatherer writes a crawl trail. The location is read from the registry rather than hard-coded.

Inside GatherLogs\SystemIndex you get a numbered series of SystemIndex.N.Crwl files, one per crawl. They are binary-ish but readable enough with Select-String. A healthy crawl log is small, often only a couple of bytes, because nothing failed. A file that is kilobytes long is recording per-item failures, and the strings inside name the paths that failed. That is your list of unreachable locations.

Services, dependencies and the scheduled task

One service, one task. Both were read live from a Windows 11 device.

Roaming profiles, network locations and multi-session

Two realities catch people out here.

First, the index is local by design. Microsoft's archived "Indexer data location" policy documentation states plainly that the directory "must be location on a local fixed drive". You cannot point the catalog at a network share or a redirected profile path. If your profile solution redirects %ProgramData%, indexing will not work.

Second, on multi-session Windows and modern Windows Server, Windows Search now roams per user by itself. Microsoft's FSLogix documentation says the FSLogix search roaming feature "is no longer necessary in newer versions of Windows", specifically Windows Server 2019 version 1809 and later plus Windows 10 and 11 multi-session, and that FSLogix detects native per-user search and disables its own roaming automatically. The recommendation there is to disable FSLogix search roaming and instead enable the Windows Search service so per-user catalogs are created inside the user's container. The registry value that turns on Windows per-user catalogs, named in that same article, is EnablePerUserCatalog under the Windows Search key.

Defender and antivirus: what is actually documented

There is a widespread belief that you should add antivirus exclusions for the index database. Check that claim before you act on it. Microsoft's enterprise virus-scanning recommendation article, KB822158, lists exclusions for Windows Update, security databases, Group Policy, user profiles, Active Directory, DFSR, DHCP, DNS, WINS and Hyper-V. Windows Search and the index database are not in it. Defender's own guidance states that "Adding antivirus exclusions should always be the last resort if no other option is feasible."

What Microsoft does document about antivirus and Search is different and more useful. The performance troubleshooting article warns that "Some anti-virus programs and 'Optimize your PC' applications disable the Windows Search service" and tells you to check the service state after running them. That is the real-world antivirus interaction: not scanning overhead, but a third-party product stopping WSearch outright and leaving your users with no search at all.

How to verify: the ordered diagnostic path

Work these in order. Each step is cheap, read-only, and rules out a whole class of cause. Do not skip to the end.

Step 1: is the service even running?

This costs five seconds and closes a surprising number of tickets. The command below reads the service state and the authoritative start mode from the service control database.

Step 2: is the location the user is searching actually in scope?

This is the step almost everybody skips, and it is the step that resolves most silent-miss tickets. There are two ways to answer it: the interface, and a direct query against the index.

The interface path is here.

Microsoft's guidance for the "Indexing complete" state says exactly this: if files are still missing, "make sure that the correct folders are selected to search", and points you at Modify to see the indexed locations. Take that literally.

The better answer is to ask the index itself. Windows Search exposes a read-only OLE DB provider, Search.CollatorDSO, that you can query with SQL from PowerShell without installing anything. This is the single most useful diagnostic in this whole post.

Step 3: is policy excluding it?

If the path is out of scope, find out who put it out of scope. Read the policy key and look for scope rules stamped as policy-sourced.

Step 4: what does the event log actually say?

Now, and only now, go to the Application log. You are looking for one thing: does the log say the data is damaged, or does it say something else?

Read that panel the way a triage engineer should. The 7042 with "Recovery phase failed" is a genuine data problem. The 10024 is not: it is a filter handler hanging, and a rebuild will just hang on the same file type again. Two entries, two completely different fixes, in the same log.

Step 5: size, and whether size is even the issue

Microsoft gives you real numbers here. On a typical user's machine the indexer holds fewer than 30,000 items; a power user might reach 300,000; past 400,000 you may start to see performance problems; and the hard ceiling is about 1 million items, beyond which "it may fail or cause resource problems". The index is generally about 10 percent of the size of the indexed content. Check the live count in Settings under Searching Windows, next to Indexed.

Step 6: run the companion script

The script for this post, Get-SearchIndexHealth.ps1, does every read above in one pass and prints a verdict of REBUILD-INDICATED, SCOPE-OR-POLICY, SERVICE-PROBLEM, CAPACITY or HEALTHY. It is strictly read-only. It never rebuilds, resets, stops the service or deletes the database, and it exits 1 if any read failed rather than showing you a clean report built on missing data. It needs no modules.

The fix: scope, policy, capacity, and rebuild last

Fixing scope with Group Policy

The Windows Search settings live in one place in the policy editor. Here is the full click path.

To change which paths are excluded:

1. Open the Group Policy Management Console and edit the GPO that targets your devices.
2. Expand Computer Configuration, then Policies, then Administrative Templates.
3. Expand Windows Components and select Search.
4. Open Prevent indexing certain paths. This is the forced exclusion that users cannot override.
5. If it is Enabled, read the path list. The format is a URL, for example file:///C:\* for a local path or otfs://{*}/server/path/* for a network share. The asterisk means "everything below", not a wildcard for string matching.
6. Remove any path that covers a location your users legitimately need to search, or set the policy to Not Configured if it was applied by mistake.
7. If you need to guarantee a path is indexed instead, use Default indexed paths, which sets a default the user may still override.
8. Close the editor and run gpupdate /target:computer /force on a test device.

Two more settings in the same node matter for scope and are worth knowing by name: Prevent indexing of certain file types, which takes a semicolon-delimited extension list, and Allow indexing of encrypted files. Microsoft warns explicitly about the second one: "When this setting is enabled or disabled, the index is rebuilt completely." Toggling it fleet-wide triggers exactly the multi-hour rebuild this post is telling you to avoid, on every targeted device at once.

Fixing scope with Intune

Here is the honest state of play, and it is not symmetrical with Group Policy.

1. Sign in to the Microsoft Intune admin center with at least the Policy and Profile Manager role.
2. Select Devices, then Manage devices, then Configuration, then Create, then New policy.
3. Set Platform to Windows 10 and later and Profile type to Settings catalog. Select Create.
4. Name the profile something you will recognise later, for example Win11: Windows Search indexing. Select Next.
5. On Configuration settings choose Add settings, then in the settings picker search for Search and select the Search category.
6. Pick the settings you need. Close the picker, set each value, and select Next.
7. Assign scope tags if you use them, assign the profile to a device group, review, and select Create.

These are the Search settings the Policy CSP actually exposes, with the Group Policy name each one maps to. All of them write to SOFTWARE\Policies\Microsoft\Windows\Windows Search and come from Search.admx.

Moving the index to another volume

This is the correct fix when the index is large but legitimate and the system volume is tight. There is both an interface path and a policy.

1. Open Settings, then Privacy & security, then Searching Windows.
2. Select Advanced indexing options to open the Indexing Options dialog.
3. Select Advanced. You will be prompted for administrative consent.
4. Under Index location, note the current location, then select Select new and pick a folder on a local fixed drive.
5. Confirm. The service restarts and moves the catalog files. Watch for event 1017 on success or 1016 on failure.
6. To enforce it centrally instead, use the Group Policy setting Indexer data location in the same Search node. The archived policy documentation states the directory "must be location on a local fixed drive".

Event 1016 has a documented cause worth memorising: the move fails "because the target directory is not empty, or because the SYSTEM account doesn't have write access to the target directory". Both are trivially checkable before you start.

Reclaiming space without a rebuild, on Windows 10

Microsoft publishes an offline defragmentation procedure that reclaims empty space inside the database instead of rebuilding it. It is worth knowing, and it is worth knowing its limit.

When a rebuild is genuinely the right call

Rebuild when the log says the data is damaged. That means events 4138, 7040, 3602 or 7042 with a recovery failure context, or the documented state where the Searching Windows page is entirely greyed out with no status message, which Microsoft describes as corrupted indexer registry keys or database.

The documented rebuild path is the Rebuild button, reached here:

Before you press it, do three things. Reduce the scope first, so you rebuild less; a rebuild of the same oversized scope produces the same oversized index. Plug the device in and leave it on, because the indexer throttles on battery and when the user is active. Set the expectation with the user in hours, not minutes: Microsoft's own number is up to 24 hours.

If search is broken in ways that go beyond the index, Microsoft also documents a supported reset path that is gentler than a manual rebuild: the Search and Indexing troubleshooter, invoked as msdt.exe -ep WindowsHelp id SearchDiagnostic, and a downloadable ResetWindowsSearchBox.ps1 script. The reset article notes that resetting "doesn't affect your files. However, it may temporarily affect the relevance of search results."

Proof it worked: a real run on a real device

The output below is a genuine run of Get-SearchIndexHealth.ps1 on a Windows 11 24H2 device, elevated, with a 30-day event window. The host name has been redacted and nothing else has been altered.

Notice how much of the report is negative evidence, and how valuable that is. There are no policy-sourced scope rules, so no Group Policy is hiding anyone's folders. There is 414 GB free, so this is not the documented low-disk stop. The database carries NotContentIndexed and not Compressed, so it is neither indexing itself nor paying compression overhead. Every one of those checks is a cause you have now ruled out before touching anything.

The same device also answered a direct read-only query against the catalog, which is the proof that the index is serving requests rather than merely existing on disk.

One more piece of proof, and it is the one that most often ends the argument. Earlier, a Windows 10 era check for Windows.edb on this machine returned nothing at all, because the file genuinely does not exist. The catalog is Windows.db, 3.35 GB, last written minutes before the run. If your monitoring is still looking for the old name, it is reporting healthy Windows 11 devices as having no index, and it is reporting broken ones the same way.

References

• Troubleshoot Windows Search performance — Microsoft Learn. The catalog path, Windows.db versus Windows.edb, the 30,000 / 300,000 / 400,000 / 1,000,000 item figures, the 24-hour rebuild statement, the Size on disk guidance, and the full indexing status message table.
• Fix problems in Windows Search — Microsoft Learn. The Search and Indexing troubleshooter command line, the documented reset path and ResetWindowsSearchBox.ps1.
• Windows.edb becomes larger than expected — Microsoft Learn. Why the database grows, and the offline EsentUtl.exe /d defragmentation procedure for Windows 10 and earlier.
• Search Policy CSP — Microsoft Learn. Every OMA-URI, its Group Policy mapping, the SOFTWARE\Policies\Microsoft\Windows\Windows Search registry target and Search.admx.
• Group Policy for Windows Search — Microsoft Learn (archived). The scope precedence order, the path URL formats, Indexer data location, and the shipped IFilter GUID list.
• Understanding Filter Handlers in Windows Search — Microsoft Learn. What an IFilter is and what it extracts.
• Registering filter handlers — Microsoft Learn. The persistent handler registry layout and the IID_IFilter GUID.
• Configure Windows Search database roaming — Microsoft Learn. Native per-user catalogs, EnablePerUserCatalog, and why FSLogix search roaming is no longer needed on modern Windows.
• Create a policy using settings catalog in Microsoft Intune — Microsoft Learn. The admin center navigation used above.
• Virus scanning recommendations for enterprise computers (KB822158) — Microsoft Support. Checked directly: it contains no Windows Search index exclusion, and states that exclusions should be a last resort.
• Exclusions in Microsoft Defender Antivirus — Microsoft Learn. The general position on adding exclusions.

No community or MVP deep-dive on this specific topic verified as both reachable and genuinely on-subject at the time of writing, so no community reference table is included here. Everything above is either a Microsoft-official citation or explicitly labelled as read from a live device.