Windows.edb — Windows Search Index

Windows.edb is the Extensible Storage Engine database that powers Windows Search. It contains the full text of every document, email, PDF, and source file the operating system has ever indexed — including files that have been securely deleted from disk. The Search service extracts and stores document content independently of the file. When the file is deleted, its words remain in the database. This makes Windows.edb one of the most powerful and least understood forensic artifacts in modern Windows environments.

What Is Windows.edb?

Windows.edb is the database behind Windows Search — the service that powers the search bar in the Start Menu, File Explorer, and Outlook. When a Word document is saved, when a PDF is downloaded, when an email arrives, when source code is committed to a local repository, the Windows Search indexing service (SearchIndexer.exe) reads the file, extracts its text content through IFilter protocol handlers, and stores that content in an Extensible Storage Engine (ESE) database. This is the same database engine that underpins Active Directory (ntds.dit), Exchange Server mailbox stores, and SRUM (SRUM.db).

The service was introduced in Windows Vista as Windows Desktop Search, replacing the legacy Indexing Service from Windows 2000/XP. It runs continuously in the background, re-indexing files as they are created, modified, or moved. By default, it indexes the contents of user profile directories (C:\Users\*), Outlook mailboxes, OneNote notebooks, and any locations the user has added to the indexing scope. On a system that has been in use for several years, the database can grow to several gigabytes and contain tens of thousands of indexed entries.

The critical forensic insight is this: Windows.edb contains the full text of documents that have been deleted from disk. The Search service extracts and stores document content independently of the file — when the file is deleted, its words remain in the database. The metadata record is eventually marked with a DocStatus of 1 (indicating the file is no longer present), but the extracted text in the PropertyStore often persists for days or weeks. Even after entries are purged from active tables, the ESE page structure means the data survives in freed (deallocated) pages within the database file itself — recoverable through low-level ESE page carving.

Location & Format

File Paths

Database Format

Windows.edb uses the Extensible Storage Engine (ESE), also known as JET Blue. ESE databases use a write-ahead logging model: changes are first written to transaction log files (.log), then committed to the main .edb file during checkpoint operations. Forensically, this means uncommitted entries may exist only in the log files. A “dirty shutdown” recovery (using esentutl /r) can replay these logs into the database before parsing. ESE pages are 8 KB in Windows.edb (compared to 4 KB in some other ESE databases), and each page contains a header, data rows, and tag arrays that enable page-level carving.

Internal Table Structure

Key PropertyStore PropertyIDs

What It Reveals

Windows.edb answers a class of investigative questions that no other single artifact can answer. It is the only standard Windows artifact that preserves the full text content of deleted documents. The following questions are directly answerable from Windows.edb data:

• What was the full text content of a deleted document? — The PropertyStore retains extracted body text (PropertyID 0x0013) for files that have been deleted from disk. If the document was indexed before deletion, its words are recoverable even after the file, its MFT entry, and its Recycle Bin reference have been destroyed.
• Who authored the document? — The System.Author property (PropertyID 0x0010) preserves the author name as embedded in the document metadata, independent of the filesystem owner or user who last saved the file.
• What was the original file path? — The URL column in SystemIndex_0A stores the full path as it existed at indexing time. Even if the file has been moved, renamed, and deleted, the original path is preserved.
• When was the document indexed (independent forensic clock)? — The GatherTime timestamp records when the Windows Search service last crawled the file. This timestamp is set by the Search service, not by the filesystem, and cannot be modified by user-mode timestamp manipulation tools like Timestomp or SetMACE.
• When was the document last modified at the time of indexing? — The LastModifiedTime in SystemIndex_0A captures the file’s modification timestamp as it existed when the indexer read it. If MFT timestamps have been stomped, this field preserves the pre-stomping value.
• Has a document been deleted from the system? — The DocStatus field (0=present, 1=deleted) explicitly marks files that the indexer can no longer find at their recorded path. A cluster of DocStatus=1 entries with similar timestamps indicates a mass deletion event.
• What emails were present on the system? — Windows Search indexes Outlook PST/OST files, extracting sender, recipient, subject, and body text. Email content persists in the index after messages are deleted from Outlook.
• What source code was present on the system? — The IFilter protocol handlers extract text from .txt, .py, .js, .c, .h, and other text-based files. Source code content is indexed and persists after deletion.
• Were files accessed from network paths? — If network locations (UNC paths, mapped drives) are included in the indexing scope, SystemIndex_0A records the full network path (e.g., \\fileserver\share\confidential\roadmap.docx).
• Do the filesystem timestamps match the indexer timestamps? — A discrepancy between GatherTime and MFT $SI timestamps indicates potential timestomping. The GatherTime is an independent clock that the user cannot manipulate.

Forensic Use Cases

1. Intellectual Property Theft — Patent Claims Recovery

A departing engineer deletes all patent draft documents, runs CCleaner, and uses Eraser to overwrite the free space. The MFT shows no recoverable entries. The Recycle Bin is empty. Standard forensic triage finds nothing. However, Windows.edb contains the full extracted text of every patent document the Search service indexed during the engineer’s tenure. The PropertyStore retains the body text (PropertyID 0x0013), the author field matches the engineer, and the original file paths point to C:\Users\[engineer]\Documents\Patents\Active\. The recovered text can be compared word-for-word against a competitor’s filing to prove misappropriation.

2. Insider Threat — Document Content After Deletion

An employee under investigation for data hoarding has deleted sensitive documents from a company laptop. The files are gone from disk, but Windows.edb reveals that the Search service had indexed 2,400 files in the employee’s user profile, of which 1,800 are now marked DocStatus=1 (deleted). The PropertyStore entries for these files contain the full text of internal strategy documents, customer lists, and pricing sheets. The GatherTime timestamps prove the documents existed on the machine for months before the mass deletion event on the employee’s last day.

3. Anti-Forensics Bypass — Content in Freed ESE Pages

A sophisticated actor stops the Windows Search service, deletes Windows.edb, and restarts the service (which creates a fresh, empty database). Standard ESE parsing of the new database finds nothing. However, a forensic examiner recovers the deleted Windows.edb file from unallocated disk space and performs ESE free page carving on it. The freed pages contain UTF-16LE strings with document content, file paths, and author names from entries that had been purged from the active tables months earlier. Free page carving typically recovers 20–40% additional content beyond what active table parsing yields.

4. Timestomping Detection — GatherTime vs. MFT Mismatch

An attacker deploys malware that timestomps its own executable to appear as if it was created during the original Windows installation. The MFT $STANDARD_INFORMATION timestamps show a creation date of 2019, but Windows.edb’s GatherTime for the same file shows it was first indexed in March 2026. The GatherTime cannot be modified by user-mode timestamp manipulation tools because it is set by the Search service kernel component, not by the filesystem API. The discrepancy between the MFT timestamp and the GatherTime is conclusive evidence of timestomping.

5. Email Content Recovery

Windows Search indexes Outlook PST and OST files by default, extracting sender, recipient, subject line, and message body text. When an employee permanently deletes emails from Outlook (Shift+Delete, then empties Deleted Items, then compacts the PST), the email data is removed from the mail store. However, the Windows Search index retains the extracted text of those emails in the PropertyStore. Investigators can recover the content of deleted emails — including attachments that were indexed — without needing the PST file itself.

Acquisition Methods

Live System — Volume Shadow Copy

:: Create a new Volume Shadow Copy to access the locked Windows.edb
vssadmin create shadow /for=C:

:: Note the Shadow Copy Volume Name from the output, e.g.:
:: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3

:: Copy Windows.edb from the shadow copy (bypasses file lock)
copy "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb" C:\Evidence\Windows.edb

:: Copy transaction logs for dirty-shutdown recovery
copy "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\ProgramData\Microsoft\Search\Data\Applications\Windows\*.log" C:\Evidence\

:: Copy checkpoint file
copy "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.chk" C:\Evidence\

:: Delete the shadow copy when done
vssadmin delete shadows /shadow={shadow-id} /quiet

Live System — Raw Copy Utilities

:: Using KAPE (Kroll Artifact Parser and Extractor)
kape.exe --tsource C: --tdest C:\Evidence\KAPE_Output --target WindowsSearchIndex

:: Using RawCopy (can bypass NTFS locks)
RawCopy.exe /FileNamePath:"C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb" /OutputPath:C:\Evidence\

:: Using Velociraptor (remote collection via VQL)
:: Artifact: Windows.KapeFiles.Targets with target "WindowsSearchIndex"
:: Or directly:
:: SELECT * FROM glob(globs="C:/ProgramData/Microsoft/Search/Data/Applications/Windows/*")

Forensic Image — Direct Extraction

# Mount the forensic image (read-only)
mount -o ro,noexec,nodev /dev/sdb1 /mnt/evidence

# Copy Windows.edb and transaction logs
cp /mnt/evidence/ProgramData/Microsoft/Search/Data/Applications/Windows/Windows.edb /analysis/search_index/
cp /mnt/evidence/ProgramData/Microsoft/Search/Data/Applications/Windows/*.log /analysis/search_index/
cp /mnt/evidence/ProgramData/Microsoft/Search/Data/Applications/Windows/Windows.chk /analysis/search_index/

# If the database was not cleanly shut down, recover with esentutl
# (run on a Windows analysis workstation)
esentutl /r Windows /d /l /s /8 /o

Parsing Tools & Analysis

Exporting Tables with libesedb

# Export all tables from Windows.edb using libesedb
esedbexport -m tables /analysis/search_index/Windows.edb \
    -t /analysis/search_index/export/

# List exported tables
ls /analysis/search_index/export/
# SystemIndex_0A/           ← file metadata (path, dates, DocStatus)
# SystemIndex_PropertyStore/ ← extracted content (body text, author, title)
# SystemIndex_Gthr/         ← gatherer data (GatherTime timestamps)
# SystemIndex_GthrPth/      ← gatherer path tree

Querying PropertyStore by WorkID

# Recover deleted document content from Windows.edb PropertyStore
# Requires: libesedb-python or pre-exported CSV files

import pandas as pd

# Load the SystemIndex_0A export (file metadata table)
meta = pd.read_csv('/analysis/search_index/export/SystemIndex_0A.csv', low_memory=False)

# Filter for deleted documents (DocStatus=1) in user directories
deleted = meta[(meta['DocStatus'] == 1) &
               (meta['URL'].str.contains(r'C:\\Users\\', case=False, na=False))]

print(f'Deleted documents with index entries: {len(deleted):,}')

# Get WorkIDs for deleted patent-related files
patent_files = deleted[deleted['FileName'].str.contains(
    r'patent|claims|draft|confidential', case=False, na=False)]

print(f'Patent-related deleted files: {len(patent_files)}')
for _, row in patent_files.iterrows():
    print(f'  WorkID={row["WorkID"]}  {row["FileName"]}  {row["URL"]}')

# Load the PropertyStore export
props = pd.read_csv('/analysis/search_index/export/SystemIndex_PropertyStore.csv',
                    low_memory=False)

# For each target WorkID, extract body text (PropertyID 0x0013)
target_ids = patent_files['WorkID'].tolist()

for wid in target_ids:
    body = props[(props['WorkID'] == wid) &
                 (props['PropertyID'] == '0x0013')]
    if not body.empty:
        text = body.iloc[0]['Value']
        print(f'\n--- WorkID {wid} Body Text (first 500 chars) ---')
        print(text[:500])

Sample Output

Deleted documents with index entries: 1,847
Patent-related deleted files: 7
  WorkID=14302  P-2024-003_claims_draft.docx   C:\Users\patrick\Documents\Patents\Active\P-2024-003_claims_draft.docx
  WorkID=14303  P-2024-003_technical_spec.docx  C:\Users\patrick\Documents\Patents\Active\P-2024-003_technical_spec.docx
  WorkID=14297  cache_coherency_protocol_v7.docx  C:\Users\patrick\Documents\Engineering\cache_coherency_protocol_v7.docx

--- WorkID 14302 Body Text (first 500 chars) ---
PATENT APPLICATION - CLAIMS DRAFT
Application No. P-2024-003
Title: Adaptive Bloom Filter-Based Cache Coherency Protocol for Multi-Socket Architectures

Claim 1. A method for maintaining cache coherency in a multi-socket processor system comprising:
  (a) maintaining a Bloom filter array at each socket's L3 cache controller, wherein each Bloom
      filter tracks cache line ownership with a configurable false-positive rate of 0.1% to 2.3%;
  (b) propagating invalidation requests only to sockets whose Bloom filter indicates a potential...

Retention & Persistence

Anti-Forensics Resilience

Windows.edb is one of the most resilient forensic artifacts on a Windows system. It is protected by the operating system’s file locking mechanism, stored in a privileged system directory, and not included in the target lists of any widely distributed cleanup tool. The file is locked by SearchIndexer.exe while the operating system is running, and no consumer-grade anti-forensics tool includes it in its scope.

MITRE ATT&CK Detection Mapping

Windows.edb data provides evidentiary support for detecting the following MITRE ATT&CK techniques:

Related Artifacts & Case Studies

Corroborating Artifacts

Case Study

References

1. Joachim Metz, “libesedb — Library and tools to access the Extensible Storage Engine (ESE) Database File format” — https://github.com/libyal/libesedb
2. NirSoft, “ESEDatabaseView — View ESE Database Files” — https://www.nirsoft.net/utils/ese_database_view.html
3. Arsenal Recon, “Arsenal Image Mounter and ESE Analysis Tools” — https://arsenalrecon.com
4. Microsoft, “Windows Search Overview” — https://learn.microsoft.com/en-us/windows/win32/search/windows-search
5. SANS Institute, “Windows Forensic Artifacts — Search Index (Windows.edb)” — https://www.sans.org/blog/
6. 13Cubed, “Windows Search Index Forensics” — https://www.youtube.com/@13Cubed
7. Simson Garfinkel, “bulk_extractor — High Performance Digital Forensics Exploitation Tool” — https://github.com/simsong/bulk_extractor
8. Sangjin Oh, “WinSearchDBAnalyzer — Windows Search Database Analyzer” — https://github.com/moaistory/WinSearchDBAnalyzer