What does "dirty shutdown" mean for SRUDB.dat?

The ESE database header is flagged inconsistent because uncommitted transactions still live in the SRU*.log files. It happens whenever you copy the file while the SRUM service holds it open.

Which command repairs it?

Soft recovery: `esentutl /r sru /l /s `. This replays the logs into the database. Only fall back to hard repair (`esentutl /p`) if logs are missing — it can drop data.

Do I need the .log files?

For soft recovery, yes. Always acquire the entire C:\Windows\System32\sru\ directory, not just SRUDB.dat, so the logs and checkpoint are available to replay.

Can a parser read a dirty database without recovery?

Partially. Read-only parsers can usually read committed pages but will miss the most recent rows still in the logs, and some refuse a dirty header outright. Recover first for completeness.

Is recovery forensically sound?

Soft recovery (`/r`) is the accepted practice — it only applies transactions the system itself had already journalled. Document the command and work on a copy, never the original evidence.

← Back to parser

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

5/19/2026

Why your copy is "dirty"

ESE (the engine behind SRUDB.dat) is transactional. Writes land in SRU*.log first and are flushed into SRUDB.dat later. When you image a live machine or copy the file from a Volume Shadow Copy, you almost always catch it mid-flush: the database header is marked dirty shutdown and the newest rows are still in the logs.

A read-only tool that opens it directly will either refuse the dirty header or silently skip the un-flushed pages — so your most recent (often most relevant) activity is missing.

Soft recovery with esentutl

esentutl ships with every Windows install. Work on a copy:

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 — the log base name is sru (SRU.log, SRU00001.log, …)
/l — directory holding the log files
/s — directory holding the checkpoint (SRU.chk)

After it completes, esentutl /mh SRUDB.dat should report State: Clean Shutdown. Now any parser — including the browser parser — reads every row, including the freshly replayed ones.

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 structure and can discard unrecoverable rows. Use it only when there is no alternative, and note it in your report — the output is no longer a faithful copy of the original.

The lesson for acquisition

Most "SRUM has no recent data" problems are really dirty-database problems. Prevent them at collection time: grab the whole C:\Windows\System32\sru\ directory. See Where is SRUDB.dat located on Windows? for tooling that does this automatically.

Frequently asked questions

What does "dirty shutdown" mean for SRUDB.dat?: The ESE database header is flagged inconsistent because uncommitted transactions still live in the SRU*.log files. It happens whenever you copy the file while the SRUM service holds it open.
Which command repairs it?: Soft recovery: `esentutl /r sru /l <log dir> /s <checkpoint dir>`. This replays the logs into the database. Only fall back to hard repair (`esentutl /p`) if logs are missing — it can drop data.
Do I need the .log files?: For soft recovery, yes. Always acquire the entire C:\Windows\System32\sru\ directory, not just SRUDB.dat, so the logs and checkpoint are available to replay.
Can a parser read a dirty database without recovery?: Partially. Read-only parsers can usually read committed pages but will miss the most recent rows still in the logs, and some refuse a dirty header outright. Recover first for completeness.
Is recovery forensically sound?: Soft recovery (`/r`) is the accepted practice — it only applies transactions the system itself had already journalled. Document the command and work on a copy, never the original evidence.