Read time 7 minutes
Exchange Server offers great ease and flexibility to the users to access their mailbox information either using Outlook or Outlook Web Access, as per their needs. All the data in an Exchange Server is stored within Exchange database (.edb file). The most common reason why Exchange Server goes in an inconsistent or Dirty Shutdown state is transaction logs not being committed to the exchange database. This can be due to any reason such as power failure or system crashes. The transaction logs record all the transactions made on an Exchange server. These logs play a major role providing easy access to the data and save databases from unexpected corruptions.
What are the possible causes of Exchange database dirty shutdown?
Dirty Shutdown in Exchange database is a result of several factors. The following are some of the scenarios that can lead to the error:
- When the computer system does not shut down properly, then it may result in a dirty shutdown problem.
- A severe malware, spyware, or trojan attack on the database may disrupt it from working and leave it dirty perhaps.
- A hacking attempt on the database may also cause errors including dirty shutdown problem.
- If the user turned off the computer unexpectedly while the Exchange was open or there was an ongoing process, then the dirty shutdown error will occur.
- In a rare circumstance, the Exchange Server can crash abruptly.
In such a scenario, the user gets an error message indicating:
Some other situations may show same types of errors like the following:
“Operation terminated with error -550 JET_errDatabaseDirtyShutdown, Database was not shutdown cleanly.”
“Exchange is unable to mount the database that you specified database:0f770444-9988-7d33-80009-3718f2f48229;Error Code:MapiExceptionCallfailed:Unable to mount database. (hr=0×80004005, ec=-528).”
What is Dirty shutdown?
Exchange Server database is designed using JET or Joint Engine Technology in which log files are given a significant role to keep a constant record of input and output operations going on in the EDB files. But when these log files are left in the cached memory without being committed to the Information Store, then JET engine term them as DIRTY. Moreover, if in this incomplete process, the system is turned off accidentally, it displays dirty shutdown error. If the database is down, inconsistent or unhealthy state, it cannot be mounted again on the server hence blocking the data accessibility.
The main reason for Exchange database dirty shutdown is the inconsistency in transactions of the transactional log files. The database goes in the dirty shutdown state when EDB or STM files are not properly detached from the transaction log files. Because of this issue, the server is unable to read the transaction logs and hence creates transactional discrepancy. In this situation, when the user tries to open the EDB files, it displays the dirty shutdown Exchange error.
Note: A transaction log file is a highly important piece of information for the database as it consistently keeps track of all changes made in the Exchange database. All the changes made on those user mailboxes are first registered in these log files and then to the database. The log files are generated in sequence and help users to understand the complete log history.
Verify the Exchange Server state
You need to first verify whether the database is properly detached from transaction files or not, in order to check it is a clean or dirty shutdown Exchange. To analyze the state of database, follow the below provided steps:
Go to the ‘Start’ button and then type ‘cmd’ in the run textbox and hit enter.
Note: here it is assumed that your Exchange Server is installed at this location ‘c:\program files\exchsrvr folder’ and the database is saved in:‘c:\program files\exchsrvr\mdbdata folder’
Now, type the given command, for private folder database file:
Type the given command, for public folder database file:
Verify the exchange database state, as:
- In the clean shutdown state, your database is detached properly
- In the dirty shutdown state, the transactions are not committed to the database
Resolution for dirty shutdown error
In order to resolve the issue of dirty shutdown, it is required to bring the database back into a clean shutdown state. For this, transactional log files have to be re-committed into the database. The solution is definitely complex and requires running certain commands in the ESEUTIL application for the database repair. The process may seem long and fixes minor glitches only. Follow the below mentioned steps for Exchange dirty shutdown repair and achieving clean shutdown state using manual technique:
- Keep a backup of entire Exchange database files, including log files, private & public folder files and STM files to a secure location on the system. Also, make sure you have sufficient space in your system to perform the repair process. The space required should be a minimum of 1.2 times the size of the Exchange database file.
- Use Eseutil, an inbuilt repair utility of Exchange Server to check the consistency of the database. The default location of this free utility provided by Microsoft is – C:\program files\exchsrvr folder\bin\ESEUTIL.
- Run the following command on the tool:
Eseutil/mh “C:\ program files\ exchsrvr\ mdbdata\ priv1.edb”
- If the database is affected from dirty shutdown state, then run the following command to perform soft repair on corrupt EDB files:
Eseutil/r “C:\ program files\ exchsrvr\ mdbdata\ priv1.edb“
- Again, check for database consistency. If the database consistency is OK, remount the database. But, if it is still found in an inconsistent state, then use the following command to perform the hard repair on corrupt EDB files:
Eseutil/p “C:\ program files\ exchsrvr\ mdbdata\ priv1.edb“
- Defragment the database to remove empty disk space within it by running this command “Eseutil/ d” on the utility. It arranges the database on the server in this manner.
- Lastly, check the integrity of the database by using another utility “Isinteg”. Now run this command line :
Isinteg –s servername –fix –test alltests“
- Now, again check the database consistency using Eseutil /mh command as in Step 3. This time the database can be turned out in a clean state.
This was the manual way to repair Exchange database dirty shutdown using the in-built ESEUTIL application provided by Microsoft. However, if you do not achieve the desired results using the manual technique or find the aforementioned technique an arduous task, then try using a reliable Exchange Server recovery tool. It is a result-oriented yet friendly-working Exchange data recovery tool to repair corrupt EDB and STM files within a matter of minutes.
Conclusion
Users can successfully bring the database to a clean shutdown state by following these efficient methods. Using Kernel for Exchange Server recovery tool can help you repair corrupt exchange database files and is capable enough to restore the recovered files to various platforms like live Exchange Server, Outlook, Office365, email server, or webmails in a single attempt. You can also use it to store data backup to PST files ensuring that there is no data loss throughout the process.