Microsoft Premier Field Engineer notes explain why an Exchange database remains dirty after Eseutil /r. Five mistakes appear in the notes, from a wrong /d path to a stale checkpoint file. Fixes are a clean log set, correct paths and a second /mh check before mounting. Microsoft calls /p a last resort that can lose data. Notes date from 2012 and name Exchange 2007 and 2010.
You restart the Exchange server and the database will not mount. You start Eseutil /r and the database still shows Dirty Shutdown. Microsoft documents this pattern for Exchange 2010.
Facts follow the archived Microsoft Learn post Exchange database dirty state following ESEUTIL recovery. Danijel Klaric, a Microsoft Premier Field Engineer, wrote it in 2012. Exchange 2007 and 2010 appear in it.
Why does the Database Remain Dirty After Eseutil /r?
- Full file path after /d. Recovery mode needs the folder that contains the EDB file. File paths cause errors. Microsoft notes that /d in defragmentation mode takes a full file path, which adds to the confusion.
- /i switch. It exists for old storage groups where one log stream served several databases. Exchange 2010 has no storage groups. Microsoft advises against the switch.
- No /s system path. Eseutil then uses the current command prompt folder for the checkpoint file. Name the folder that contains the database and logs.
- Stale checkpoint file. Old E0x.chk files from earlier attempts can preserve the dirty state. Delete it only when the log folder contains just the logs that recovery needs.
- Error -1216. Wrong paths produced JET_errAttachedDatabaseMismatch. Adding /i hid the problem and did not solve it.
How to Recover to Clean Shutdown?
- Copy the EDB file and the required logs to a separate folder. Suspend the database copy or use a volume snapshot that you can revert.
- Check the state with /mh. Note the Log Required range. For example 124 to 124 means log E00000007C.log is the minimum.
- Check Log Committed in the same output. Recovery fails without the committed logs unless you use /a, which discards the last committed transaction.
- Verify the log set with /ml. Windows Explorer copies can drop files without a warning.
- Start recovery with folders only and name the system path.
- Check the header with /mh again before you mount the database.
eseutil /mh
eseutil /ml \E00
eseutil /R E00 /l "c:\DBRecovery" /s "c:\DBRecovery" /d "c:\DBRecovery" When is Eseutil /p the Answer?
Microsoft calls /p a repair mode that can cause data loss. Microsoft treats it as a last resort for a database that /r cannot recover.
What does Microsoft Not Say?
- Anything about Exchange 2013, 2016 or 2019. Only Exchange 2007 and 2010 appear in the post.
- Why the server restarted. Recovery is the topic and not the cause of the stop.
- Any claim that the list is final. Microsoft shares two customer cases.
Related reading: how to fix unable to mount database in Exchange and Exchange Server disaster recovery plan.
Frequently Asked Questions
Why does Exchange 2010 Show Dirty Shutdown Following Eseutil /r?
Microsoft lists five causes. They are a file path after /d, the /i switch, a missing /s path, a stale checkpoint file and a wrong path that raises error -1216.
What does /d Need in Recovery Mode?
Microsoft states that /d needs the folder that contains the EDB file and not the full file path.
Is It Safe to Delete the Checkpoint File?
Microsoft says yes when the log folder contains only the logs that recovery needs.
What does Error -1216 Mean?
Microsoft names it JET_errAttachedDatabaseMismatch and links it to a wrong path in the post.
When do I Use Eseutil /p?
Use /p only after /r fails. Microsoft warns that it can cause data loss.
Key Takeaways
- Wrong paths and a stale checkpoint file cause a dirty database.
- Eseutil /r needs folders after /d and /s and not a file path.
- Eseutil /mh before and after recovery confirms the state.
- Eseutil /ml checks the log set before recovery.
- Eseutil /p is a last resort because it can lose data.
Sources and References
Facts follow an archived Microsoft Learn post.