How to Fix Exchange Dirty Shutdown Error 2016/2013/2010

Swiftly navigate to this tutorial to fix the Exchange unexpected shutdown error:

What is a "Dirty Shutdown" in Exchange Server?

A “Dirty Shutdown” implies that the database is down and not in a healthy state. The prime reason for a dirty shutdown is inconsistent transactions in the transaction log file. If the EDB file is not properly detached from the transaction logs, the database goes into a dirty shutdown state. Here, the Exchange server is unable to access and read the transaction logs, resulting in transaction differences.

When you encounter an Exchange dirty shutdown, you can manually repair it using the Eseutil utility. If that fails, you can still use Exchange Recovery tools to help you automatically recover and repair EDB files and content in Exchange 2019, 2016, 2013, and 2010.

Manually fixing the Dirty Shutdown error in Exchange 2016/2013/2010 using the Eseutil tool (UTF-8 encoding)

Follow the given steps to fix the issue and recover Exchange Server database after a Dirty Shutdown. If you are not well-versed with Exchange and have little knowledge about the Eseutil command, it is recommended to opt for the automatic method to resolve the Exchange Dirty Shutdown error without losing any more data.

1. Back up all database files (.edb and .stm) and log files to another location.

2. Ensure Sufficient Disk Space: To recover an Exchange database from a dirty shutdown state, you must ensure that you have 110% free disk space.

3. Check database consistency. Run the following command to check the consistency of your database:

eseutil /mh "Path to the private database" (for example: eseutil /mh "c:\db\mailbox database.edb")

4. Check the Exchange database status. The status should be Dirty Shutdown.

If Exchange shows a “Dirty Shutdown,” you can try to resolve the issue first with a “Soft Repair.” If that doesn't work, then attempt a “Hard Repair.” Let's look at each method:

Run a soft fix

eseutil /r – Run from the database log folder, and specify the log check file (C:\dblog>eseutil /r E00).

Or specify the command as:

eseutil /r "Prefix"/l > /d
Eseutil /r E00 /l c:\dblog /d c:\db This is an Eseutil command used for restoring an Exchange database. The parameters mean: - `/r "Prefix"`: Specifies the prefix of the log files. For example, if the log files start with "Prefix," this option indicates the range of log files to be used during the recovery process. - `/l` followed by the path to the log files: Specifies the directory containing the log files to be recovered, which in this case is `c:\dblog`. - `/d` followed by the target database path: Specifies where the restored database should be located, which here is `c:\db`. Please note that these parameters might vary based on your specific situation, ensuring that you correctly identify the database and log file locations. Always back up important data before performing any database recovery operation.

Check the database for consistency: Run a consistency check on the database again. If it shows a clean shutdown, proceed to Step 6. However, if the soft repair does not work, run a hard repair.

Hard fix

If soft repair doesn't work, try hard repair.

Eseutil /p, for example: Eseutil /p "C:\Program Files\Exchsrvr\Maildbdata\Priv1.edb"

5. Defragment the database. Now defragment the database by using the eseutil /d command on the mailbox database file.

Eseutil /p, for example: Eseutil /p "c:\program files\exchangesrvr\maildbdata\priv1.edb"

Before mounting the database, delete the log files from the MDBDATA folder after you run this command.

6. Check the database integrity. This command takes about ten minutes per GB of data. If you don't have the time (two to ten minutes per GB), you can skip it after a soft recovery, but you must run it after a hard recovery.

isinteg -s "Server Name" -test alltests

If that integer check fails, run this command instead.

The command `isinteg -s "servername" –fix –test - alltests` is used to run ISINTEG (Exchange Server Information Store Integrity Tool), which checks and repairs the Exchange Server's Information Store. Here's an explanation of the parameters: - `-s "servername"`: Specifies the name of the Exchange Server. - `–fix`: Indicates that if issues are detected, it will attempt to fix them. - `–test`: Specifies a particular test to run. If not specified, default settings might be used. - `-alltests`: Runs all tests, performing a comprehensive check. Please replace "servername" with the actual name of your Exchange Server when using this command.

Please run this command repeatedly until all errors are at level 0, or the status shows no change.

7. Run the database consistency check again. Use the eseutil /mh command to check the database for consistency, and the status should now show as Clean Shutdown.

Utilize Exchange Recovery Tool for Automated Recovery of Exchange Server Databases

By following the aforementioned steps, you can resolve the Exchange Dirty Shutdown issue and recover your database files. However, if you're unable to perform these steps or find the process too complicated, you can opt for a more straightforward and efficient method using the Exchange Recovery application. This software effectively repairs corrupted mailboxes in Exchange 2016, 2013, and 2010.

It swiftly scans the entire database/EDB file and extracts all recoverable items such as emails, appointments, contacts, calendar entries, notes, tasks, and journal entries from different user mailboxes. With this powerful Exchange Server recovery tool, you can effortlessly restore deleted mailboxes in Exchange.

Step 1: Select the EDB File.

Search and select the lost Exchange Database file. After selecting the EDB file, click on “Analyze”.

Step 2: Analyze the file.

The software will scan and locate lost Exchange data.

Step 3: Recover the data you need.

Select the emails and other data you need, and preview the contents of your mailboxes.

Then, you can click “Export MSG” to export the data to a specific location or click “Recover” to restore the data to the server.