Windows.edb Dirty Shutdown: Recover It with esentutl
Why a collected Windows.edb is in dirty-shutdown state, how to check it with esentutl /mh, and how to replay the MSS logs with esentutl /r safely on a copy.
TL;DR. A Windows.edb copied from a running system is almost always in dirty shutdown state: some committed changes are still only in the MSS*.log transaction logs. Check with esentutl /mh Windows.edb. To get a consistent database, copy the whole folder (database, MSS*.log, MSS.chk) to a working directory, cd into it and run esentutl /r MSS /d. The /d matters: without it, esentutl looks for the database in the directory recorded in the logs, which is the original location. Parse both the raw and the recovered copy if the difference could matter. Never run recovery on the original evidence.
What "dirty shutdown" means
ESE writes every change to its transaction log before it updates the database file. When the engine shuts down properly, it flushes everything into the database and marks the header clean shutdown. When the file is copied while the engine is running, or the machine loses power, the header still says dirty shutdown. The database pages may be missing changes that exist only in the logs. Microsoft describes this recovery design in its ESE overview; the general concept is in the glossary.
For Windows Search the files are:
| File | Role |
|---|---|
Windows.edb | The database |
MSS.log | Current transaction log |
MSSxxxxx.log (hex generation number) | Older log generations still needed |
MSS.chk | Checkpoint: position up to which the logs are already applied |
*.jrs | Reserve logs (disk-full safety) |
MSStmp.log | Temporary log |
The base name MSS is what you pass to esentutl.
Step 1: check the state
On a copy, with the built-in esentutl.exe (Windows):
esentutl /mh Windows.edb
Look for:
State: Dirty Shutdown
or Clean Shutdown. The output also shows the page size (cbDbPage) and the log range the database still needs. Microsoft's archived esentutl VSS post shows a real header dump with both states. The Windows Search Index Parser reads the same state field and warns when it is dirty.
If esentutl refuses to open a file that another process holds, you are working on the live file. Stop and make a copy first: see acquisition options.
Step 2: prepare a working copy
- Hash the collected folder.
- Copy the whole folder to a working directory, for example
D:\work\search. Recovery needs the database, allMSS*.loggenerations andMSS.chktogether. - Use a Windows analysis machine whose ESE version is at least as recent as the source system's. An older engine may reject a database written by a newer one.
Step 3: soft recovery with esentutl /r
cd /d D:\work\search
esentutl /r MSS /d
What the options do, per the archived esentutl recovery reference:
| Option | Meaning | Use it? |
|---|---|---|
/r MSS | Recovery using logs with base name MSS | Yes |
/l | Location of log files (default: current directory) | Only if the logs are elsewhere |
/s | Location of system files such as the checkpoint (default: current directory) | Only if MSS.chk is elsewhere |
/d [path] | Location of the database files; without a path, the current directory. Default when /d is absent: the directory originally recorded in the logs. | Always, to keep recovery inside the working copy |
/i | Ignore mismatched or missing database attachments | Only if recovery fails on attachments; document it |
/a | Allow recovery to lose committed data if integrity can be kept | Last resort; document it |
/t | Truncate log files after success | No: keep the logs as evidence |
Run esentutl /mh Windows.edb again. The state should now be Clean Shutdown.
If recovery fails because a log generation is missing, you have an incomplete collection. Re-collect if possible. Otherwise, parse the dirty database as it is and state the gap.
Alternative: /vssrec on a live system
On a live Windows 10 or later system, esentutl can copy the database out of a shadow copy and replay the logs inside the snapshot in one go:
cd /d C:\ProgramData\Microsoft\Search\Data\Applications\Windows
esentutl /y Windows.edb /d D:\case\Windows.edb /vssrec MSS .
This mirrors the example in Microsoft's archived post (/y <source> /d <destination> /vssrec <log base name> <log path>), run from the database folder so that . is the log path. It gives you a clean copy without stopping the service. Two caveats from the same post: transactions not committed when the snapshot was taken are rolled back, and the snapshot adds I/O load. I also collect the raw folder so the unrecovered state is preserved.
Why not /p (repair)?
esentutl /p is a repair: it makes the database consistent by discarding what it cannot fix. That is a data-loss operation meant for administrators who want a working database back. For evidence, soft recovery with the logs is the right tool. If you ever need /p, run it on a separate copy and keep the unrepaired database next to it.
Recovered or raw: which do you analyse?
Both, when it matters.
| Raw dirty copy | Soft-recovered copy | |
|---|---|---|
| Recent changes still in logs | Missing | Included |
| Records deleted by those logged transactions | May still be visible | Gone (the deletion has been applied) |
| Consistency | Pages may be mid-update | Consistent |
| Modified by you | No | Yes, a working copy, documented |
The first two rows are why I keep both: the raw copy can still show an item that the logged transactions delete, while the recovered copy shows the latest additions. A diff of the two exports shows exactly what the logs contained.
Does the parser need a clean database?
No. The Windows Search Index Parser reads dirty databases and flags the state. It lists the MSS*.log, .jrs and MSS.chk files it finds as recognised but not parsed: it does not replay transaction logs itself. For the most complete view, recover a copy with esentutl /r and drop both copies in turn. Remember that its ESE reader has been validated on synthetic databases only; cross-check key results with another tool (see the comparison).
FAQ
Should I use esentutl /p on a dirty Windows.edb?
Not as a first step. /p is a repair that can discard damaged pages and data. Use soft recovery (/r) with the logs first. Repair only a copy, only when recovery fails, and document it.
Can I parse a dirty Windows.edb without recovering it?
Yes. The database file is readable; it just lacks the changes still in the logs. The Windows Search Index Parser reads it and warns that recent changes may be missing.