How to Resolve Exchange "Dirty Shutdown" Error

Log files play a critical role in keeping the Exchange database (EDB) healthy and optimized for performance. It also helps provide faster data access and protect the database from corruption or file locks. Exchange transaction log files keep records of every transaction or change performed or made on the Exchange Server. These records in log files are then committed to the in-memory copy of the Exchange database file. If the changes or logs are not committed to the database for reasons, such as power failure, server crash, or the
logs files missing or corrupted
, the database may dismount or get corrupt and display the ‘Dirty Shutdown’ error.

What are the After-Effects of Dirty Shutdown and How to Tackle Them?

The dirty shutdown error is not easy to resolve. However, the native tools in Exchange Server may help you identify the issues and guide you in restoring the database to Clean Shutdown state. If you try mounting the database with the Dirty Shutdown state, you may encounter the following errors:

• ERROR: the database was not shutdown cleanly (dirty shutdown)
• Operation terminated with error -550 (JET_errDatabaseDirtyShutdown, Database was not shut down cleanly. Recovery must first be run to properly complete the database 
• Unable to mount database. (hr=0x80004005, ec=-528) 

Steps to Resolve Exchange Dirty Shutdown Error

If Exchange database gets corrupt, displays a Dirty Shutdown error, or does not mount, you can use the EseUtil — a built-in command line-based Exchange database recovery tool provided by Microsoft. The tool replays the uncommitted logs to the database (Soft Recovery) to bring it to consistent state or Clean Shutdown state. The steps are as follows:

Step 1: Check Database State and Uncommitted Logs

Open the Exchange Management Shell or Command Prompt as administrator and run the following command to check the database state and note the uncommitted logs from the command output.

eseutil /mh 

databasefilename /databasefilename

It will show the state as Dirty Shutdown and also display the log prefix which isn’t committed.

Step 2: Check the Logs’ Health

Before you replay the uncommitted logs on the database file, run the following command to check the log files’ health status.

eseutil /ml "M:\mbx01\logs"

If the output displays ‘No damaged log files were found, you may proceed to Step 3. Otherwise, you will need to perform the Hard Recovery discussed in Step 4.

Step 3: Perform Soft Recovery

You can perform the Soft Recovery (EseUtil/r) if the logs are available and in a healthy state. The command is as follows:

eseutil /r E03 /l M:\ExDb\logs /d M:\ExDb\DB01

The E03 is the log prefix that needs to be replayed.

After running the command, check the output. If it displays the repaired successfully output, check the database state using the command.

eseutil /MH databasepath /databasepath

Note: Recovering a database with EseUtil doesn't guarantee that the database will mount afterward.

Step 4: Run Hard Recovery

If the Soft Recovery fails or the database is still in Dirty Shutdown state, you can run Hard Recovery (eseutil/p) using the following command.

databasepath /databasepath

If you run Hard Recovery, you must accept three things:

• There is no 100% guarantee that the database will get mounted.
• You must accept data loss as it deletes any corrupted data.
• You cannot get Microsoft support after you run this.

Also, you cannot just mount the database even after the recovery is complete. You need to run a defragmentation process on the database to arrange the database data, and compact and free the old data and unused pages. However, this process takes a considerable amount of time to complete, depending on the size of the database. You also need to move the mailboxes from the repaired database to a new database file (EDB) on your server as the repaired database may fail or get damaged again. It’s also hardcoded so avoid using it.

  Case Study

Data Loss Nightmare? iConnect Consulting Inc. resolved dirty shutdown error with Stellar Repair for Exchange Software!

See how iConnect consulting Inc.used Stellar Repair for Exchange

Read Case Study

To avoid the risk of data loss, save time, and ensure Microsoft Support, do not run the Hard Recovery on your corrupt or inconsistent Exchange database with Dirty Shutdown state.

Instead, use a third-party software, such as Stellar Repair for Exchange, to fix the database file (EDB). The software can extract mailboxes from the inconsistent or corrupt Exchange database and save them to PST format. You may also export the mailboxes from the corrupt or dismounted databases to the live Exchange Server or Office 365 directly in a few clicks.

Conclusion

By using native tools to repair a database, you will end up spending several hours with no guarantee of recovery. On the other hand, the users will not be able to access, send, or receive emails during the process. Apart from the business aspects, where business opportunities can be lost due to downtime, loss of data can result in legal obligations. The solution would be to have the issue rectified in the least possible time and without data loss.

You can use Stellar Repair for Exchange software that can repair damaged databases and extract mailboxes in common formats, such as PST, EML, MSG, HTML, RTF, and PDF. In case the database is down due to Dirty Shutdown or severe corruption, you can create a new blank database so that the users can continue their work and resume sending and receiving emails. The users will gradually see their old emails coming up into their mailboxes with minimum risk and interruption to their business and daily work. The application can also be used for Office 365 migration as it can export an EDB file directly to an Office 365 tenant. Stellar Repair for Exchange is compatible with all Exchange database formats - from 5.5 to the latest 2019 version.