Skip to content
Search IndexParser

Windows.edb / Windows.db / -wal

Windows Search Index Parser

Every file, folder and web page Windows indexed — paths, sizes, owners, timestamps and content snippets, even for files deleted since — from Windows.db (Windows 11) or Windows.edb (Windows 10). Parsed in your browser with WebAssembly — nothing is uploaded.

Drop Windows.db (+ -wal, Windows-gather.db) or Windows.edb here

Best: the whole C:\ProgramData\Microsoft\Search\Data\Applications\Windows folder. Folders and ZIP triage collections (KAPE, Velociraptor) work as-is — Windows.db is paired with its -wal and Windows-gather.db, transaction logs are recognised and explained.

Synthetic databases from a fictional intrusion — no real data. How to collect ↓

100% client-side: databases are parsed by WebAssembly in your browser and never uploaded.

How to get your data

From a live PC, a triage collection or a disk image — about two minutes.

  1. CollectCopy the Windows Search index folder (commands below).
  2. Drop it hereThe folder, the loose files or the KAPE / Velociraptor ZIP, as-is.
  3. Stays in your browser100% client-side: databases are parsed by WebAssembly in your browser and never uploaded.

Live Windows 10 or 11: open Windows PowerShell with “Run as administrator” and paste the block.

Takes one Volume Shadow Copy of C:, copies the whole index folder out of it — so Windows.db and its -wal (or Windows.edb and its logs) come from the same instant — then deletes the snapshot. No tool to install.

PowerShell (admin)
New-Item -ItemType Directory -Force C:\triage | Out-Null
$id = (Invoke-CimMethod -ClassName Win32_ShadowCopy -MethodName Create -Arguments @{Volume='C:\'; Context='ClientAccessible'}).ShadowID
$sc = Get-CimInstance Win32_ShadowCopy | Where-Object ID -eq $id
cmd /c mklink /d C:\triage\vss "$($sc.DeviceObject)\"
robocopy C:\triage\vss\ProgramData\Microsoft\Search\Data\Applications\Windows C:\triage\WindowsSearch /E /B /COPY:DT /R:0 /W:0
cmd /c rmdir C:\triage\vss
$sc | Remove-CimInstance

Then drop the C:\triage\WindowsSearch folder here.

Gotchas

  • The Windows Search service keeps the files open: a copy with Explorer or copy fails or gives a file full of zeros. Use a shadow copy, KAPE / Velociraptor or an image.
  • Keep Windows.db and Windows.db-wal from the same moment. Don't stop WSearch or open the original in a SQLite tool first: that can fold the WAL into the database and lose what it held.
  • A Windows.edb copied from a running system is usually in dirty-shutdown state: it is parsed, but changes still in the MSS*.log files are not included.

What is the Windows Search index?

Windows Search indexes files, folders, e-mails and browsing history so the Start menu and File Explorer can search them instantly. For each item it stores dozens of properties — full path, size, owner, created / modified / accessed times, when it was indexed — and, for text-based documents, an extract of their content (System.Search.AutoSummary).

The index is not cleaned up in real time: items deleted from disk often remain in it, with their metadata and content snippet, until the indexer catches up. It is one of the few places where evidence of deleted files — and part of their content — survives.

Where it is stored

  • Windows 11 (22H2 and later): C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.db — SQLite, with Windows.db-wal — plus Windows-gather.db, the gatherer's crawl list. The property store is normalised: SystemIndex_1_PropertyStore holds one row per (WorkId, ColumnId, Value) and SystemIndex_1_PropertyStore_Metadata maps ColumnId to property names such as System.ItemPathDisplay.
  • Windows 10 and earlier: the same folder holds Windows.edb, an ESE (JET Blue) database. SystemIndex_PropertyStore (Windows 8 and later) or SystemIndex_0A (Vista / 7) has one wide row per item, with columns named like 4447-System_ItemPathDisplay; SystemIndex_Gthr and SystemIndex_GthrPth hold the gather records and the folder tree.
  • Windows Search is a system service: one index covers the indexed locations of every user of the machine. The MSS*.log, *.jrs and MSS.chk files next to Windows.edb are its transaction logs.

Why it matters in an investigation

  • Files that no longer exist: paths, sizes, owners and timestamps of deleted items. Items present in the property store but missing from the gather table are flagged — they may have been deleted.
  • Content snippets (System.Search.AutoSummary): part of the text of documents, notes and scripts — including credentials an attacker saved, then deleted.
  • Indexed removable drives and network shares, and browsing / activity history items (URLs, titles).
  • Gather time (System.Search.GatherTime) tells when the indexer processed an item: a file indexed shortly before acquisition was recently created or changed.
  • On Windows 11, the -wal file holds the latest indexing transactions: items only in, or changed in, the WAL are marked.

Limitations

  • Windows.edb (ESE) support is validated on synthetic databases only: the reader follows the published format documentation (libesedb, Microsoft's ESE source code) but has not yet been checked against real Windows.edb files. Cross-check important findings with a second tool.
  • Not supported yet: XPRESS9 / XPRESS10 / LZ4-compressed ESE values, the SystemIndex_0A value encoding of Windows Vista / 7, replaying the MSS*.log transaction logs of a dirty-shutdown database, and recovering deleted records from free ESE or SQLite pages (deleted entries still flagged in ESE pages are counted, not shown).
  • Only indexed locations are covered (by default user profiles and the Start menu, plus any location added to the index); the index may be disabled, rebuilt or purged.
  • Timestamps are FILETIMEs (UTC). Property sets vary with file type and Windows version, so every raw property is listed too.
  • The Windows 11 layout and value encoding come from public research: Microsoft does not document the exact schema.

How to get the files

  • Collect the whole C:\ProgramData\Microsoft\Search\Data\Applications\Windows folder with KAPE, Velociraptor or from a disk image, and drop the folder or the ZIP as-is.
  • On a live system the files are locked by the WSearch service: copy them from a VSS snapshot or with a raw-copy tool. On Windows 11, copy Windows.db and Windows.db-wal at the same moment (a mismatched WAL is detected and ignored).
  • A Windows.edb copied from a running system is usually in dirty-shutdown state. It is parsed anyway; for a consistent copy, replay the logs with esentutl /r MSS on a copy of the folder — never on the original evidence.

FAQ

Is my database uploaded anywhere?

No. The parser — including its SQLite and ESE readers — is Rust compiled to WebAssembly and runs in a Web Worker in your browser. There is no upload endpoint.

Does it read Windows.edb from Windows 10?

Yes, with its own read-only ESE reader (catalog, B+-trees, fixed / variable / tagged columns, long values, 7-bit and XPRESS compression). It has been validated on synthetic databases only so far, so treat its output as a lead and confirm key findings with another tool.

Can it show deleted files?

It shows items that are still in the index after the file was deleted — often with size, owner, timestamps and a content snippet — and flags items missing from the gather table. Recovering records already removed from the database (free pages) is on the roadmap.

Why add Windows-gather.db and the -wal file?

On Windows 11, Windows.db-wal holds the most recent indexing work, and Windows-gather.db lists what the gatherer crawled. With both, the tool marks WAL-only items and spots items present in one table but not the other.

How is this different from SIDR or esedbexport?

It covers the same tables, but runs in the browser with no install, pivots every property of each item into one row, applies the WAL itself, and flags deleted candidates, content snippets, executables and removable-drive paths.

Blog

Read the blog