In an Exchange Server system, corruption may creep into your database anytime due to several hardware or firmware-related issues. Oftentimes, there are problems within the storage subsystem caused by firmware upgrades, controller issues, memory upgrades or failures, and the like.
These problems introduce page-level damage into the Exchange database files (EDB). This may lead to a checksum mismatch during a page read operation and subsequently record Event ID 474 in the application log of the Event Viewer:

‘Event ID: 474
IInformation store "2680" the database page read from the file "~\mdbdata\priv1.edb" at offset 4050944 (0x00000000003dd000) for 4096 (0x00001000) bytes failed verification due to a page checksum mismatch.’

At this stage, you may not be able to start the Exchange Message Transfer Agent (MTA) service on your Exchange Server computer.

What Does Exchange Server Event ID 474 Indicates?

The Event ID 474 is recorded when the reference to the Exchange mailbox database page is corrupt or damaged. It indicates that a problem in the storage media, such as the hard-disk subsystem, has caused damage to your Exchange database.

Event ID 474 is also referred to as error code 1018—Page Checksum Mismatch. The event or Page Checksum Mismatch error may also occur due to firmware malfunction.

When the error occurs, it can lead to the following issues,

  • Users can’t send or receive emails
  • Outlook may not start or display an error
  • Backups are interrupted/do not finish
Methods to Resolve Page Checksum Mismatch Error- ESE Event ID 474

To rectify this problem and bring your database back to a consistent state, follow these methods.

Method 1: Move Mailboxes

If you have encountered the Page Checksum Mismatch error or Event ID 474, move all the mailboxes from your current server databases to a new server. You can use the Exchange Admin Center (EAC) or Exchange Management Shell (EMS) in Exchange 2010 or later versions and Exchange Management Console in earlier versions to move the mailbox database. However, these tools will work only when the database is mounted. After moving all user mailboxes to a second Exchange Server, dismount the mailbox store and follow these steps to restore the damaged database.

Step 1: Backup Transaction Logs
To ensure transactional consistency in your database, you should copy all transactional log files to a safe location. This would enable you to replay mail messages even if the backup program overwrites these files during the restore operation.

Step 2: Check the Defect
Identify the root cause of the problem by checking your firmware compatibility or detecting the defective device in your hard-disk subsystem. You should also verify the file system for corruption. Try to determine and diagnose the problem quickly.

Step 3: Restore the Database
Use backup software to restore your database from a backup. Ensure that the backup program does not mount the database after the restore operation.

Step 4: Copy the Transaction Logs
The previous operation may result in overwriting the transaction log files. In this case, you can copy the transaction log files from the location where you previously saved them to the ‘Mdbdata’ folder.

Step 5: Mount the Database
Try to remount your mailbox store.

Method 2: Use EseUtil

Extensible Storage Engine Utilities or EseUtil is a built-in command-line-based tool that you may use to repair a corrupt database. You must perform Hard Recovery using EseUtil /p switch, as Soft Recovery won’t work on such a corrupt database with page-level corruption.

Eseutil /p <PathToDatabase.edb>

However, hard recovery recovers the database by purging irrecoverable mailboxes (damaged pages) and mail items that can lead to data loss. Thus, proceed at your own risk.

Additionally, you also need to defragment the repaired mailbox database to remove white spaces left behind by purged data before mounting.

ESEUTIL /D <database_name> /T <LOCAL_path> or <UNC_path>

After the defragmentation, execute the following cmdlet to mount the repaired database.

Mount-Database –Identity <DatabaseName>

If the database doesn’t mount or you do not want to risk your data with Hard Recovery, we recommend installing and using Exchange recovery software, such as Stellar Repair for Exchange.

Unlike EseUtil, the software is GUI-based and helps administrators recover mailboxes and mail items from damaged or corrupt Exchange databases (EDB) to PST format with complete integrity and consistency.

You may also export the recovered mailboxes and mail items, such as messages, contacts, notes, tasks, calendar entries, and journal records, from a corrupt database directly to another Exchange Server database or Office 365 tenant.


Page Checksum Mismatch error or Event ID 474 issue arises due to bad disk subsystem or issues with your storage drive/firmware malfunction. The error is also linked to Jet engine database error—1018 or Jet_errReadVerifyFailure—indicating a corrupt or damaged database at the page level. In such a case, you can diagnose the storage media for issues and backup immediately. However, if the server or database is down and you can’t back up, use EseUtil to perform hard recovery to recover the damaged database.

Although hard recovery can lead to data loss as it purges irrecoverable mail items, it may fix the database, which you can mount to restore mailbox services. You may also use Exchange recovery software, such as Stellar Exchange Mailbox Recovery Tool, to recover mailboxes from corrupt or damaged databases. Unlike EseUtil, the software does not purge data and recovers all mail items with complete integrity and consistency. With parallel processing, the software helps you extract and save mailboxes from repaired database to PST or export to office 365 or Live Exchange at 4x speed—minimizes the downtime.

Buy Now
Why Choose Stellar?
Easy to Use


Future Ready


24X5 Supports


Money Back


Most Awarded


Reliable & Secure