Windows.edb Parser Comparison: SIDR, ESEDatabaseView & More

TL;DR. For fleet-scale collection and standard reports on both Windows 10 and 11, use SIDR (Stroz Friedberg / LevelBlue). For recovering deleted records from Windows.edb, use WinSearchDBAnalyzer. For a raw look at any ESE table, ESEDatabaseView (Windows GUI) or esedbexport from libesedb (cross-platform CLI). For Windows 11, the sqlite3 shell on a copy is your ground truth. Use the Windows Search Index Parser when you want zero install, no upload, one pivoted row per item across both formats, WAL-aware diffs and triage flags. Its ESE reader has only been validated on synthetic data, so cross-check with one of the others. When findings matter, run two tools and diff.

No single tool does everything here, and the format is undocumented enough that two parsers can disagree on real data. What follows is what each tool is built for, according to its own documentation and what I could verify, without benchmarks I cannot reproduce.

The tools

SIDR

SIDR (Search Index Database Reporter) was released by Stroz Friedberg alongside Kulkarni and Paluch's 2023 research. Per its README, it scans a directory for Windows.edb and Windows.db, and writes three reports named after the host: a File Report, an Internet History Report and an Activity History Report, in JSON or CSV. It ships a velosidr.yaml Velociraptor artifact to run it on endpoints. Apache 2.0 licence.

sidr -f csv -o D:\case\reports D:\case\search

Reach for it when you process many hosts, want consistent reports across cases, or need the activity history and internet history already separated. Keep in mind: it produces curated reports rather than every raw property, and as a CLI it expects you to handle collection and review elsewhere.

WinSearchDBAnalyzer

Written by Jeonghyeon Kim (moaistory), described on his blog and on GitHub under the MIT licence. Its README highlights deleted-record recovery from Windows.edb, extraction from a live system, parsing files "regardless of status", and categories such as mail, OneNote titles, internet history and activity history. Revival forks exist, including one by Andrew Rathbun.

Reach for it when you need records that are no longer live in the ESE database. That is exactly the gap most parsers, including this one, leave open. Keep in mind: it targets the ESE format of Windows 10 and earlier, not the SQLite Windows.db of Windows 11, and it is a Windows GUI application.

ESEDatabaseView

NirSoft's generic ESE viewer. It opens any ESE database (Windows.edb, SRUDB.dat, WebCacheV01.dat and others), lets you browse and filter tables and export them to CSV, HTML, XML, JSON and other formats, from the GUI or the command line. NirSoft notes it does not need esent.dll. Its documentation is candid that on tables with complex data structures some fields may show incorrect or empty values.

Reach for it when you want to see the raw SystemIndex_PropertyStore or gather tables exactly as stored, or check a column another tool reports as empty. Keep in mind: it knows ESE, not Windows Search. There is no pivot, no path rebuilding from the gather tree, no interpretation of properties, and no Windows 11 support since Windows.db is SQLite.

esedbexport (libesedb)

Joachim Metz's libesedb is an open C library for ESE files, with esedbinfo and esedbexport tools. Its format documentation is the reference most ESE parsers, this one included, are built on. The project labels itself experimental.

esedbexport -t D:\case\export Windows.edb

Reach for it when you want a scriptable, cross-platform dump of every table, or a second opinion on the ESE layer itself. Keep in mind: the output is one text file per table, and interpretation is up to you.

sqlite3 and DB Browser for SQLite

For Windows.db, the official SQLite engine is the reference. Joining SystemIndex_1_PropertyStore with its metadata table on a copy gives you verifiable ground truth. The queries are in Windows.db forensics: SQLite and the WAL.

Keep in mind: work on a copy only. A normal SQLite client may checkpoint the WAL on close and destroy the before/after comparison.

The Windows Search Index Parser

What it does, per its own README and UI:

• Reads Windows.db (with -wal and Windows-gather.db) and Windows.edb with its own SQLite and ESE readers, compiled from Rust to WebAssembly, in a Web Worker. Nothing is uploaded.
• Pivots every property of each item into one row, joins the gather tables, rebuilds folder paths.
• Marks items only in or changed in the WAL; flags items missing from the gather table, content snippets, executables, archives, other drives, network paths, user-writable folders and recently indexed items.
• Accepts folders and KAPE / Velociraptor ZIPs as-is; exports CSV (formula-injection safe) and JSON.

What it does not do, stated plainly:

• ESE validation: its Windows.edb reader has been validated on synthetic databases only. That is why the UI warns about it.
• Windows 11 schema: decoding follows public research; the DDL and storage-type codes are undocumented.
• No carving: deleted records in free ESE pages, SQLite freelists or stale WAL frames are not recovered (defunct ESE entries are counted).
• No log replay of MSS*.log; no Vista / 7 SystemIndex_0A value decoding; no XPRESS9 / XPRESS10 / LZ4.
• No CLI or automation. Human-driven triage, not a pipeline.

Which combination for which job

When parsers disagree

Typical causes, in the order I check them:

1. Different input. One tool got the WAL or the replayed ESE database, the other did not. See the dirty-shutdown guide.
2. Long values and compression. A snippet present in one tool and empty in another usually means one of them did not follow a long-value reference or decode a compressed value. See ESE basics.
3. Multi-valued columns reduced to their first value.
4. Time decoding: byte order and UTC vs local time.
5. Record selection: defunct records shown or hidden; gather-only records included or not.

Write down which tool produced each finding and which one confirmed it. That is what a reviewer will ask.

Related articles

• How to open Windows.edb and Windows.db step by step
• Windows Search index forensics: the complete guide
• Windows.edb vs Windows.db