How to Open Windows.edb and Windows.db (Step by Step)
Step-by-step: open and analyse a Windows Search index (Windows.edb or Windows.db) in your browser, read the flags, filter, and export a CSV for your timeline.
TL;DR. Collect the whole C:\ProgramData\Microsoft\Search\Data\Applications\Windows\ folder. Drop it, or the KAPE / Velociraptor ZIP, on the Windows Search Index Parser. It pairs Windows.db with its -wal and Windows-gather.db (Windows 11) or reads Windows.edb (Windows 10), pivots every property into one row per item and flags what deserves a look. Read the warnings first, filter on flags, open the interesting items, export CSV. Nothing leaves your browser.
People searching "how to open Windows.edb" mostly land on Exchange EDB recovery products. Wrong file. Windows.edb is the Windows Search index, an ESE database with nothing to do with mailboxes. Here is how to open it, and its Windows 11 successor, without installing anything.
Before you start
You need a copy, not the live file. The Windows Search service locks the databases. The collection options (image, KAPE WindowsIndexSearch, Velociraptor, esentutl /y /vss) are in where Windows.edb is stored and how to acquire it.
What to have in hand:
| Windows version | Minimum | Better |
|---|---|---|
| Windows 11 | Windows.db | Windows.db + Windows.db-wal + Windows-gather.db (+ its -wal) |
| Windows 10 and earlier | Windows.edb | The whole folder, and a log-replayed copy if the database is dirty |
If you just want to see what the output looks like, use Try a sample (Windows 11) or Windows 10 sample (.edb) on the home page. Both are synthetic databases built for a fictional intrusion; no real data.
Step 1: drop the folder
Open the parser and drop the folder on the drop zone, or use Choose a folder / Choose files. ZIP collections are opened in the browser, including nested ZIPs up to a few levels deep. You do not need to unpack a KAPE archive first.
What happens next:
Windows.dbis paired with theWindows.db-walandWindows-gather.dbfound in the same folder.Windows.edbis read by the built-in ESE reader.- ESE logs (
MSS*.log,*.jrs),MSS.chk,tmp.edb,-shmfiles and the other Windows Search databases (Windows-usn.dband friends) are listed under Files not parsed with the reason. - A file that starts with zeros is reported as probably locked or still being written when it was copied.
Parsing runs in a Web Worker with WebAssembly. There is no upload endpoint. That matters when the index contains a client's document text.
Step 2: read the warnings before the numbers
The header shows counters: computers, indexed items, items with content, items not in gather table, items only in the WAL, flagged items. Under them, the warnings tell you how far to trust those counters:
| Warning | What it means | What to do |
|---|---|---|
No -wal file for Windows.db | The most recent committed transactions are missing | Re-collect Windows.db-wal with the database |
| No Windows-gather.db | No folder paths from the gather tree, no "not in gather table" check | Add Windows-gather.db from the same folder |
| WAL ignored (implausible) | The WAL does not belong to this database or was copied at another moment | Re-collect both files in one operation |
| Dirty shutdown (Windows.edb) | Changes still in MSS*.log are not included | Replay the logs on a copy (guide) and parse again |
| Validated on synthetic databases only | The ESE reader has not yet been checked against real Windows.edb files | Cross-check important findings with a second tool |
| N deleted (defunct) records seen | Deleted ESE entries exist in the pages but are not recovered yet | Consider a carving tool if they matter |
Step 3: triage with categories and flags
The category buttons split the items into files, folders, executables and scripts, archives and disk images, web / history, other, and items with a content snippet. Flagged only keeps items with at least one flag:
| Flag | Rule |
|---|---|
| User-writable folder | AppData, Downloads or Desktop of a profile, Users\Public, ProgramData, Windows\Temp, $Recycle.Bin, PerfLogs |
| Executable / script | .exe, .dll, .ps1, .bat and other executable or script extensions |
| Archive / image | .zip, .7z, .rar, .iso, .vhdx and similar |
| Other drive (USB?) | Drive letter other than C: |
| Network path | UNC path (\\server\share) |
| Recently indexed | Indexed after its last modification and within 24 h of the newest gather time in that index |
| Content snippet | System.Search.AutoSummary is present |
| Only in WAL / Changed in WAL | Added or modified by transactions still in Windows.db-wal, not yet checkpointed into Windows.db |
| Not in gather table (deleted?) | In the property store but no gather record for that WorkId |
| Gather table only | Gather record whose properties are gone from the store |
These are triage heuristics, not verdicts. "Other drive" can be a second internal disk. "Not in gather table" can be an item the gatherer has not reconciled yet. The search box filters on path, name, content, owner, URL and dates at the same time. Typing creds, .ps1, \\ or an account name is often the fastest way in.
Step 4: open an item
Click a row. The detail panel shows:
- Path, URL, type and kind
- Created, modified, accessed and Indexed (gather time)
- Owner and computer
- WorkId / DocumentID and where the item was found (property store and gather table, store only, gather only)
- Write-ahead log status for Windows 11
- Content snippet
- Gather table record: gatherer path, last modified, scope ID
- All properties: every raw property decoded, so nothing is hidden behind the summary columns
The meaning of each property is explained in Windows Search index properties explained.
Step 5: time zone and export
Timestamps are stored as FILETIMEs in UTC. The UTC / Local toggle only changes the display. Export CSV or JSON of the current filtered view. The CSV is protected against formula injection, which matters because paths and snippets are attacker-controlled text that will end up in someone's spreadsheet. Large indexes render 500 rows at a time; the export includes all rows that match your filters.
Step 6: corroborate
The index tells you a file existed at a path with given metadata and, sometimes, what it contained. Before you write "the attacker used X":
- Execution: Prefetch, Amcache, ShimCache.
- Opening a file: LNK files and Jump Lists.
- Creation and deletion times: the USN journal and the Recycle Bin.
- Logons and services: event logs.
When to use something else
For fleet-wide collection and reporting, SIDR with its Velociraptor artifact is the better fit. For carving deleted ESE records, look at WinSearchDBAnalyzer. For a raw table dump of any ESE file, esedbexport or NirSoft's ESEDatabaseView. The trade-offs are in Windows Search index parsers compared.