Where Is Windows.edb Stored? Location and Acquisition

TL;DR. The Windows Search index lives in C:\ProgramData\Microsoft\Search\Data\Applications\Windows\. Windows 10 and earlier: Windows.edb (ESE) plus MSS*.log, MSS.chk and *.jrs. Windows 11: Windows.db and Windows-gather.db (SQLite), each with a -wal file. Collect the whole folder. The files are locked by the WSearch service on a live system, so use a raw copy tool, a shadow copy or esentutl /y /vss. Never copy the SQLite database without its -wal, and expect a live-copied Windows.edb to be in dirty-shutdown state.

The folder

C:\ProgramData\Microsoft\Search\Data\Applications\Windows\

ProgramData is hidden by default, and %ProgramData% (or the older %AllUsersProfile%) resolves to it. Microsoft's Windows Search troubleshooting article places Windows.edb (Windows 10) and Windows.db (Windows 11) in that folder. The index location can be moved in Indexing Options (Advanced, "Index location"), so if the folder is empty on a machine where search clearly worked, check that setting in the SOFTWARE hive with a registry parser before concluding anything.

What is in it on Windows 10 and earlier

What is in it on Windows 11

Kaspersky's Windows 11 artefacts write-up lists Windows-gather.db, Windows.db and Windows-usn.db in this folder.

Why the files are locked

The Windows Search service (WSearch, running SearchIndexer.exe) keeps the databases open. ESE opens its files exclusively. As an archived Microsoft ESE blog post shows, touching an in-use database fails with JET_errFileAccessDenied (-1032). SQLite files are also held open. A copy through Explorer or copy either fails or, for some tools, produces a file of zeros. The parser flags a file that starts with zeros for that reason.

Four ways to collect

1. Dead box or mounted image

Mount the image read-only, copy the folder. Nothing is locked, nothing is changing. This is the preferred path whenever you have a full disk image anyway.

2. KAPE or Velociraptor on a live system

KAPE's WindowsIndexSearch target collects C:\ProgramData\Microsoft\Search\Data\Applications\Windows\ (plus GatherLogs) through raw NTFS access. It also grabs per-user folders under AppData\Roaming\Microsoft\Search\Data\Applications\S-1*\ when they exist.

kape.exe --tsource C: --target WindowsIndexSearch --tdest D:\case\kape

Velociraptor can collect the same folder with its NTFS accessor. SIDR's authors also ship a Velociraptor artifact that runs their parser on the endpoint.

3. esentutl with a shadow copy (ESE only)

Windows ships esentutl.exe. Since Windows 10 it can read an in-use database through a Volume Shadow Copy:

esentutl /y C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb /vss /d D:\case\Windows.edb

The resulting copy is a snapshot of an open database, so it is normally in dirty-shutdown state. The same blog post describes /vssrec to replay the logs inside the snapshot. It also warns that transactions not committed at the moment of the snapshot are rolled back. For evidence I prefer to copy raw and replay later on a working copy, as described in the dirty-shutdown guide.

4. Stop the service (only if you may change the system)

On a machine you are allowed to modify (lab, reimaged soon anyway):

net stop wsearch
robocopy "C:\ProgramData\Microsoft\Search\Data\Applications\Windows" D:\case\search /E /COPY:DAT
net start wsearch

Stopping WSearch closes the databases cleanly, so Windows.edb ends in clean-shutdown state and the SQLite WAL is usually checkpointed. That is convenient, but you have changed the evidence: the checkpoint folds the WAL into Windows.db and resets it, and whatever the old WAL frames held may be lost. Document it, or avoid it.

Windows 11: keep the WAL with its database

Windows.db-wal holds committed transactions that are not yet written back into Windows.db. SQLite's WAL documentation is explicit: readers look for the newest copy of each page in the WAL first. Without the WAL you are looking at an older state of the index, often missing exactly the most recent activity. With a WAL copied at a different moment from its database, you get inconsistent pages. Copy both in one operation. The parser checks that the WAL matches the database and ignores a mismatched one with a warning. The details are in Windows.db forensics: SQLite and the WAL.

Windows 10: expect a dirty shutdown

A Windows.edb copied from a running system is almost always marked dirty shutdown: the database header says it was not closed cleanly, and some changes live only in the MSS*.log files. You can still read it. The Windows Search Index Parser parses it and says so. For a consistent view, replay the logs on a copy with esentutl /r MSS. Step by step in fixing a dirty Windows.edb.

Hash, then work on copies

• Hash the collected folder before you touch anything.
• Run esentutl recovery, sqlite3 or any tool that might write (SQLite checkpoints on close!) only on a working copy.
• Opening Windows.db in a normal SQLite client on the original can checkpoint the WAL into it. Read-only in-browser parsing does not write back, but a copy costs nothing.

Then parse it

Drop the folder, or the KAPE / Velociraptor ZIP as-is, on the Windows Search Index Parser. It pairs Windows.db with its -wal and Windows-gather.db, recognises the ESE logs and explains why they are not parsed, and runs locally in the browser. The how-to walks through the output.

FAQ

Can I just copy Windows.edb while Windows is running?

No. The Windows Search service holds the files open and a plain copy fails. Use a raw NTFS copy tool, a Volume Shadow Copy, esentutl /y /vss, or stop the service on a machine you are allowed to change.

Is it safe to delete Windows.edb?

On your own machine, deleting it (with the service stopped) forces a rebuild. On a machine under investigation, never: you destroy the evidence and the rebuild overwrites free space.

Related articles

• Windows Search index forensics: the complete guide
• Windows.edb vs Windows.db: what changed in Windows 11
• Fixing a dirty-shutdown Windows.edb with esentutl