How to fix a dirty SRUDB.dat (ESE database recovery)

Almost every SRUDB.dat you copy off a live host is dirty. The Diagnostic Policy Service writes constantly; you image the volume mid- flush; the engine never had a chance to write its clean-shutdown record. The fix is soft recovery — replay the logs into the database — which is also exactly what Windows itself would do at next boot if you left it running.

Why your copy is dirty

ESE is a write-ahead-log engine. Writes land in SRU*.log first and are checkpointed into SRUDB.dat later. When you copy the file:

• From a live machine, even via VSS, the engine was in the middle of a write cycle.
• From a forensic image, the system was running when the image started.

esentutl /mh SRUDB.dat tells you the state:

State: Dirty Shutdown
Log Required: 1-2 (0xN-0xM)

A read-only parser opened against this file will either refuse the header or quietly skip pages that need log replay. Either way, the freshest (and often most interesting) rows are missing.

Soft recovery with esentutl

esentutl.exe ships with every Windows install. Always work on a copy of the evidence — never the original:

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

The flags:

• /r sru — log base name is sru (SRU.log, SRU00001.log, …).
• /l — directory holding the log files.
• /s — directory holding the checkpoint (SRU.chk).

Keep the copied SRUDB.dat, the SRU*.log files and SRU.chk together in one folder, and run the command from that folder as above (the cd matters): you are replaying a copy that no longer sits in C:\Windows\System32\sru\, where the logs were written.

After completion:

esentutl /mh SRUDB.dat

…should report State: Clean Shutdown. Any parser — SrumECmd, srum-dump, the ESE engine directly, or the in-browser parser — now reads every row including the freshly replayed ones.

What soft recovery does not do

Soft recovery is not repair. It applies transactions the engine already wrote to the journal. It cannot:

• Recover rows from before the oldest log file. ESE prunes old logs; if you only have the database and the most recent log, anything older than that log's coverage is permanently outside SRUM's reach.
• Fix structural corruption in the database file. For that you need hard repair, which is destructive.

When logs are missing

If you only have SRUDB.dat and no logs, soft recovery is impossible. Hard repair is the last resort:

esentutl /p SRUDB.dat

/p rebuilds the database and can discard unrecoverable rows. Use it only when there is no alternative, and explicitly note it in your report. The output is no longer a faithful copy of the original evidence.

The lesson for acquisition

Almost every "SRUM is missing the last week" complaint is really a dirty-database story. Prevent it at collection time:

• Grab the entire C:\Windows\System32\sru\ directory, not just SRUDB.dat.
• Use KAPE's SRUM target or, in Velociraptor, Windows.Triage.Targets with the SRUM target (Windows.KapeFiles.Targets on older releases) — both pull the logs and the checkpoint automatically. Windows.Forensics.SRUM is not a substitute: it parses on the endpoint and returns rows, not the database.
• Grab the SOFTWARE registry hive at the same time so network profile GUIDs resolve. The registry parser reads this hive cleanly.

See where SRUDB.dat lives for full acquisition guidance.

Documenting the recovery

For chain-of-custody, record:

• Original file path on the source image, SHA-256 of the dirty copy.
• esentutl /mh output before and after recovery (paste both).
• The exact command line used.
• SHA-256 of the recovered database.

A defence will challenge the recovery if it is not documented. A documented /r is a standard ESE operation, accepted by every court that has heard SRUM testimony.

Further reading

• The ESE database format that powers SRUDB.dat
• Where is SRUDB.dat located on Windows?
• How to parse SRUDB.dat without installing anything