Interactive Troubleshooter

Published: Sep 7, 2026

Updated: Sep 7, 2026

Interactive: Exchange Database Mount Failed: ESEUTIL Guide

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

An interactive root-cause diagnostic tree to resolve Exchange database mount failures, dirty shutdown states, and corrupted transaction logs using ESEUTIL commands.

Full Diagnostic Tree & Step-by-Step Overview

What specific error code or database state appears when attempting to mount the Exchange database via PowerShell or EAC?

Error MapiExceptionJetErrorDatabaseDirtyShutdown (-550) or similar ESE JET database errors.
Error specifying missing transaction logs, damaged log files, or log generation sequence mismatch.
Access Denied, NTFS permission revocation, or storage volume dismounts due to low disk space.
Database corruption requiring advanced repair syntax or circular logging inspection.

What database header status is displayed when inspecting the ESEUTIL file metadata?

Header shows 'Dirty Shutdown' state due to unexpected power loss or Information Store crash.
Header shows 'Clean Shutdown', but the database still fails to mount due to version incompatibility.
Header inspection fails entirely with error -1216 (JET_errAttachedDatabaseMismatch).

Perform ESEUTIL Soft Recovery to Resolve Dirty Shutdown State

Solution:

Root Cause: Unclean Database Shutdown (Dirty Shutdown State -550)

When Exchange Server or the underlying Windows operating system shuts down abruptly without cleanly dismounting the mailbox database, the ESE database is left in a 'Dirty Shutdown' state. Transaction logs contain uncommitted changes that must be replayed into the database before it can mount successfully.

Step-by-Step Fix:

1Inspect Database Header:

Open Exchange Management Shell (EMS) as Administrator and run the header check command:

powershell
     eseutil /mh "E:\Mailbox\Mailbox Database\MailboxDatabase.edb"

Verify that the State field reads Dirty Shutdown.

2Execute Soft Recovery:

Locate the folder containing the active transaction logs (E00, E01, etc.) and checkpoint file (E00.chk).

Run soft recovery to replay valid logs into the database:

powershell
     eseutil /r E00 /l "E:\Mailbox\Mailbox Database" /d "E:\Mailbox\Mailbox Database"

3Verify Clean State and Mount:

Run eseutil /mh again to confirm the state has changed to Clean Shutdown.

Mount the database via EMS:

powershell
     Mount-Database -Identity "Mailbox Database"

Resolve Exchange Schema Version Mismatch After Cumulative Update

Solution:

Root Cause: Database Version Mismatch Following Cumulative Update (CU) Installation

A database showing 'Clean Shutdown' might still fail to mount if the Exchange binaries on the server have been updated via a Cumulative Update (CU) or Security Update (SU), but the database schema version expects a different binary build version.

Step-by-Step Fix:

1Check Exchange Service and Version Build:

Run Get-ExchangeServer | fl Name,Edition,AdminDisplayVersion to inspect installed versions.

2Review Event Viewer Logs:

Check Application logs for MSExchangeIS Event ID 499 or 500 indicating schema mismatch.

3Complete Setup Provisioning:

If a CU was partially applied, open an elevated command prompt and complete unattended setup: Setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms_DiagnosticDataON.

Fix Attached Database Mismatch and Log Stream Mismatches

Solution:

Root Cause: Attached Database Mismatch (-1216) Due to Swapped Log Paths

Error -1216 occurs when the transaction log files present in the log directory do not belong to the specific database file being mounted. This typically happens if log paths were modified or files were restored from mismatched backup snapshots.

Step-by-Step Fix:

1Verify Log Signature Matching:

Run eseutil /ml "E:\Mailbox\Mailbox Database\E00" to inspect log file signatures and verify they match the database signature.

2Move Mismatched Logs:

Create a temporary backup folder and move conflicting log files out of the active log directory.

Re-run eseutil /mh to verify compatibility before attempting to mount.

What specific transaction log error or missing file condition is reported in the Exchange logs?

Missing sequential log files required for soft recovery (e.g., gap in log generation numbers).
Corrupted checkpoint file (`E00.chk`) pointing to non-existent or deleted log generations.
Log drive completely full, preventing the Information Store from writing new transaction logs.

Handle Missing Transaction Logs Using Eseutil /p or Restore from Backup

Solution:

Root Cause: Missing Transaction Log Generation Causing Soft Recovery Failure

If transaction logs required for soft recovery have been prematurely deleted, purged, or lost due to drive failure, soft recovery (eseutil /r) will fail because it cannot find the continuous chain of log files needed to reach a consistent state.

Step-by-Step Fix:

1Evaluate Restore Options:

Recommended: Restore the database and transaction logs from a valid, recent VSS-aware application backup.

2Force Recovery with Missing Logs (Lossy Repair):

If backups are unavailable and you must force the database to mount, use hard repair (eseutil /p). Warning: Hard repair causes permanent data loss as corrupted pages are stripped out:

powershell
     eseutil /p "E:\Mailbox\Mailbox Database\MailboxDatabase.edb"

3Defragment and Mount:

Run offline defragmentation (eseutil /d) post-repair, then mount the database via Exchange Management Shell.

Recreate Corrupted Checkpoint File for Exchange Database

Solution:

Root Cause: Corrupted Checkpoint File (`.chk`) Desynchronization

The checkpoint file tracks which transaction logs have been successfully committed to the database file. If the .chk file becomes corrupted, the Exchange Information Store engine gets confused about where log replay should begin.

Step-by-Step Fix:

1Backup Existing Logs and Checkpoint:

Copy all .edb, .log, and .chk files to a secure fallback location.

2Delete Corrupted Checkpoint File:

Remove the active E00.chk file from the log directory.

3Run Soft Recovery to Rebuild Checkpoint:

Execute soft recovery so Exchange automatically recreates a clean checkpoint file based on available logs:

powershell
     eseutil /r E00 /l "E:\Mailbox\Mailbox Database"

Free Log Disk Space and Enable Circular Logging

Solution:

Root Cause: Log Drive Storage Exhaustion Halting Database Writes

When the disk drive hosting Exchange transaction logs runs completely out of free space, the Microsoft Exchange Information Store service immediately dismounts all associated databases to prevent database corruption from unwritten transactions.

Step-by-Step Fix:

1Free Up Disk Space:

Safely move older transaction log files or backup files to an auxiliary volume to immediately free up space on the log drive.

2Enable Circular Logging (If Applicable):

If space constraints are chronic and passive database copies exist (DAG environment), enable circular logging via EMS:

powershell
     Set-MailboxDatabase -Identity "Mailbox Database" -CircularLoggingEnabled $true

Mount the database once storage headroom is restored: Mount-Database -Identity "Mailbox Database".

What permission, service, or storage infrastructure issue is observed when checking mount failure dependencies?

Exchange Trusted Subsystem or local system accounts lack NTFS Read/Write permissions on database and log folders.
Microsoft Exchange Information Store service fails to start or crashes immediately upon startup.
SAN storage paths, cluster quorum disks, or CSV (Cluster Shared Volumes) offline states block access.

Restore Correct NTFS Permissions for Exchange Trusted Subsystem

Solution:

Root Cause: Missing NTFS Permissions on Database and Log Directories

Exchange databases require strict permission inheritance. If permissions on the database .edb folder or transaction log directory are modified, the Exchange Trusted Subsystem or SYSTEM accounts lose access, preventing the Information Store from opening and mounting the database.

Step-by-Step Fix:

1Grant Permissions via PowerShell or File Properties:

Open PowerShell as Administrator and grant full control to the Exchange Trusted Subsystem:

powershell
     $Acl = Get-Acl "E:\Mailbox\Mailbox Database"
     $Permission = "Exchange Trusted Subsystem", "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow"
     $Acl.AddAccessRule($Permission)
     Set-Acl "E:\Mailbox\Mailbox Database" $Acl

2Verify SYSTEM and Administrators Access:

Ensure NT AUTHORITY\SYSTEM and local Administrators also retain Full Control permissions on both database and log folders.

Troubleshoot Microsoft Exchange Information Store Service Startup Failures

Solution:

Root Cause: Corrupted Information Store Registry Keys or Stuck Dependency Services

If the Microsoft Exchange Information Store service (MSExchangeIS) crashes or fails to start, no databases can mount. This is often caused by hanging RPC dependencies, corrupted registry configurations, or third-party filter driver conflicts.

Step-by-Step Fix:

1Restart Dependent Services:

Restart Windows Remote Management, Active Directory Topology Service, and Transport services in proper sequence.

2Check Event Logs for Crash Signatures:

Open Event Viewer and examine Application logs for Event ID 1000 (Application Error) pointing to Store.exe.

3Run Microsoft Official Support Guide diagnostics or rebuild performance counters using lodctr /r if store counters are corrupted.

Repair Cluster Shared Volumes and SAN Storage Mount Points

Solution:

Root Cause: Failover Cluster Disk Resource Offline State or CSV Lock

In Exchange Database Availability Group (DAG) or clustered environments, if the underlying Cluster Shared Volume (CSV) or SAN LUN goes offline or encounters a SCSI reservation conflict, the database files become inaccessible, resulting in forced dismounts.

Step-by-Step Fix:

1Check Failover Cluster Status:

Open Failover Cluster Manager (cluadmin.msc) and verify that the disk resource hosting the database is online.

2Rescan Storage Disks:

Open Disk Management (diskmgmt.msc) on the host server and click Rescan Disks to refresh SAN storage paths.

3Bring Cluster Resource Online:

Bring the specific disk and Exchange database cluster role back online, then mount the database via Exchange Management Shell.

What advanced corruption or database structural repair scenario must be addressed?

Severe B-tree or page-level corruption requires running Eseutil hard repair (`eseutil /p`).
Insufficient free disk space for running Eseutil defragmentation or repair operations.
Complete database rebuild and mailbox restoration required from DAG passive copies or backups.

Execute Eseutil Hard Repair and Defragmentation

Solution:

Root Cause: Severe B-Tree Structure Corruption in Mailbox Database

When software bugs, failing storage blocks, or memory faults corrupt the internal ESE B-tree structure, soft recovery fails completely. Eseutil hard repair (eseutil /p) is required to rebuild corrupted database tables by discarding damaged pages.

Step-by-Step Fix:

1Perform Hard Repair:

Execute the hard repair command in EMS (acknowledge data loss warnings):

powershell
     eseutil /p "E:\Mailbox\Mailbox Database\MailboxDatabase.edb"

2Defragment Database to Reclaim Space:

Run offline defragmentation to rebuild the database structure and compact free pages:

powershell
     eseutil /d "E:\Mailbox\Mailbox Database\MailboxDatabase.edb" /t "E:\Mailbox\TempDefrag.edb"

3Integrity Check and Mount:

Run eseutil /g to verify database integrity, then mount via Mount-Database.

Provision Temporary Scratch Volume for Eseutil Operations

Solution:

Root Cause: Lack of Free Disk Space on Staging Volume During Eseutil Repair/Defrag

Running Eseutil repair (/p) or offline defragmentation (/d) requires free disk space equal to 110% to 120% of the total database size on the scratch volume. If free space is insufficient, the utility aborts with error -1808 (JET_errDiskFull).

Step-by-Step Fix:

1Attach External Temporary Volume:

Provision and attach a temporary scratch disk with sufficient free capacity.

2Specify Temporary Path in Command:

Run defragmentation or repair pointing explicitly to the temporary scratch drive:

powershell
     eseutil /d "E:\Mailbox\Mailbox Database\MailboxDatabase.edb" /t "F:\TempScratch\Defrag.edb"

3Clean Up Scratch Files:

Once complete, verify mounting and safely remove temporary scratch files.

Reseed Database from DAG Passive Copy or Backup

Solution:

Root Cause: Irreparable Database Damage Requiring DAG Reseeding

If a database has suffered catastrophic structural damage and hard repair leaves it unusable, the fastest and cleanest enterprise recovery method in an Exchange Database Availability Group (DAG) is reseeding the database from a healthy passive copy.

Step-by-Step Fix:

1Suspend Failed Database Copy:

Run Suspend-MailboxDatabaseCopy -Identity "Mailbox Database\ExServer02".

2Reseed from Active Source:

Execute the reseed command in EMS to copy healthy database files from a replication partner:

powershell
     Update-MailboxDatabaseCopy -Identity "Mailbox Database\ExServer02" -SafeToDeleteExistingFiles

3Resume Copy and Verify Health:

Run Resume-MailboxDatabaseCopy and confirm synchronization status via Get-MailboxDatabaseCopyStatus.

Related Diagnostic Guides

Windows Update Error 0x80070002 Missing Files Diagnostic Guide

System Restore Failed 0x80070005 Antivirus Conflict Tree

Windows Photo Viewer Not Showing Thumbnails: Codec Diagnostic

Safe Mode Password Not Working With Microsoft Account Fix

Clipboard History Not Working Windows 11: Sync Service Tree

Subscribe to StepDiag

Embed Guide on Your Website