Où est stocké Windows.edb ? Emplacement et acquisition
Emplacement de Windows.edb et Windows.db sous Windows 10 et 11, fichiers compagnons à collecter et copie de l'index Windows Search verrouillé à chaud.
En bref. L'index Windows Search se trouve dans C:\ProgramData\Microsoft\Search\Data\Applications\Windows\. Windows 10 et antérieurs : Windows.edb (ESE) avec MSS*.log, MSS.chk et *.jrs. Windows 11 : Windows.db et Windows-gather.db (SQLite), chacun avec un fichier -wal. Collectez tout le dossier. Sur un système actif, les fichiers sont verrouillés par le service WSearch : utilisez un outil de copie brute, un cliché instantané ou esentutl /y /vss. Ne copiez jamais la base SQLite sans son -wal, et attendez-vous à ce qu'un Windows.edb copié à chaud soit en état « dirty shutdown ».
Le dossier
C:\ProgramData\Microsoft\Search\Data\Applications\Windows\
ProgramData est masqué par défaut, et %ProgramData% (ou l'ancien %AllUsersProfile%) pointe dessus. L'article de dépannage Windows Search de Microsoft place Windows.edb (Windows 10) et Windows.db (Windows 11) dans ce dossier. L'emplacement de l'index peut être déplacé dans les Options d'indexation (Avancé, « Emplacement de l'index ») : si le dossier est vide sur une machine où la recherche fonctionnait manifestement, vérifiez ce réglage dans la ruche SOFTWARE avec un parseur de registre avant de conclure quoi que ce soit.
Contenu sous Windows 10 et antérieurs
| Fichier | Rôle | Nécessaire à l'analyse ? |
|---|---|---|
Windows.edb | La base ESE : magasin de propriétés, tables gather, catalogue | Oui |
MSS.log, MSSxxxxx.log | Journaux de transactions ESE | Oui, pour rejouer une base « dirty » |
MSS.chk | Checkpoint : position des journaux déjà appliquée à la base | Oui, pour le rejeu |
MSSres*.jrs / *.jrs | Journaux de réserve | À conserver, sans risque |
tmp.edb | Base temporaire | Non |
Sous-dossier GatherLogs\ | Journaux du crawl | Parfois utile, collectez-le quand même |
Contenu sous Windows 11
| Fichier | Rôle | Nécessaire à l'analyse ? |
|---|---|---|
Windows.db | Magasin de propriétés (SystemIndex_1_PropertyStore + _Metadata) | Oui |
Windows.db-wal | Journal WAL : dernières transactions validées, pas encore checkpointées | Oui, toujours avec Windows.db |
Windows-gather.db + -wal | Tables gather (SystemIndex_Gthr, SystemIndex_GthrPth) | Oui : chemins et contrôle « supprimé ? » |
Windows-usn.db, autres *.db | Bases annexes (suivi USN et autres) | À collecter, rarement nécessaires |
*.db-shm | Index en mémoire partagée du WAL | Non : SQLite le reconstruit |
L'article de Kaspersky sur les artefacts de Windows 11 liste Windows-gather.db, Windows.db et Windows-usn.db dans ce dossier.
Pourquoi les fichiers sont verrouillés
Le service Windows Search (WSearch, qui exécute SearchIndexer.exe) garde les bases ouvertes. ESE ouvre ses fichiers en mode exclusif. Comme le montre un billet archivé de Microsoft sur ESE, accéder à une base en cours d'utilisation échoue avec JET_errFileAccessDenied (-1032). Les fichiers SQLite sont eux aussi tenus ouverts. Une copie via l'Explorateur ou copy échoue ou, avec certains outils, produit un fichier rempli de zéros. C'est pourquoi le parseur signale un fichier qui commence par des zéros.
Quatre façons de collecter
1. Machine éteinte ou image montée
Montez l'image en lecture seule et copiez le dossier. Rien n'est verrouillé, rien ne bouge. C'est la voie à privilégier dès que vous disposez de toute façon d'une image disque complète.
2. KAPE ou Velociraptor sur un système actif
La cible KAPE WindowsIndexSearch collecte C:\ProgramData\Microsoft\Search\Data\Applications\Windows\ (plus GatherLogs) par accès NTFS brut. Elle récupère aussi les dossiers par utilisateur sous AppData\Roaming\Microsoft\Search\Data\Applications\S-1*\ lorsqu'ils existent.
kape.exe --tsource C: --target WindowsIndexSearch --tdest D:\case\kape
Velociraptor peut collecter le même dossier avec son accesseur NTFS. Les auteurs de SIDR fournissent aussi un artefact Velociraptor qui exécute leur parseur sur le poste.
3. esentutl avec un cliché instantané (ESE uniquement)
Windows intègre esentutl.exe. Depuis Windows 10, il sait lire une base en cours d'utilisation via un cliché instantané (Volume Shadow Copy) :
esentutl /y C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb /vss /d D:\case\Windows.edb
La copie obtenue est l'instantané d'une base ouverte : elle est donc normalement en état « dirty shutdown ». Le même billet décrit /vssrec, qui rejoue les journaux à l'intérieur du cliché. Il prévient aussi que les transactions non validées au moment du cliché sont annulées. Pour une preuve, je préfère copier en brut et rejouer ensuite sur une copie de travail, comme décrit dans le guide dirty shutdown.
4. Arrêter le service (seulement si vous pouvez modifier le système)
Sur une machine que vous avez le droit de modifier (labo, poste réinstallé ensuite de toute façon) :
net stop wsearch
robocopy "C:\ProgramData\Microsoft\Search\Data\Applications\Windows" D:\case\search /E /COPY:DAT
net start wsearch
Arrêter WSearch ferme proprement les bases : Windows.edb se retrouve en « clean shutdown » et le WAL SQLite est en général checkpointé. C'est pratique, mais vous avez modifié la preuve : le checkpoint intègre le WAL dans Windows.db et le réinitialise, et ce que contenaient les anciennes trames WAL peut être perdu. Documentez-le, ou évitez-le.
Windows 11 : gardez le WAL avec sa base
Windows.db-wal contient des transactions validées qui ne sont pas encore réécrites dans Windows.db. La documentation WAL de SQLite est explicite : les lecteurs cherchent d'abord la version la plus récente de chaque page dans le WAL. Sans le WAL, vous regardez un état plus ancien de l'index, auquel manque souvent justement l'activité la plus récente. Avec un WAL copié à un autre moment que sa base, vous obtenez des pages incohérentes. Copiez les deux en une seule opération. Le parseur vérifie que le WAL correspond à la base et ignore, avec un avertissement, un WAL qui ne correspond pas. Les détails sont dans l'analyse forensique de Windows.db : SQLite et le WAL.
Windows 10 : attendez-vous à un dirty shutdown
Un Windows.edb copié depuis un système en marche est presque toujours marqué dirty shutdown : l'en-tête indique que la base n'a pas été fermée proprement, et certaines modifications ne vivent que dans les fichiers MSS*.log. Il reste lisible. Le Windows Search Index Parser le parse et le signale. Pour une vue cohérente, rejouez les journaux sur une copie avec esentutl /r MSS. Pas à pas dans réparer un Windows.edb en dirty shutdown.
Hachez, puis travaillez sur des copies
- Calculez l'empreinte du dossier collecté avant d'y toucher.
- Lancez la récupération
esentutl,sqlite3ou tout outil susceptible d'écrire (SQLite checkpointe à la fermeture !) uniquement sur une copie de travail. - Ouvrir le
Windows.dboriginal dans un client SQLite classique peut y checkpointer le WAL. Le parsing en lecture seule dans le navigateur n'écrit rien, mais une copie ne coûte rien.
Ensuite, parsez
Déposez le dossier, ou le ZIP KAPE / Velociraptor tel quel, dans le Windows Search Index Parser. Il associe Windows.db à son -wal et à Windows-gather.db, reconnaît les journaux ESE et explique pourquoi ils ne sont pas parsés, et tout se passe localement dans le navigateur. Le pas-à-pas détaille le résultat.
FAQ
Peut-on simplement copier Windows.edb pendant que Windows tourne ?
Non. Le service Windows Search garde les fichiers ouverts et une copie classique échoue. Utilisez un outil de copie NTFS brute, un cliché instantané (VSS), esentutl /y /vss, ou arrêtez le service sur une machine que vous avez le droit de modifier.
Peut-on supprimer Windows.edb sans risque ?
Sur votre propre machine, le supprimer (service arrêté) force une reconstruction. Sur une machine sous investigation, jamais : vous détruisez la preuve et la reconstruction écrase l'espace libre.