Wo liegt Windows.edb? Speicherort und Sicherung

Kurz gesagt. Der Windows-Search-Index liegt in C:\ProgramData\Microsoft\Search\Data\Applications\Windows\. Windows 10 und älter: Windows.edb (ESE) plus MSS*.log, MSS.chk und *.jrs. Windows 11: Windows.db und Windows-gather.db (SQLite), jeweils mit einer -wal-Datei. Den ganzen Ordner sichern. Im laufenden System sperrt der Dienst WSearch die Dateien, daher ein Rohkopie-Tool, eine Schattenkopie oder esentutl /y /vss verwenden. Die SQLite-Datenbank nie ohne ihre -wal-Datei kopieren, und bei einer live kopierten Windows.edb mit dem Zustand „Dirty Shutdown“ rechnen.

Der Ordner

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

ProgramData ist standardmäßig ausgeblendet; %ProgramData% (oder das ältere %AllUsersProfile%) verweist darauf. Microsofts Troubleshooting-Artikel zu Windows Search verortet Windows.edb (Windows 10) und Windows.db (Windows 11) in diesem Ordner. Der Indexspeicherort lässt sich in den Indizierungsoptionen (Erweitert, „Indexspeicherort“) verschieben. Ist der Ordner auf einem Rechner leer, auf dem die Suche offensichtlich funktionierte, zuerst diese Einstellung in der SOFTWARE-Hive mit einem Registry-Parser prüfen, bevor man Schlüsse zieht.

Inhalt unter Windows 10 und älter

Datei	Rolle	Für die Analyse nötig?
`Windows.edb`	Die ESE-Datenbank: Eigenschaftenspeicher, Gather-Tabellen, Katalog	Ja
`MSS.log`, `MSSxxxxx.log`	ESE-Transaktionsprotokolle	Ja, um eine „dirty“ Datenbank nachzuspielen
`MSS.chk`	Checkpoint: bis zu welcher Protokollposition die Datenbank bereits aktualisiert ist	Ja, für das Nachspielen
`MSSres.jrs` / `.jrs`	Reserveprotokolle	Behalten, harmlos
`tmp.edb`	Temporäre Datenbank	Nein
Unterordner `GatherLogs\`	Crawl-Protokolle	Gelegentlich nützlich, trotzdem sichern

Inhalt unter Windows 11

Datei	Rolle	Für die Analyse nötig?
`Windows.db`	Eigenschaftenspeicher (`SystemIndex_1_PropertyStore` + `_Metadata`)	Ja
`Windows.db-wal`	Write-Ahead-Log: die neuesten bestätigten Transaktionen, noch nicht gecheckpointet	Ja, immer zusammen mit `Windows.db`
`Windows-gather.db` + `-wal`	Gather-Tabellen (`SystemIndex_Gthr`, `SystemIndex_GthrPth`)	Ja: Pfade und „gelöscht?“-Prüfung
`Windows-usn.db`, weitere `*.db`	Hilfsdatenbanken (USN-Nachverfolgung und andere)	Sichern, selten nötig
`*.db-shm`	Shared-Memory-Index des WAL	Nein: SQLite baut ihn neu auf

Kasperskys Beitrag zu den Artefakten von Windows 11 nennt Windows-gather.db, Windows.db und Windows-usn.db in diesem Ordner.

Warum die Dateien gesperrt sind

Der Dienst Windows Search (WSearch, führt SearchIndexer.exe aus) hält die Datenbanken offen. ESE öffnet seine Dateien exklusiv. Wie ein archivierter Microsoft-Blogbeitrag zu ESE zeigt, scheitert der Zugriff auf eine verwendete Datenbank mit JET_errFileAccessDenied (-1032). Auch SQLite-Dateien bleiben geöffnet. Eine Kopie per Explorer oder copy schlägt fehl oder erzeugt bei manchen Tools eine mit Nullen gefüllte Datei. Deshalb markiert der Parser Dateien, die mit Nullen beginnen.

Vier Wege zur Sicherung

1. Ausgeschalteter Rechner oder eingebundenes Abbild

Das Abbild schreibgeschützt einbinden und den Ordner kopieren. Nichts ist gesperrt, nichts ändert sich. Das ist der bevorzugte Weg, wann immer ohnehin ein vollständiges Datenträgerabbild vorliegt.

2. KAPE oder Velociraptor im laufenden System

Das KAPE-Target WindowsIndexSearch sichert C:\ProgramData\Microsoft\Search\Data\Applications\Windows\ (plus GatherLogs) per NTFS-Rohzugriff. Es erfasst außerdem benutzerspezifische Ordner unter AppData\Roaming\Microsoft\Search\Data\Applications\S-1*\, sofern vorhanden.

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

Velociraptor kann denselben Ordner mit seinem NTFS-Accessor sichern. Die Autoren von SIDR liefern außerdem ein Velociraptor-Artefakt, das ihren Parser auf dem Endpunkt ausführt.

3. esentutl mit einer Schattenkopie (nur ESE)

Windows bringt esentutl.exe mit. Seit Windows 10 kann es eine verwendete Datenbank über eine Volumeschattenkopie lesen:

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

Die Kopie ist eine Momentaufnahme einer geöffneten Datenbank und daher normalerweise im Zustand „Dirty Shutdown“. Derselbe Beitrag beschreibt /vssrec, das die Protokolle innerhalb der Schattenkopie nachspielt. Er warnt auch, dass zum Zeitpunkt der Schattenkopie nicht bestätigte Transaktionen zurückgerollt werden. Für Beweismittel kopiere ich lieber roh und spiele später auf einer Arbeitskopie nach, wie in der Anleitung zum Dirty Shutdown beschrieben.

4. Den Dienst beenden (nur wenn das System verändert werden darf)

Auf einem Rechner, den man verändern darf (Labor, wird ohnehin neu aufgesetzt):

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

Das Beenden von WSearch schließt die Datenbanken sauber: Windows.edb endet im Zustand „Clean Shutdown“, und das SQLite-WAL wird in der Regel gecheckpointet. Bequem, aber die Spur wurde verändert: Der Checkpoint schreibt das WAL in Windows.db und setzt es zurück, und was die alten WAL-Frames enthielten, kann verloren gehen. Dokumentieren oder vermeiden.

Windows 11: das WAL mit seiner Datenbank sichern

Windows.db-wal enthält bestätigte Transaktionen, die noch nicht in Windows.db zurückgeschrieben wurden. Die WAL-Dokumentation von SQLite ist eindeutig: Leser suchen die neueste Version jeder Seite zuerst im WAL. Ohne WAL sieht man einen älteren Stand des Index, dem oft genau die jüngste Aktivität fehlt. Mit einem WAL, das zu einem anderen Zeitpunkt als die Datenbank kopiert wurde, erhält man inkonsistente Seiten. Beide in einem Vorgang kopieren. Der Parser prüft, ob das WAL zur Datenbank passt, und ignoriert ein unpassendes mit einer Warnung. Details in Windows.db-Forensik: SQLite und das WAL.

Windows 10: mit einem Dirty Shutdown rechnen

Eine aus einem laufenden System kopierte Windows.edb ist fast immer als Dirty Shutdown markiert: Der Header besagt, dass sie nicht sauber geschlossen wurde, und manche Änderungen existieren nur in den MSS*.log-Dateien. Lesbar ist sie trotzdem. Der Windows Search Index Parser wertet sie aus und weist darauf hin. Für einen konsistenten Stand die Protokolle auf einer Kopie mit esentutl /r MSS nachspielen. Schritt für Schritt in Windows.edb nach Dirty Shutdown reparieren.

Erst hashen, dann auf Kopien arbeiten

Den gesicherten Ordner hashen, bevor irgendetwas angefasst wird.
esentutl-Wiederherstellung, sqlite3 oder jedes Tool, das schreiben könnte (SQLite checkpointet beim Schließen!), nur auf einer Arbeitskopie ausführen.
Das Öffnen der originalen Windows.db in einem normalen SQLite-Client kann das WAL hineinschreiben. Das schreibgeschützte Parsen im Browser schreibt nichts zurück, aber eine Kopie kostet nichts.

Dann parsen

Den Ordner oder das KAPE- / Velociraptor-ZIP unverändert auf den Windows Search Index Parser ziehen. Er ordnet Windows.db ihrer -wal-Datei und Windows-gather.db zu, erkennt die ESE-Protokolle und erklärt, warum sie nicht ausgewertet werden, und läuft lokal im Browser. Die Schritt-für-Schritt-Anleitung erklärt die Ausgabe.

FAQ

Kann man Windows.edb einfach kopieren, während Windows läuft?

Nein. Der Dienst Windows Search hält die Dateien geöffnet, eine normale Kopie schlägt fehl. Stattdessen ein Tool für NTFS-Rohkopien, eine Volumeschattenkopie (VSS), esentutl /y /vss verwenden oder den Dienst auf einem Rechner beenden, den man verändern darf.

Kann man Windows.edb gefahrlos löschen?

Auf dem eigenen Rechner erzwingt das Löschen (bei beendetem Dienst) eine Neuerstellung. Auf einem untersuchten Rechner niemals: Die Spur wird vernichtet, und die Neuerstellung überschreibt freien Speicher.