Exchange Database Won't Mount After Shutdown: The Complete Diagnostic Flowchart (JET -1018, -1022, 528, 548)

Quick Answer: In over 90% of cases, an Exchange database won't mount because of one of four JET (Joint Engine Technology) errors triggered by a dirty shutdown: -1018 (page checksum mismatch), -1022 (disk I/O failure), 528 (missing log file), or 548 (log file mismatch). Each error points to a different failure layer and requires a different recovery path. Running eseutil /p without diagnosing the exact error first is the most common reason recovery attempts destroy data instead of saving it.

---

Why Exchange Databases Fail to Mount: The Core Mechanic

Microsoft Exchange Server stores all mailbox data in an ESE (Extensible Storage Engine) database — the .edb file. Every write to the database is first recorded in a transaction log (.log file) before it's committed to the EDB. This two-phase write process ensures data integrity under normal conditions.

When Exchange doesn't shut down cleanly — due to a power failure, Windows crash, storage disconnect, or forced process kill — the database enters a dirty shutdown state. In this state, the ESE cannot verify that the in-memory cache was fully flushed to disk, and the database is flagged as inconsistent.

Exchange's Information Store service will refuse to mount any database flagged as dirty. This is a protection mechanism, not a bug.

The four JET errors below are how Exchange tells you what specifically went wrong during that inconsistent shutdown.

---

JET Error -1018: Page Checksum Mismatch (JET_errReadVerifyFailure)

What It Means

JET error -1018 is the most common Exchange database corruption error. It occurs when Exchange reads a database page and the checksum stored in that page's header does not match the checksum of the actual data read from disk.

Every 4 KB page in an Exchange EDB file has a checksum recorded when it was last written. If that checksum doesn't validate on read, it means the page was either:

• Written incompletely (partial write during a crash)
• Corrupted at the storage layer (bad disk sector, RAID rebuild error, or VM snapshot issue)
• Modified outside of Exchange (improper backup tool, AV scanning, or disk utility)

How to Diagnose JET -1018

Run an integrity check on the dismounted database:

eseutil /g "C:\Program Files\Server15\DB\Name\DBName.edb"

If the output reports Database is CORRUPT or lists page-level errors, JET -1018 is confirmed.

Recovery Options for JET -1018

Method	Data Loss Risk	Recommended When
Restore from verified backup	None	Clean backup exists and is current
eseutil /p (hard repair)	High — purges corrupt pages and their mailbox items	No backup; pages are few and isolated
Third-party EDB repair tool	Low — repairs structure, preserves mailbox data	No backup; widespread corruption or critical mailboxes

⚠️ Critical Warning: eseutil /p resolves the checksum error by deleting the affected pages — meaning any mailbox items stored on those pages are permanently gone. Microsoft's own documentation states that eseutil /p should be a last resort and that the resulting database should be treated as suspect.

---

JET Error -1022: Disk I/O Failure (JET_errDiskIO)

What It Means

JET error -1022 indicates that Exchange could not read from or write to the physical disk where the EDB file resides. Unlike -1018 (a data integrity problem), -1022 is an infrastructure problem — Exchange is reaching for the data but the storage layer isn't responding.

Common causes include:

• Failed or failing hard disk/SSD (check SMART status immediately)
• Disconnected or timed-out SAN/NAS volume
• RAID controller failure or degraded RAID array
• VM storage misconfiguration (especially VMware snapshot chains or thin-provisioned disks reaching capacity)
• Disk I/O queue saturation under extreme load

How to Diagnose JET -1022

1. Check Windows Event Viewer > System log for disk error events (Event IDs 7, 11, 51)
2. Run chkdsk /f /r on the volume hosting the EDB after dismounting Exchange
3. Check SMART data via wmic diskdrive get status or a tool like CrystalDiskInfo
4. If on a SAN, verify connectivity, LUN availability, and multipath status

Recovery Options for JET -1022

⛔ Do not attempt eseutil on a disk with active I/O errors. The risk of compounding corruption is extreme.

The correct sequence:

1. Identify and fix the storage-layer problem first (replace disk, reconnect volume, fix RAID)
2. Copy the EDB and log files to a healthy volume
3. Run eseutil /mh on the copied EDB to check database state
4. Proceed with soft or hard recovery on the healthy copy

If the disk has physically failed and no backup exists, the EDB must be recovered using a forensic-level tool capable of reading partially damaged files — one that can parse an EDB even when standard ESE access methods fail.

---

Exchange Error 528: Missing Transaction Log File (JET_errMissingLogFile)

What It Means

Error 528 means Exchange cannot find a required transaction log file needed to replay committed transactions and bring the database to a consistent state.

Exchange uses a sequential log chain. Each log file (e.g., E00.log, E0000001.log, E0000002.log) must be present and intact for the database to reach a clean shutdown state. If any log in the required sequence is missing, Exchange refuses to mount.

This most commonly happens when:

• Circular logging was enabled — Exchange overwrites old logs, destroying the replay chain
• Logs were manually deleted to free disk space
• Antivirus quarantined a log file (flagging it incorrectly)
• A log file was on a separate volume that failed or was wiped
• Backup software deleted logs after a failed backup job

How to Diagnose Error 528

Run:

eseutil /mh "C:\...\DBName.edb"

Look for the Log Required range in the output (e.g., Log Required: 1-5 (0x1-0x5)). Then check which log files actually exist in the log directory. The gap between what's required and what exists confirms missing logs.

Recovery Options for Error 528

Scenario	Recovery Path
Logs missing but backup exists with matching log chain	Restore from backup, replay logs
Circular logging was ON and no backup exists	Cannot do soft recovery. Must use eseutil /p or third-party tool — data loss is likely
Single log missing, rest intact	Attempt hard recovery, then use a third-party tool to extract maximum mailbox content

⚠️ Circular logging + Error 528 = worst-case scenario. When circular logging is enabled and a crash occurs, point-in-time recovery is impossible without a full backup. This is why Microsoft recommends disabling circular logging for all production databases.

---

Exchange Error 548: Log File Mismatch (JET_errBadLogSignature)

What It Means

Error 548 indicates that a log file exists but its internal signature does not match the signature of the database it's supposed to belong to.

Exchange maintains a signature in both the EDB header and each log file to ensure they belong to the same database instance. A signature mismatch occurs when:

• Log files from a different database or a previous database instance are in the log directory
• The database was restored from backup but old log files were not cleared
• A database was moved or renamed without clearing the log path
• An incomplete database copy was mounted alongside mismatched logs (common in DAG misconfigurations)

How to Diagnose Error 548

Run eseutil /ml <logfile> on the first log in the sequence and compare its lGeneration and signature field against the EDB header output from eseutil /mh. If the signatures differ, the logs don't belong to this database.

Recovery Options for Error 548

This error is often more recoverable than -1018 or 528, because the database itself may be intact.

1. Clear the log directory (move all logs to a backup folder — do not delete them yet)
2. Run eseutil /p on the EDB to perform hard repair from the database alone
3. Run eseutil /d to defragment and rebuild the database structure
4. If this fails, use a third-party EDB repair tool to read the EDB directly without relying on the log chain

---

The Diagnostic Flowchart: Which Error Do You Have?

Exchange database won't mount
         |
         v
Run: eseutil /mh database.edb
         |
    Dirty Shutdown?
   /              \
 YES               NO
  |                |
  |         Different issue (quota,
  |         permissions, service)
  |
  v
Check Windows Event Viewer
for specific JET error code
    |
    |---------|---------|----------|
  -1018    -1022      528        548
    |        |         |          |
  Page    Disk IO   Missing    Log file
 corrupt   error    log file   mismatch
    |        |         |          |
 Fix:    Fix        Restore   Clear log
 eseutil  storage   from      directory,
 /p or    layer     backup    then hard
 3rd      first,    or hard   repair or
 party    then      repair    3rd party
 tool     copy EDB  or 3rd    tool
          to new    party
          volume,   tool
          then
          repair

---

When eseutil Isn't Enough: What Native Tools Can't Do

eseutil is Microsoft's built-in database repair utility and the default answer across most IT forums. However, it has documented limitations that admins discover — usually at the worst possible time:

1. eseutil /p causes data loss by design. It repairs the database structure by purging corrupt pages. Any mailbox items stored on those pages are permanently deleted. Microsoft explicitly advises against using this as a primary recovery strategy.

2. eseutil cannot recover from physical disk failure. If the EDB is stored on a dead disk, eseutil cannot access it at all.

3. eseutil requires the log chain. Without a clean log sequence, soft recovery (eseutil /r) will not work, leaving only the destructive /p option.

4. eseutil does not enable granular recovery. You cannot use it to extract specific mailboxes or items. It's all-or-nothing at the database level.

5. After eseutil /p, the database is not trusted. Microsoft's own guidance states the resulting database should be treated as potentially inconsistent and should not be used as a long-term production store.

---

Prevention: How to Stop This from Happening Again

Action	What It Prevents
Disable circular logging on all production databases	Error 528 scenarios after crash
Use UPS (Uninterruptible Power Supply) for Exchange servers	Dirty shutdown from power failure
Monitor disk health proactively (SMART, disk I/O alerts)	JET -1022 from disk degradation
Verify backups weekly with test restores	Ensures recovery path exists before you need it
Separate EDB and log files onto different volumes	Prevents a single disk failure from wiping both
Configure DAG (Database Availability Groups) for HA	Eliminates single point of failure at DB level

---

Summary: JET Errors at a Glance

Error Code	Cause	Native Fix	Data Loss Risk
JET_errReadVerifyFailure (-1018)	Corrupt EDB page	eseutil /p	High
JET_errDiskIO (-1022)	Disk/storage failure	Fix storage, then repair	High if disk is dead
JET_errMissingLogFile (528)	Missing transaction log	Restore backup	High if circular logging was ON
JET_errBadLogSignature (548)	Log/DB signature mismatch	Clear logs, hard repair	Low to Medium

---

Final Thought

Exchange database failures are not rare events — they are an expected operational risk in any on-premises mail infrastructure. The admins who recover fastest are not the ones who know the most eseutil flags — they are the ones who diagnose the specific error first and match it to the right recovery method.

Reaching for eseutil /p before understanding the error code is the most expensive mistake in Exchange recovery. It trades a repairable problem for a permanent one.

The flowchart above gives you the diagnostic structure. The tool you use at the end of it determines whether your users get their mailboxes back intact.