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 the Exchange database (.edb file). The most common reason why Exchange Server goes into an inconsistent or Dirty Shutdown state is that transaction logs are not being committed to the Exchange database. This can happen due to several reasons, 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 in providing easy access to the data and save databases from unexpected corruption.
Causes of Exchange Database Dirty Shutdown
Dirty Shutdown in Exchange database can happen due to several factors. The following are some of the scenarios that can lead to the error:
- When the computer system does not shut down properly multiple times, then it may result in a dirty shutdown problem.
- A severe malware, spyware, or trojan attack on the database may corrupt the database, causing a dirty state problem. To resolve it, you must repair EDB files.
- A hacking attempt on the database may also cause errors including a dirty shutdown problem.
- If the user turns off the computer unexpectedly during an ongoing process or there is an abrupt system shutdown, the dirty shutdown error can occur.
In such a scenario, the user gets an error message indicating:
Some other situations may show the following types of errors:
“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 occurring within the EDB files. But when these log files are left in the cached memory without being committed to the Information Store, then the JET engine terms them as DIRTY. Moreover, if in this incomplete process, the system is turned off accidentally, it displays a dirty shutdown error. If the database is down, inconsistent, or is in an unhealthy state, it cannot be mounted on the server. This results in the inaccessibility of user mailboxes that are stored in the database (facing an issue).
The main reason for an Exchange database dirty shutdown is the inconsistency in transactions log files. The database goes into 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 a 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 to those user mailboxes are first registered in these log files and then in 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 if it is a clean or dirty shutdown. To analyze the state of database, follow the steps below:
- Go to the ‘Start’ button and then type ‘cmd’ in the run textbox and hit enter.
- In the command prompt, go to the directory where eseutil is and run this command
eseutil /mh “complete folder path of your edb file”
After running the command, you will get an output like shown in the image below:
Verify the exchange database state, as:
- State: Clean Shutdown means your database is in OK condition. Nothing is damaged. You can mount it to the server.
- State: Dirty Shutdown means your EDB file is damaged. You cannot mount it unless you change the state to Clean Shutdown.
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, transaction log files have to be re-committed to 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.
Before you perform any operation on the database file, we recommend that you take a complete database backup. Since your EDB file is in “Dirty Shutdown” state, you will not be able to use a native procedure for backup. So, copy and paste the offline EDB file and log files to another folder.
Follow the below mentioned steps to fix Exchange dirty shutdown issue and return the database to a clean shutdown state:
- Keep a backup of the 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”
Note: My EDB file is stored at the default location, that is “C:\ program files\ exchsrvr\ mdbdata\ priv1.edb”. If your EDB file location is different, then change the path in the command before running it. - 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“
Note:The hard recovery command will erase all the corrupt pages from the database. - Defragment the database to remove empty disk space within it by running this command “Eseutil/ d”
- Lastly, check the integrity of the database by using another utility, “Isinteg”. with the following command:
Isinteg –s servername –fix –test alltests“
- Now, again, check the database consistency using Eseutil /mh command:
Eseutil/mh “C:\ program files\ exchsrvr\ mdbdata\ priv1.edb”
This time, the database state will be “Clean Shutdown”. Now you can mount it on the server.
The above method is free but comes with a price. When you use the /p (hard recovery) switch for the repair, it causes permanent data loss. Therefore, only use hard recovery when it is the only way or if you are not worried about losing emails.
However, when you cannot afford to lose even a single email, you must use a professional Exchange recovery tool. A professional tool helps you to safely recover your emails, attachments, contacts, and other mailbox items without causing data loss.
A reliable tool to remove corruption from an EDB file is Kernel for Exchange Server. I have been using this tool for many years now, and it has saved my database multiple times from failures. Additionally, after data recovery, you can either save data locally in PST files or migrate recovered mailboxes from EDB to Live Exchange or Office 365.
Conclusion
Users can successfully bring the database to a clean shutdown state using the eseutil tool. But in case of severe corruption, you will have to use the hard recovery option. But that will result in data loss. To recover all the user’s mailboxes from EDB files, use Kernel for Exchange Server. This tool is designed specially to repair corrupt Exchange database files and recover all user mailboxes without losing any data.
Frequently Asked Questions
Ans. This error indicates that the Exchange Server fails to access the location where your EDB file is stored. In such a situation, users get the error 0xFFFFFC01 JET_errInvalidPath. You can fix it by correcting the EDB file path. But if the culprit is a damaged header in EDB, use the eseutil tool to fix it.
Ans.
1. Store databases in isolated locations.
2. Use premium anti-virus programs that also offer online protection.
3. Prevent abrupt server shutdown and power failures.
4. Monitor disk space and health of log files periodically.
