Windows Search Index: Evidence of Deleted Files

TL;DR. The Windows Search index does not delete a record the moment a file disappears. You can find deleted files in three places: live records still in the property store (path, size, owner, timestamps, gather time and often a content snippet), WAL differences on Windows 11 (a record present in one state of Windows.db and not the other), and free space inside the database (defunct ESE entries, SQLite freelist pages), which needs carving. A property-store item with no matching gather record is a strong "deleted?" lead. The content snippet in System.Search.AutoSummary is the prize: text of a file that no longer exists, without carving the disk.

Why deleted files linger

The indexer learns about a deletion from the file system's change tracking, queues the work and eventually removes the item. Several things delay that:

The machine was shut down, hibernated or seized right after the deletion.
The indexer was paused, busy, on battery or backing off because of user activity. Microsoft's troubleshooting guide lists these states.
The item was on a drive that is no longer connected: an unplugged USB stick or an unreachable share. Chivers and Hargreaves pointed out in their 2011 paper that records of unavailable files persist.
On Windows 11, the removal is a committed transaction in Windows.db-wal until a checkpoint writes it into Windows.db. The Stroz Friedberg write-up notes that a deleted file's record stays available in the main database until the WAL changes are written back.

None of this is guaranteed. It is a race you sometimes win.

Level 1: live records of files that no longer exist

The easiest case. The file is gone from disk, but its record is still a normal row in the property store. Any parser shows it, and you get the full set of properties:

Property	What it gives you about the deleted file
`System.ItemPathDisplay`	Full path, including the folder it was staged in
`System.Size`	Size at indexing time: compare with carved fragments or exfil volumes
`System.FileOwner`	The account that owned it
`System.DateCreated` / `DateModified` / `DateAccessed`	File system times as seen when indexed
`System.Search.GatherTime`	When the indexer processed it
`System.Search.AutoSummary`	Extract of the content

How do you know the file is deleted? The index does not say so. You compare with the file system in your image (MFT, directory listing). Or, faster, you look at the gather tables.

The gather-table cross-check

The property store and the gather tables (SystemIndex_Gthr) are two views of the same items, joined on WorkId = DocumentID. When the gatherer processes a deletion, the two do not always disappear together. The Windows Search Index Parser compares them:

Not in gather table (deleted?): the property store still has the item, the gather table no longer does. A good candidate for "deleted after it was indexed".
Gather table only: the gatherer still lists the document but its properties are gone. Common with temporary files, such as an archive extracted to a temp folder and cleaned up.

Both flags are heuristics. Confirm with the file system, the USN journal (a FILE_DELETE reason for the same name) or the Recycle Bin ($I files carry the original path and deletion time).

Level 2: the Windows 11 write-ahead log

Windows.db-wal contains committed pages that are newer than the corresponding pages in Windows.db. That gives you two states of the index:

The database alone: the state at the last checkpoint.
The database plus the WAL: the current state.

An item present in the first and absent in the second was removed by a recent transaction. An item only in the second was added recently, which is what the parser flags as only in WAL. An item whose properties differ was re-indexed recently (changed in WAL): for example a file overwritten or executed again. The SQLite and WAL deep dive explains how the frames and checkpoints work, and why the WAL can even hold several older versions of the same page.

Practical consequence: never analyse a Windows 11 index without its WAL, and never let a tool open the original in read-write mode. A normal SQLite client may checkpoint on close, merging the WAL and destroying the "before" state.

Level 3: records in free space

When the database does delete a record, the bytes are not wiped at once.

ESE: the deleted entry is flagged defunct in its page and cleaned up later. Pages that become empty return to the free space. The libesedb format documentation describes the page tags involved.
SQLite: deleted cells go to freeblocks inside the page, emptied pages go to the freelist, and older page versions can remain in WAL frames that were overwritten logically but not physically.

Recovering those needs a carver that understands the format. Chivers and Hargreaves built one (wdsCarve) for their research. WinSearchDBAnalyzer recovers deleted records from Windows.edb. The Windows Search Index Parser does not carve yet: for ESE it counts the defunct entries it sees and reports the number as a warning, so you know there is something to recover with another tool.

Content snippets: the reason to care

System.Search.AutoSummary is described by Microsoft as an automated summary of the full text of a document. In practice it is an extract of the beginning of the text. The Stroz Friedberg research reports up to the first 1,024 bytes on Windows 11 and lists the file types where they saw it: documents (.txt, .docx, .xlsx, .pdf, .one, .eml), web and config files (.html, .xml, .ini, .reg, .sql, .asp) and scripts (.bat, .cmd, .vbs, .js).

What I look for in snippets:

Credentials and notes an attacker saved on the host, then deleted.
Scripts: the first lines of a .bat or .vbs show intent even when the file is gone.
Ransom notes and their contact details.
Document titles and first lines proving that a sensitive document existed in a staging folder.

Two cautions:

The snippet reflects the content at indexing time. If the file was modified afterwards and not re-indexed, the snippet is stale. Compare System.DateModified with the gather time.
Content indexing depends on configuration. If a file type is set to "properties only" in Indexing Options, or the location is not indexed, there is no snippet. Microsoft documents both options. Absence of a snippet proves nothing.

A short example

In the fictional case that ships as the tool's sample, a file C:\ProgramData\Intel\creds.txt is deleted by the intruder. The file is gone and the gather table no longer lists it, but the property store still has its path, owner (FIN-WKS-07\svc_backup), size (214 bytes), timestamps, and a snippet containing the credentials the attacker had collected. The full walk-through is in investigating an intrusion with the Windows Search index.

Reporting it correctly

Say "the Windows Search index contains a record for path X, indexed at T". Do not write "the file existed until T".
Quote the snippet as "indexed content", with the caveat that it reflects the file at indexing time.
State whether the WAL and gather database were available and whether an ESE database was dirty.
If you relied on the tool's flags, say they are heuristics and how you confirmed them.

FAQ

How long does a deleted file stay in the Windows Search index?

There is no fixed duration. It depends on when the indexer processes the deletion, whether the machine was running, and on database housekeeping. Treat every surviving record as luck, and document when the index was collected.

Can the index give me the full content of a deleted document?

Usually not. System.Search.AutoSummary holds an extract, not the file. Stroz Friedberg's research describes up to the first 1,024 bytes on Windows 11. That is often enough for credentials, a ransom note or the first lines of a script.