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.
To resolve dirty shutdown error, try an automated tool Kernel for Exchange Server recovery. The tool also enables you to migrate corrupt Exchange mailbox data into Live Exchange and Office 365.
In such a scenario, the user is displayed an error message indicating:
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 accidentally, it displays dirty shutdown error.
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.
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 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:
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.
Proposed by Mr Ahmed MALEK, Senior IT Security Manager at INSEAD(MCC, MVP)
Read more : https://social.technet.microsoft.com/Forums/office/en-US/45ea5440-728a-442e-949f-8d330abea079/exchange-edb-corrupt