How to Repair Exchange 2013 Database After a Dirty Shutdown

Effective Way to Repair Exchange 2013 Database After Dirty Shutdown

Are you also getting an error code 0X80004005 in MS Exchange? Do you want a solution to repair Exchange 2013 database after Dirty Shutdown error? This blog will help you out, to resolve similar issues by using the solution mentioned here.

The Transaction log files plays a crucial role in the effortless working of the Microsoft Exchange database. The deviations or inequalities in these log files can cause Exchange Server not to start at all or to function unexpectedly. Let us discuss about Exchange Server transaction log files and the role of these files with respect to the Exchange 2007.

Note: One of the best way to repair Exchange 2013 database after dirty shutdown is to use the advanced solution i.e. Exchange Recovery Software provided by SysTools that easily repair & recover Exchange mailbox and EDB file from minor and major corruption and export the recovered Exchange database mailboxes directly to the Live Exchange Server mailboxes 2016, 2013, 2010, 2007, 2003.

The Appearance of the Transaction Log Files in Microsoft Exchange Server 2013

Exchange transaction logs checks for even a small change accomplished in the database. At the beginning, the data is registered in these log files and then written to the database. Afterwards, it is updated in the mailboxes of a user. When one log file is completely full, then a new log file one is created with another immediate sequence number, this is because the size of the log files size is fixed.

When it is required to restore the database from an older version, that time these Transaction log files are a big advantage. Microsoft Exchange Admins not to delete any log files permanently. Alternatively, it has been suggested to verify that the back up of the log files must be at safe locations.

Role of Transaction Log Files in Exchange Dirty Shutdown Error

MS Exchange Server can start smoothly only when the database is shut down perfectly. To close the database in a proper way, it has to be checked that the data in the transaction log is attached to database files. When the complete transaction log data is committed, the database is considered to be disconnected to the log files which is a sign that the server can be easily shut down now.

When Microsoft Server turns on, the state of the database is analyzed and if it is “attached” to the transaction log files, the database is observed to be in Dirty Shutdown State or sometimes it shows an error code 0X80004005. Correspondingly, the server separates the database first, by repeating the accessible log files, and then continues to other tasks.

What Dirty Shutdown Error Is?

The database of the Microsoft Exchange Server uses ESE i.e. Extensible Storage Engine, known as JET engine also, at its core. This Jet engine uses the cache of the mailbox database in order to reduce the input-output operation count. The transaction log files are stored here in this Jet engine.

Remarkably, when on the database, a customization or application is loaded into the cache memory but doesn't attached to that database, it is considered Dirty by the Jet engine. And the database is treated inconsistent, until those Dirty transactions are not resolved. If in case the Exchange Server shuts down suddenly when the database is contradictory, this error of Dirty Shutdown is received.

Dirty Shutdown Error: The After Effects

This error shows that the files of Exchange database i.e. EDB or STM might be corrupted or damaged. In such cases, it is suggested to use ESEUTIL to recover these database files with Eseutil /k command.

Following Errors Might Occur:

• ERROR: database was not shutdown cleanly (dirty shutdown)
• Operation terminated with error -550
• Exchange is unable to mount the specified database

How to Repair Exchange 2013 Database After Dirty Shutdown

To fix Dirty Shutdown error, first of all, check if the Exchange is in clean or a dirty shutdown state.

To verify this, open the Command Prompt and then type the following syntax:
Eseutil /mh "Path of the database"

If the Database state shows Clean Shutdown, then the database is consistent and detached from the transaction log. But, if it shows Dirty Shutdown, the database is inconsistent and still attached to the log file.

The Following Few Methods can be used to Fix the Dirty Shutdown Error or 0X80004005 error code.

1. There must be Free Disk Space 110%
Check the free space and it is required to fix the priv.edb & pub.edb.
2. Use Clean Log files: In Case the Database is Consistent

In the clean state of the log files, a soft recovery of the database can resolve this error. To mount the database again, the transaction logs are replayed.

For this, use ESEUTIL command-line utility with /ml switch to first check the state of the log files through:
eseutil /ml “Path of the log files\log prefix
Then, do the soft recovery from:
eseutil /r enn /L[path to log files] /s[path to checkpoint file] /d[path to database file] /i


3. When Log files are not available or not in a clean state

When the Transaction log files are not available, can't be accessed or not in clean state, then it is required to go for a Hard Database Recovery. In this recovery process, from online backup the database is stored again and the log files are repeated again.

4. EDB, Logs, & STM files: Take the Backup

If the backup of a valid and current database is available then EDB, STM, and LOG files can be restored. When it gets completed, a ‘restore.env’ file will be created in a temporary folder as: 'C:\Temp Copy pub.edb, priv.edb, logs and .stm files to an another place.

Note: Ensure to keep a copy of the restore.env and log files. As sometimes there might be loss of data in case of Hard recovery process.

The syntax for hard recovery is: Eseutil /cc “Path of the restore.env containing folder". After the completion of the process, the temporary folder that containing restore.env gets emptied.

5. In case there isn't Any Backup Available
If the above mentioned methods doesn't works then, use ESEUtil as: eseutil /p Enter 'OK' on the consequent pop-up.
6. Check consistency of Database

Once the backup process gets completed, run eseutil with \mh switch to check database consistency again. For this run:
eseutil /mh „path of the priv.edb"
(eseutil /mh “c:\db\mailbox database.edb”) Now, the shutdown should be clean. The defragmentation of the database will resolve the error.

7. Offline Defragmentation

For the final step, de-fragment the database to arrange the DB on the server and then in order to reduce the disk space, remove the unused pages. A new and compressed database is created and this is free of old data and unused pages.

Syntax used is: eseutil /d Database_Name

Bringing It All Together

The above mentioned manual method to repair Exchange 2013 database after dirty shutdown are a bit lengthy and time-consuming to resolve this dirty shutdown or 0X80004005 error . So if you wish an other way other than ESEUTIL, it is recommended to go for a professional software like SysTools Exchange Recovery Software. The utility repair damaged/corrupted EDB file and extracts the data from the mailbox into Live Exchange Server, Office 365 and different file formats like PST, EML, PDF, HTML, and MSG formats. The application brings the corrupt Exchange databases back to the healthy state. This is an error-free solution which even a novice user can operate easily.