Exchange Server is an email-based communication server used in conjunction with MS Outlook by most organizations to maintain smooth and efficient business communication. Exchange also offers great ease and flexibility to the users to access their mailbox information either using Outlook or Outlook Web Access, suiting as per their needs and conveniences.
In order to save the user mailbox information, MS Exchange information store relies upon Exchange database files (EDB) and keep them as a backup repository in case the user accidently deletes the emails or mailbox content.
Unfortunately, EDB files of Information Store is vulnerable to corruption as well, like any other database files. Exchange dirty shutdown is one such corruption error that you may encounter due to an abrupt termination of Information Store.
In such a scenario, the user is displayed an error message indicating:
What is dirty shutdown error?
Exchange Server database is designed on JET engines, in which log files are given a significant role to keep a constant record of input and output operations going 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. And in this incomplete process, if the system is turn off accidently, it displays dirty shutdown error.
Reason for Dirty Shutdown State
The main reason for dirty shutdown is caused due to 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 create transactional discrepancy. And in this situation, when the user tries to open the EDB files, it displays the dirty shutdown error.
Note: A transaction log file is a highly important piece of information for database as it consistently keeps a track of all changes made in the exchange database. And 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 helping users to understand the complete log history.
Verify a clean or dirty shutdown state
You may verify whether the database is properly detached from transaction files or not, in order to check it is a clean or dirty shutdown state. 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 is this path: ‘c:\program files\exchsrvr\mdbdata folder’
Now, type the given command, for private folder:
Type the given command, for public folder:
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
In order to resolve the issue of dirty shutdown error, it is required to bring the database back into a clean shutdown state. For this, transactional log files have to be replayed in the database. Follow the below mentioned steps to achieve 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 repairing process.
- Use Eseutil, an inbuilt repair utility of Exchange Server to check the consistency of the database.
- 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 it is still found in an inconsistent state, then use the following command to perform hard repair on corrupt EDB files:eseutil/p “C:\ program files\ exchsrvr\ mdbdata\ priv1.edb”
- Defrag the database store by running this command “Eseutil/d” on the utility.
- Lastly, check the integrity of the database by using another utility “Isinteg”. Now run this command line : “Isinteg –s servername –fix –test alltests”
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 third-party Exchange Server recovery tool. Kernel for Exchange Server is a result-oriented yet friendly-working tool to repair corrupt EDB and STM files within a matter of minutes. In three simple steps, users can successfully bring the database to error-free clean shutdown state. Other than dirty shutdown error, this tool can solely repair EDB files from all corruption conditions and capable enough to restore the recovered files to various platforms like Outlook, Office365, email server or web mails in a single attempt.