Windows Search Index Forensics: The Complete Guide
What the Windows Search index records, where Windows.edb and Windows.db live, what survives file deletion, and how to analyse both formats in a DFIR case.
TL;DR. Windows Search keeps a database of every item it indexes: full path, size, owner, MAC timestamps, the time it was indexed and, for text-like documents, a chunk of the content. On Windows 10 and earlier that database is Windows.edb (ESE). On Windows 11 it is Windows.db plus Windows-gather.db (SQLite, with write-ahead logs). Both live in C:\ProgramData\Microsoft\Search\Data\Applications\Windows\. The index is not purged in real time, so it regularly holds the path, metadata and text of files that were deleted from disk. It is one of the few artefacts that can give you content of a deleted file without carving. Treat it as proof that a file existed and was seen by the indexer, not as proof that someone opened it.
I have seen this artefact ignored in more reports than I can count, usually because the analyst's suite did not parse it or because Windows.edb sounded like an Exchange mailbox. That is a shame: on a typical workstation it is a structured, timestamped inventory of the user's documents, the Start menu and, depending on the Windows version, browser history and activity records.
What the Windows Search index is
The Windows Search service (WSearch, process SearchIndexer.exe) crawls configured locations, runs property handlers and filters over each file, and stores the result so that the Start menu and File Explorer can answer queries instantly. Microsoft's Windows Search performance guide puts a typical user's machine under 30,000 indexed items and states a practical ceiling of about one million.
One index serves the whole machine. Items from every user profile that falls inside an indexed location end up in the same database, which is why the owner property (System.FileOwner) matters.
What gets indexed depends on the configuration:
| Setting | Effect on the evidence |
|---|---|
| Classic mode | Microsoft describes it as indexing Documents, Pictures, Music and the desktop. In practice the Indexing Options list usually contains the Users folder and the Start menu. |
| Enhanced mode | The whole PC, including user folders outside the profile. More coverage, bigger index. |
| Added locations | Any folder, drive or share an administrator or user added. Removable drives show up with their own drive letter. |
| "Properties only" vs "properties and contents" per file type | Decides whether you get a content snippet for that extension. |
Always check what was indexed on your machine before you argue from absence. The gather tables (see below) list the crawl scopes, and the tool shows the folder tree it rebuilt from them.
Where the databases live
| Windows version | Files in C:\ProgramData\Microsoft\Search\Data\Applications\Windows\ | Format |
|---|---|---|
| Windows Vista to Windows 10 | Windows.edb, MSS*.log, MSS.chk, *.jrs, tmp.edb | ESE (JET Blue) with transaction logs |
| Windows 11 | Windows.db + Windows.db-wal, Windows-gather.db + -wal, Windows-usn.db and others | SQLite in WAL mode |
Microsoft's own troubleshooting article names Windows.edb for Windows 10 and Windows.db for Windows 11 in that same folder. Sources disagree on the exact Windows 11 release that made the switch, so the rule I use is simple: look at the folder. The full acquisition procedure, including locked files and shadow copies, is in where Windows.edb and Windows.db are stored and how to collect them.
How the data is organised
Both formats keep two kinds of records.
The property store holds one logical record per indexed item, keyed by a WorkId. On Windows 10 it is SystemIndex_PropertyStore, a wide ESE table with hundreds of columns named like 4447-System_ItemPathDisplay. On Windows 11 it is SystemIndex_1_PropertyStore, a narrow SQLite table with one row per (WorkId, ColumnId, Value), and SystemIndex_1_PropertyStore_Metadata maps each ColumnId to a property name. The format comparison covers both layouts.
The gather tables (SystemIndex_Gthr and SystemIndex_GthrPth) are the crawler's bookkeeping: which documents it knows about, under which scope (folder), with which last-modified value. On Windows 11 they sit in Windows-gather.db. The DocumentID in the gather table matches the WorkId in the property store.
That split is useful. An item still in the property store but missing from the gather table is a candidate for "deleted since it was indexed". The Windows Search Index Parser flags exactly that.
What you can get out of it
| Evidence | Property or table | Why it matters |
|---|---|---|
| Full path of a file or folder | System.ItemPathDisplay | Existence of a file at a location, including files long gone |
| Size, owner, computer name | System.Size, System.FileOwner, System.ComputerName | Attribution and identification |
| Created / modified / accessed | System.DateCreated, System.DateModified, System.DateAccessed | File system times as seen at indexing time |
| When the indexer processed it | System.Search.GatherTime | An independent timestamp that attackers rarely think about |
| Text content | System.Search.AutoSummary | Part of a document, script or note, even after deletion |
Browser history (IE / legacy Edge; Windows 11 System.Link.TargetUrl) | URL properties | Web activity when browser databases are gone |
| Activity history items | System.ItemType = ActivityHistoryItem | Application and file usage attributed to a user SID |
The URL and ActivityHistory points come from Stroz Friedberg's 2023 research, published by Phalgun Kulkarni and Julia Paluch as Windows Search Index: The Forensic Artifact You've Been Searching For. It is the best public write-up of what the Windows 11 layout contains. Each property is explained in detail in Windows Search index properties explained.
The deleted-file angle
The reason this artefact belongs in every Windows triage is that the index lags behind the disk. When a file is deleted, the indexer is notified and eventually removes the record, but "eventually" can be a long time on a busy or powered-off machine. On Windows 11 the removal first lands in the write-ahead log. Chivers and Hargreaves already showed in 2011 (Forensic data recovery from the Windows Search Database, Digital Investigation) that records of unavailable files persist and that deleted records can be carved from unused database space.
In practice you will find three situations, covered in what the index keeps about deleted files:
- The record is still live in the property store. Any parser shows it.
- The record is gone from the checkpointed database but still in the WAL (Windows 11), or the other way round.
- The record was deleted from the database and only survives in free pages. That needs carving.
A workflow that holds up
- Collect the whole folder, not just the main database: WAL files, gather database, ESE logs. Use KAPE's
WindowsIndexSearchtarget, Velociraptor or a disk image. - Check the state. For ESE, a dirty shutdown means recent changes are still in the logs. See fixing a dirty Windows.edb with esentutl. For SQLite, keep
Windows.dbandWindows.db-waltogether. - Parse and pivot. Open the folder in the browser-based parser (the step-by-step how-to) or in the tool of your choice. Export to CSV for your timeline.
- Filter on what matters: user-writable paths, executables, archives, other drive letters, network paths, content snippets, items missing from the gather table.
- Corroborate. A path in the index is a lead. Tie it to LNK files, Jump Lists, the USN journal, Recycle Bin records or Amcache before you write "the user opened".
A fully worked (fictional) case is in investigating an intrusion with the Windows Search index.
Limits you must state in the report
- Scope. Only indexed locations are covered. Excluded folders, unindexed drives and file types set to "properties only" leave gaps.
- Configuration can be changed. The service can be disabled and the index rebuilt or deleted. See anti-forensics against the index.
- Timestamps are copies. The MAC times are what the file system reported at indexing time; later changes are only visible if the item was re-indexed.
- Undocumented schema. Microsoft documents the properties, not the database layout. Everything about table structure comes from public research and reverse engineering.
- Tool maturity. Parsers disagree on edge cases. Cross-check key findings with a second tool; the parser comparison lists the options. For the Windows Search Index Parser specifically: its ESE (Windows.edb) reader has been validated on synthetic databases only so far, its Windows 11 decoding follows published research because Microsoft does not document the schema, and it does not yet carve deleted records from free pages.
FAQ
Is the Windows Search index enabled by default?
Yes. The Windows Search service (WSearch) is configured to start automatically on client editions of Windows, and it indexes the default locations unless someone has disabled the service or excluded folders.
Does the index prove that a user opened a file?
No. It proves that the indexer saw the file at a given path with given metadata. Opening and execution need other artefacts such as LNK files, Jump Lists, Prefetch or the ActivityHistory items the index itself can hold.
Can I trust the timestamps?
The created, modified and accessed times are copies of the file system values at the time the item was indexed. The gather time is the indexer's own clock. Both are FILETIMEs in UTC.
See also the definition of FILETIME.
Further reading
- Microsoft Learn: Troubleshoot Windows Search performance.
- Kulkarni and Paluch (Stroz Friedberg): Windows Search Index research and SIDR.
- Kaspersky Securelist: forensic artefacts in Windows 11.
- Chivers and Hargreaves (2011): Forensic data recovery from the Windows Search Database.