Que signifie « arrêt sale » pour SRUDB.dat ?

L’en-tête de la base ESE est marqué incohérent car des transactions non commit subsistent dans les fichiers SRU*.log. Cela arrive dès qu’on copie le fichier pendant que le service SRUM le maintient ouvert.

Quelle commande le répare ?

Récupération douce : `esentutl /r sru /l /s `. Elle rejoue les logs dans la base. Ne recourez à la réparation dure (`esentutl /p`) que si les logs manquent — elle peut perdre des données.

Ai-je besoin des fichiers .log ?

Pour la récupération douce, oui. Récupérez toujours tout le répertoire C:\Windows\System32\sru\, pas seulement SRUDB.dat, pour disposer des logs et du checkpoint.

Un parseur peut-il lire une base dirty sans récupération ?

Partiellement. Les parseurs en lecture seule lisent les pages commit mais ratent les lignes récentes encore dans les logs, et certains refusent un en-tête dirty. Récupérez d’abord pour l’exhaustivité.

La récupération est-elle saine forensiquement ?

La récupération douce (`/r`) est la pratique acceptée — elle n’applique que des transactions déjà journalisées par le système. Documentez la commande et travaillez sur une copie, jamais l’original.

← Retour à l’analyseur

Réparer un SRUDB.dat corrompu (récupération de base ESE)

19/05/2026

Pourquoi votre copie est « dirty »

ESE (le moteur derrière SRUDB.dat) est transactionnel. Les écritures vont d’abord dans SRU*.log et sont flushées dans SRUDB.dat plus tard. En imageant une machine vivante ou en copiant depuis un Volume Shadow Copy, on l’attrape presque toujours en plein flush : l’en-tête est marqué arrêt sale et les lignes les plus récentes sont encore dans les logs.

Un outil en lecture seule qui l’ouvre directement refusera l’en-tête dirty ou ignorera silencieusement les pages non flushées — votre activité la plus récente (souvent la plus pertinente) manque.

Récupération douce avec esentutl

esentutl est présent sur tout Windows. Travaillez sur une copie :

mkdir C:\work\sru
copy "E:\image\Windows\System32\sru\*" C:\work\sru\
cd C:\work\sru
esentutl /r sru /l C:\work\sru /s C:\work\sru

/r sru — le nom de base des logs est sru (SRU.log, SRU00001.log…)
/l — répertoire des fichiers de log
/s — répertoire du checkpoint (SRU.chk)

Une fois terminé, esentutl /mh SRUDB.dat doit indiquer State: Clean Shutdown. Tout parseur — y compris l’analyseur navigateur — lit alors chaque ligne, y compris celles fraîchement rejouées.

Quand les logs manquent

Si vous n’avez que SRUDB.dat sans logs, la récupération douce est impossible. La réparation dure est le dernier recours :

esentutl /p SRUDB.dat

/p reconstruit la structure et peut écarter des lignes irrécupérables. À n’utiliser qu’en l’absence d’alternative, et à noter dans le rapport — la sortie n’est plus une copie fidèle de l’original.

La leçon pour l’acquisition

La plupart des problèmes « SRUM n’a pas de données récentes » sont en fait des problèmes de base dirty. Prévenez-les à la collecte : prenez tout le répertoire C:\Windows\System32\sru\. Voir Où se trouve SRUDB.dat sur Windows ? pour les outils qui le font automatiquement.

Pour aller plus loin

Questions fréquentes

Que signifie « arrêt sale » pour SRUDB.dat ?: L’en-tête de la base ESE est marqué incohérent car des transactions non commit subsistent dans les fichiers SRU*.log. Cela arrive dès qu’on copie le fichier pendant que le service SRUM le maintient ouvert.
Quelle commande le répare ?: Récupération douce : `esentutl /r sru /l <dossier logs> /s <dossier checkpoint>`. Elle rejoue les logs dans la base. Ne recourez à la réparation dure (`esentutl /p`) que si les logs manquent — elle peut perdre des données.
Ai-je besoin des fichiers .log ?: Pour la récupération douce, oui. Récupérez toujours tout le répertoire C:\Windows\System32\sru\, pas seulement SRUDB.dat, pour disposer des logs et du checkpoint.
Un parseur peut-il lire une base dirty sans récupération ?: Partiellement. Les parseurs en lecture seule lisent les pages commit mais ratent les lignes récentes encore dans les logs, et certains refusent un en-tête dirty. Récupérez d’abord pour l’exhaustivité.
La récupération est-elle saine forensiquement ?: La récupération douce (`/r`) est la pratique acceptée — elle n’applique que des transactions déjà journalisées par le système. Documentez la commande et travaillez sur une copie, jamais l’original.