Windows Search Index Forensics: Windows.edb and Windows.db

This guide shows you how to collect and parse the Windows Search index, and how to turn it into evidence: proof that a file existed at a given path, the text it contained, the e-mails a user had, and traces of items that were deleted since. You will also learn where its limits are, so you do not confuse background indexing with user activity.

What the indexer is

The Windows Search service (WSearch, running SearchIndexer.exe) crawls configured locations and stores, for each item, a set of properties: path, name, size, type, owner, dates and, for many formats, a slice of the text content. Explorer, the Start menu and Outlook query this index to return instant results.

For an investigator it is a system-maintained catalogue of the user's files, independent from the file system itself. When the MFT entry is reused and the USN journal has rolled over, the index may still describe a file, and sometimes what was in it. The Windows Search index cheat sheet lists the key fields; this guide is about using them.

Formats and locations

The switch to SQLite is tied to Windows 11, but the exact build and whether an upgraded system converts its index vary; treat the files on disk as the ground truth. On Windows Server the Search service is not enabled by default, so an empty folder there is normal.

Two registry locations are worth recording before you parse:

• HKLM\SOFTWARE\Microsoft\Windows Search, where DataDirectory can relocate the index to another path.
• HKLM\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager\Windows\SystemIndex\ (DefaultRules and WorkingSetRules), which defines what was indexed.

By default ("Classic" mode) the index covers the user profile folders, libraries and Start menu. "Enhanced" mode, set in Settings, covers the whole PC. The scope decides what you can expect to find: a tool dropped in C:\PerfLogs will not be indexed in Classic mode.

What it records

In Windows.edb the properties sit in the main property table (SystemIndex_PropertyStore on Windows 10, SystemIndex_0A on older versions), with column names prefixed by a numeric ID such as 4447-System_ItemPathDisplay. In the Windows 11 SQLite layout, SystemIndex_1_PropertyStore holds rows of WorkId, ColumnId and Value, and a metadata table maps ColumnId to property names. The gather tables (SystemIndex_Gthr, SystemIndex_GthrPth) record crawled items and their parent folders; in the SQLite layout they live in Windows-gather.db.

E-mail

When Outlook uses Windows Search, messages and attachments from the mailbox are indexed with sender, recipients, subject, dates and a body extract. Their paths use a mapi:// or mapi16:// scheme with the profile SID. That can surface mail that was deleted from the mailbox, or give you message content when the OST or PST is encrypted, missing or corrupt.

Browsing

Older systems index Internet Explorer and legacy Edge history. On Windows 11, some URL and activity records appear as well. Treat this as a supplement to browser forensics, not a substitute.

Collection

The database is locked by SearchIndexer.exe. Copy it through a shadow copy and take the logs with it:

set SRC=C:\ProgramData\Microsoft\Search\Data\Applications\Windows
mkdir E:\case\search
esentutl.exe /y "%SRC%\Windows.edb" /vss /d E:\case\search\Windows.edb
robocopy "%SRC%" E:\case\search MSS*.log MSS.chk /COPY:DAT
robocopy "%SRC%\GatherLogs" E:\case\search\GatherLogs /E /COPY:DAT

On Windows 11, copy the SQLite databases together with their -wal and -shm files from a shadow copy or image, so the WAL stays consistent with its database. KAPE's WindowsIndexSearch target and the Velociraptor triage target of the same name collect the system index, per-user indexes and gather logs (acquisition and triage).

Windows.edb is often large, several gigabytes on a busy workstation. Budget for it in triage collections rather than dropping it.

Replaying ESE logs

A live copy is usually in dirty state. On a working copy:

cd /d E:\case\search
esentutl.exe /mh Windows.edb | findstr /i "State"
esentutl.exe /r MSS /i

MSS is the log base name of the search database. Keep the unreplayed copy too: some tools recover more deleted records from the original pages and logs than from a cleanly recovered database.

Parsing tools

:: SIDR: point it at the folder holding the collected database(s)
sidr.exe -f csv -o E:\out\search E:\case\search

:: libesedb: dump all ESE tables to text files
esedbexport -t E:\out\search\export E:\case\search\Windows.edb

Check sidr --help for the options of your build. For manual work on Windows 11, query the property store and pivot on WorkId to assemble each item's properties.

Gather logs

The GatherLogs\SystemIndex folder holds text logs written during crawls, typically SystemIndex.<n>.Crwl and SystemIndex.<n>.gthr files. They list URLs of items the gatherer processed or failed to process, with status codes and times. They rotate quickly, but when present they can show that a file path existed at crawl time, including on paths the user later cleaned. Parse them with a text editor or a simple script; their format is undocumented and tools rarely handle them.

Cross-linking with Explorer search history

The index stores items, not queries. What the user typed into the Explorer search box lives in WordWheelQuery, under NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery, as UTF-16 strings in MRU order. Searches from the taskbar or Start menu are not stored there.

Put the two together: a WordWheelQuery term salaries plus index entries for \\fs01\hr$\salaries_2026.xlsx and a local copy in Downloads builds a strong narrative of search, discovery and copy. Confirm the opening with LNK files and Jump Lists, as described in the ShellBags, LNK and Jump Lists guide.

Investigative scenarios

Insider theft: what did the user have?

Filter the property store on the user's profile path and on file types of interest (.xlsx, .pdf, .zip, .7z). The index often lists documents that are no longer on disk, with size, dates and an AutoSummary extract. Compare with the current MFT listing to produce a list of "files that existed and are gone".

Ransomware and intrusion: tools and notes

Search for tool names, script extensions (.ps1, .bat, .vbs) and ransom note file names. An indexed C:\Users\admin\Desktop\run.ps1 with an AutoSummary containing the script body can recover a deleted attacker script. Gather time tells you the file existed at least at that moment.

Deleted files and rebuilds

Records of deleted items can survive in ESE free pages and MSS*.log files, or in the SQLite -wal and freelist; WinSearchDBAnalyzer and carving tools recover them (file carving). Older states of the whole index live in volume shadow copies: comparing two copies shows what appeared and disappeared between them. A recently recreated database, or a disabled WSearch service, on a system that normally indexes, is an anti-forensics indicator.

Naming thumbnails

A thumbcache entry has an ID but no file name. Match System_ThumbnailCacheId in the index to the cache entry to name the picture, which is often decisive in image-related cases.

Mail without the mailbox

When the user deleted a thread or the OST is inaccessible, indexed mapi16:// items can still give sender, subject, date and body extract. Report them as index records, not as recovered messages.

Reading AutoSummary carefully

System_Search_AutoSummary is produced by the filter (IFilter) that handles each file type, so its quality depends on the format: plain text, scripts and Office documents usually give readable extracts, while PDFs depend on the installed filter and encrypted or binary files give nothing. The extract reflects the file content at the last crawl, not at deletion time. Quote it verbatim in your report, with the gather time next to it, and flag that it is a partial copy produced by the indexer. When the same path appears in several shadow copies of the index, comparing the extracts can show how a document changed over time.

Timestamps

All index dates are FILETIME values in UTC. Keep their meaning straight:

• System_Date* are copies of the file's own times at crawl time.
• System_Search_GatherTime is when the indexer processed the item.
• None of them is a user action.

Line gather times up with the USN journal to date file creation and deletion more precisely (NTFS forensics).

Pitfalls

• Indexing is not access. The service runs on its own. Never write "the user viewed" on the basis of an index record.
• Scope matters. An absent file may simply be outside the indexed locations, or excluded by type.
• Lag. Gather time can trail file changes by minutes or more, and a busy or throttled indexer can skip items.
• Dirty databases. Replaying logs changes the database; keep the original for recovery of deleted records.
• Opening SQLite originals. It can checkpoint the WAL and lose records. Work on copies.
• Size limits on content. AutoSummary is an extract, not the document, and not every format is text-indexed.
• Format assumptions. A Windows 11 host upgraded from 10, or a relocated DataDirectory, may not match what you expect.

Workflow checklist

1. Record the Windows build, the WSearch service state, DataDirectory and the crawl scope rules.
2. Collect Windows.edb with MSS* logs, or Windows*.db with -wal and -shm, plus per-user indexes and GatherLogs, from a shadow copy or image.
3. Keep an untouched copy; replay ESE logs on a second copy with esentutl /r MSS /i if needed.
4. Parse with SIDR, and browse with WinSearchDBAnalyzer or ESEDatabaseView when you need deleted records or raw tables.
5. Filter on case keywords: file names, paths, extensions, senders, tool names.
6. Compare indexed paths with the current MFT and shadow copies to list files that were deleted or moved.
7. Correlate with WordWheelQuery, LNK files, Jump Lists, thumbcache and the USN journal; write each timestamp's meaning next to it on a UTC timeline.