Windows.edb en dirty shutdown : réparer avec esentutl
Pourquoi un Windows.edb collecté est en dirty shutdown, comment le vérifier avec esentutl /mh et rejouer les journaux MSS avec esentutl /r sur une copie.
En bref. Un Windows.edb copié depuis un système en marche est presque toujours en état dirty shutdown : certaines modifications validées ne se trouvent encore que dans les journaux de transactions MSS*.log. Vérifiez avec esentutl /mh Windows.edb. Pour obtenir une base cohérente, copiez tout le dossier (base, MSS*.log, MSS.chk) dans un répertoire de travail, placez-vous dedans avec cd et lancez esentutl /r MSS /d. Le /d est essentiel : sans lui, esentutl cherche la base dans le répertoire enregistré dans les journaux, c'est-à-dire l'emplacement d'origine. Parsez la copie brute et la copie récupérée si la différence peut compter. Ne lancez jamais la récupération sur la preuve originale.
Ce que signifie « dirty shutdown »
ESE écrit chaque modification dans son journal de transactions avant de mettre à jour le fichier de base. Quand le moteur s'arrête proprement, il vide tout dans la base et marque l'en-tête clean shutdown. Quand le fichier est copié pendant que le moteur tourne, ou que la machine perd l'alimentation, l'en-tête indique toujours dirty shutdown. Il peut manquer aux pages de la base des modifications qui n'existent que dans les journaux. Microsoft décrit ce mécanisme de récupération dans sa présentation d'ESE ; le concept général figure dans le glossaire.
Pour Windows Search, les fichiers sont :
| Fichier | Rôle |
|---|---|
Windows.edb | La base |
MSS.log | Journal de transactions courant |
MSSxxxxx.log (numéro de génération hexadécimal) | Générations de journaux plus anciennes encore nécessaires |
MSS.chk | Checkpoint : position jusqu'à laquelle les journaux sont déjà appliqués |
*.jrs | Journaux de réserve (sécurité en cas de disque plein) |
MSStmp.log | Journal temporaire |
Le nom de base MSS est ce que vous passez à esentutl.
Étape 1 : vérifier l'état
Sur une copie, avec esentutl.exe intégré à Windows :
esentutl /mh Windows.edb
Cherchez :
State: Dirty Shutdown
ou Clean Shutdown. La sortie indique aussi la taille de page (cbDbPage) et la plage de journaux dont la base a encore besoin. Le billet archivé de Microsoft sur esentutl et VSS montre un vrai vidage d'en-tête dans les deux états. Le Windows Search Index Parser lit le même champ d'état et avertit quand la base est « dirty ».
Si esentutl refuse d'ouvrir un fichier tenu par un autre processus, vous travaillez sur le fichier actif. Arrêtez-vous et faites d'abord une copie : voir les options d'acquisition.
Étape 2 : préparer une copie de travail
- Calculez l'empreinte du dossier collecté.
- Copiez tout le dossier dans un répertoire de travail, par exemple
D:\work\search. La récupération a besoin ensemble de la base, de toutes les générationsMSS*.loget deMSS.chk. - Utilisez une machine d'analyse Windows dont la version d'ESE est au moins aussi récente que celle du système source. Un moteur plus ancien peut refuser une base écrite par un moteur plus récent.
Étape 3 : récupération douce avec esentutl /r
cd /d D:\work\search
esentutl /r MSS /d
Ce que font les options, d'après la référence archivée d'esentutl en mode récupération :
| Option | Signification | À utiliser ? |
|---|---|---|
/r MSS | Récupération à partir des journaux de nom de base MSS | Oui |
/l | Emplacement des journaux (par défaut : répertoire courant) | Seulement si les journaux sont ailleurs |
/s | Emplacement des fichiers système comme le checkpoint (par défaut : répertoire courant) | Seulement si MSS.chk est ailleurs |
/d [chemin] | Emplacement des fichiers de base ; sans chemin, le répertoire courant. Sans /d : le répertoire enregistré à l'origine dans les journaux. | Toujours, pour que la récupération reste dans la copie de travail |
/i | Ignorer les attachements de base manquants ou incohérents | Seulement si la récupération échoue sur les attachements ; documentez-le |
/a | Autoriser la récupération à perdre des données validées si l'intégrité peut être maintenue | En dernier recours ; documentez-le |
/t | Tronquer les journaux après succès | Non : gardez les journaux comme preuve |
Relancez esentutl /mh Windows.edb. L'état doit maintenant être Clean Shutdown.
Si la récupération échoue parce qu'une génération de journal manque, votre collecte est incomplète. Recollectez si possible. Sinon, parsez la base « dirty » telle quelle et mentionnez la lacune.
Alternative : /vssrec sur un système actif
Sur un système actif sous Windows 10 ou ultérieur, esentutl peut copier la base depuis un cliché instantané et rejouer les journaux à l'intérieur du cliché en une seule opération :
cd /d C:\ProgramData\Microsoft\Search\Data\Applications\Windows
esentutl /y Windows.edb /d D:\case\Windows.edb /vssrec MSS .
C'est l'exemple du billet archivé de Microsoft (/y <source> /d <destination> /vssrec <nom de base des journaux> <chemin des journaux>), lancé depuis le dossier de la base pour que . désigne le chemin des journaux. Vous obtenez une copie propre sans arrêter le service. Deux réserves tirées du même billet : les transactions non validées au moment du cliché sont annulées, et le cliché ajoute de la charge d'E/S. Je collecte aussi le dossier brut pour préserver l'état non récupéré.
Pourquoi pas /p (réparation) ?
esentutl /p est une réparation : elle rend la base cohérente en supprimant ce qu'elle ne peut pas corriger. C'est une opération avec perte de données, destinée aux administrateurs qui veulent récupérer une base fonctionnelle. Pour une preuve, la récupération douce avec les journaux est le bon outil. Si vous avez un jour besoin de /p, lancez-le sur une copie distincte et gardez la base non réparée à côté.
Copie récupérée ou brute : laquelle analyser ?
Les deux, quand cela compte.
| Copie brute « dirty » | Copie après récupération douce | |
|---|---|---|
| Modifications récentes encore dans les journaux | Absentes | Incluses |
| Enregistrements supprimés par ces transactions journalisées | Peuvent encore être visibles | Disparus (la suppression a été appliquée) |
| Cohérence | Pages parfois en cours de mise à jour | Cohérente |
| Modifiée par vous | Non | Oui, copie de travail, documentée |
Les deux premières lignes expliquent pourquoi je garde les deux : la copie brute peut encore montrer un élément que les transactions journalisées suppriment, tandis que la copie récupérée montre les derniers ajouts. Un diff des deux exports montre exactement ce que contenaient les journaux.
Le parseur a-t-il besoin d'une base propre ?
Non. Le Windows Search Index Parser lit les bases « dirty » et signale leur état. Il liste les fichiers MSS*.log, .jrs et MSS.chk trouvés comme reconnus mais non parsés : il ne rejoue pas lui-même les journaux de transactions. Pour la vue la plus complète, récupérez une copie avec esentutl /r et déposez les deux copies l'une après l'autre. N'oubliez pas que son lecteur ESE n'a été validé que sur des bases synthétiques ; recoupez les résultats clés avec un autre outil (voir la comparaison).
FAQ
Faut-il utiliser esentutl /p sur un Windows.edb en dirty shutdown ?
Pas en première intention. /p est une réparation qui peut supprimer des pages et des données endommagées. Utilisez d'abord la récupération douce (/r) avec les journaux. Ne réparez qu'une copie, seulement si la récupération échoue, et documentez-le.
Peut-on parser un Windows.edb en dirty shutdown sans le récupérer ?
Oui. Le fichier de base est lisible ; il lui manque seulement les modifications encore dans les journaux. Le Windows Search Index Parser le lit et avertit que des modifications récentes peuvent manquer.