How to Resolve Exchange "Dirty Shutdown" Error


If you thought transaction log files are just a way of keeping track of processes, this article will change your thinking. Transaction log files play a crucial role in the smooth working of the Exchange database so much that inconsistencies in them can cause Exchange to function abruptly or not start up at all. Let us explain this with a brief intro about their role with respect to the Exchange server.

The crucial role that Exchange transaction log files play

Exchange transaction logs trace every modification done in the database. The data that is to be updated in user mailboxes is initially registered in the log files and is then written to the database. Since the log file size is fixed, once the log file is full, a new one is created with the next sequence number.

Transaction log files prove to be an asset when the database needs to be restored from an older version. Hence, Exchange administrators are always advised not to permanently delete any log files. Instead, they should make sure log files are properly backed up at safe locations and should discard them only when it is ensured that an older version of the database won’t be needed any longer.

How important are they from the perspective of Exchange Dirty Shutdown Error?

Only when the Exchange database shuts down properly can Exchange Server startup smoothly. For the database to shut down properly, it has to be ensured that all data in the transaction log is committed to database files. When all transaction log data has been committed, the database is considered to be “detached” to those log files which is a green signal for a clean shut down. When the Server starts up, it checks the state of the database and if it is found to be “attached” to the log files, the database is regarded to be in "Dirty Shutdown State". As a result, the server first “detaches” the database by replaying the available log files and then proceeds to other tasks.

A little more about Dirty Shutdown Error

Microsoft Exchange Server database uses Extensible Storage Engine (ESE) also known as JET engine at its core. The Jet engine uses mailbox database cache to reduce input-output operation count. It is this jet engine where transaction log files are stored.

So when a modification or operation on the database is loaded into the cache memory but isn’t committed to the database, it is marked as 'Dirty' by the Jet engine. Till the time all Dirty transactions are not resolved, the database is considered inconsistent. If the Exchange Server shuts down unexpectedly while the database is inconsistent, the Dirty Shutdown Error is received.

After effects of Dirty Shutdown Error

Flashing of the Dirty Shutdown Error indicates that Exchange database files (EDB or STM files) may be damaged. In such an event, if you try to use ESEUTIL to repair the database files with this command: Eseutil /k

You may get errors like:

  • ERROR: database was not shutdown cleanly (dirty shutdown)
  • Operation terminated with error -550 (JET_errDatabaseDirtyShutdown, Database was not shutdown cleanly. Recovery must first be run to properly complete database
  • 'Exchange is unable to mount the database that you specified

How to Fix Dirty Shutdown Error

As a first step, verify that the Exchange is in clean shutdown state or a dirty shutdown state. For this, open the Command Prompt and type in the following syntax: Eseutil /mh "Path of the database"

On the result screen, if the DB state shows as "Clean Shutdown", the database is detached from the transaction log and is consistent. However, if the DB state shows "Dirty Shutdown", the database is still attached to the log file and is inconsistent.

Depending upon the scenario, the following methods can be used to fix Error HR=0X80004005 or dirty shutdown error.

1. If the DB is consistent with Clean Log files

If the log files are in clean state, a soft recovery of the database should be able to resolve the error. In soft recovery, after an unexpected stop of the database, transaction logs are replayed to re-mount the database. To do this, ESEUtil command-line utility is used with /ml switch to first test the state of the log files through the syntax: eseutil /ml “Path of the log files\log prefix

And then, soft recovery is performed through the syntax: eseutil /r enn /L[path to log files] /s[path to checkpoint file] /d[path to database file] /i

2. If Log files are not in clean state or are unavailable

If log files cannot be accessed, aren’t available or are not in clean state, hard database recovery should be attempted. In hard recovery, the transaction log files are replayed by restoring the database from online backup. This is the only difference between hard and soft recovery.

If a valid and recent database backup is available, EDB, LOG and STM files can be restored from it. Once that completes, automatically, a file called ‘restore.env’ will be created in a temporary folder by the name 'C:\Temp'.

Important: You must make sure that you keep a copy of restore.env and log files. Hard recovery process sometimes involves loss of data and thus it is better to be safe.

Here is the syntax for hard recovery: Eseutil /cc “Path of the restore.env containing folder". Once the entire procedure completes, the temporary folder that contained restore.env will be empty.

3. If a valid backup isn't available

If none of the above methods is possible, use ESEUtil as follows: eseutil /p

Hit 'OK' on the subsequent pop-up that shows and then the process will commence. Once the process finishes, run eseutil with \mh switch to check database consistency again. This time, the shutdown should be clean. Defragmentation of the database now should resolve the error.

Offline Defragmentation

As a last step, database defragmentation is done to arrange the database on the server and unused pages are removed to reduce disk space. A new, compact database is created that is free of old data and unused pages. The syntax used is: eseutil /d Database_Name

Recommended Solution

If you wish to use method other than ESEUtil or want to make the entire process easier and risk-free, use professional Exchange database repair software Stellar Phoenix Mailbox Exchange Recovery. It repairs damaged EDB file and extracts all mailbox contents into PST format. The newly created PST can then be imported into Outlook and then to a different, properly functioning server. With a simple 3-step procedure, this product brings corrupt MS Exchange databases back to running state.

This proficient application is compatible with MS Exchange 2016, 2013, 2010, 2007, 2003, 2000, and 5.5.

Stellar Phoenix & Stellar Data Recovery are Registered Trademarks of Stellar Information Technology Pvt. Ltd.
© Copyright 2017 Stellar Information Technology Pvt. Ltd. All Trademarks Acknowledged.