JET error -1018 and ESE event 474: page checksum corruption in an Exchange database

Error -1018 is the one Exchange administrators learn to take seriously: the database engine read a page back from disk and its checksum no longer matched what was written. In almost every case Exchange didn't damage that page — something underneath it did. In this post I'll explain what the error means, how a database availability group (DAG) often repairs it on its own, and how to reseed, restore and track down the storage fault so it doesn't come back.

Symptoms#

The Application log on the Mailbox server shows Event ID 474 (ESE), an error in task category Database Page Cache, similar to this (values shortened; the sentence that lists the two checksum values is worded differently between ESE versions, so it's left out):

The database page read from the file "D:\DB01\DB01.edb" at offset ... (database page ...) for 32768 (0x00008000) bytes failed verification due to a page checksum mismatch. ... The read operation will fail with error -1018 (0xfffffc06). If this condition persists then please restore the database from a previous backup. This problem is likely due to faulty hardware. ...

Related messages you may see alongside it:

• Event ID 476 (ESE), failed verification because it contains no page data — error -1019 (JET_errPageNotInitialized): a page that should be in use is blank.
• Error -1022 (JET_errDiskIO): Windows itself returned an I/O error for the file.
• In a DAG, ExchangeStoreDB events such as Page patching was initiated to restore the page. (event 129), followed by one saying the copy encountered an error that it was able to repair (event 130).
• Backups that fail while verifying the database, or specific items and folders that won't open.

Why it happens#

ESE stores a checksum in every database page when it writes it and recalculates it every time it reads the page back. A mismatch means the bytes changed after ESE handed them to Windows: a write that only partly completed, a write that landed in the wrong place, or data damaged at rest or on its way to or from the disk. That's why -1018 is classically a storage-layer problem — disks, RAID or HBA controllers and their firmware, write caches without power protection, SAN paths and multipathing, hypervisor storage, or filter drivers (antivirus, backup agents) touching the database files. Software bugs are possible but much rarer.

Two features change how alarming this is in modern Exchange:

• Background database maintenance reads and checksums pages continuously, so a damaged page is often found before any user opens the item on it.
• Page patching, introduced in Exchange 2010, repairs single pages from another database copy. For the active copy, a request travels through the log stream and a passive copy returns a good version of the page; for a passive copy, log replay pauses while the page is fetched from the active copy. It needs a healthy copy, so standalone servers don't benefit.

How to fix it#

1. Measure the scope#

Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='ESE'; Id=474,476} -MaxEvents 50 |
  Format-Table TimeCreated, Id, Message -Wrap
Get-WinEvent -FilterHashtable @{LogName='System'; Level=1,2,3; StartTime=(Get-Date).AddDays(-14)} |
  Where-Object ProviderName -match 'disk|stor|ntfs' | Format-Table TimeCreated, ProviderName, Id -AutoSize

One event for one page that page patching then fixed is a warning. Repeated events, several databases on the same volume, or disk, controller and NTFS errors in the System log mean the storage is failing.

2. DAG: move the active copy and reseed the damaged one#

Get-MailboxDatabaseCopyStatus DB01\* | Format-Table Name, Status, CopyQueueLength, ReplayQueueLength, ContentIndexState
Move-ActiveMailboxDatabase DB01 -ActivateOnServer EX02

Activate a copy that sits on healthy storage, then fix the hardware behind the bad copy before you put data back on it. Reseed from a known-good copy, never from the one reporting the errors:

Suspend-MailboxDatabaseCopy DB01\EX01 -Confirm:$false
Update-MailboxDatabaseCopy DB01\EX01 -SourceServer EX03 -DeleteExistingFiles

Watch progress with Get-MailboxDatabaseCopyStatus DB01\EX01 until the copy reports Healthy.

3. Standalone server: restore, or move the data off#

1. In a maintenance window, dismount the database and confirm the damage with eseutil /k "D:\DB01\DB01.edb", which verifies the checksum of every page.
2. Restore the database from the last good Exchange-aware backup and let ESE replay the logs written since. Replay reapplies every change made after the backup, so with an unbroken log chain you end up with current data and no damaged page.
3. If no usable backup exists, create a new database on healthy storage and move the mailboxes into it with New-MoveRequest. Items stored on a damaged page can't be copied, so some moves may need a higher -BadItemLimit.
4. Use eseutil /p only if the database won't stay mounted at all. It discards damaged pages; follow the hard-repair steps and support caveats in Exchange database won't mount.

4. Fix the storage#

• Run the hardware vendor's diagnostics for disks, controllers and cache.
• Bring controller, HBA, disk and SAN firmware and drivers to versions your vendor supports, and check that write caching is battery- or flash-backed.
• On virtual machines, check datastore and host storage health, and don't take hypervisor checkpoints of Exchange VMs.
• Make sure antivirus excludes the database and log folders and that no file-level backup agent opens the .edb files.

Verify the fix#

• No new ESE 474 or 476 events for the database over the following weeks, while background maintenance keeps scanning every page.
• In a DAG, Get-MailboxDatabaseCopyStatus DB01\* shows one Mounted copy and the others Healthy with low queue lengths, and Test-ReplicationHealth passes on each member.
• On a standalone server, eseutil /k on the restored or new database reports no bad checksums before you mount it.
• The next full backup completes.

Key takeaways#

• Treat -1018 as a storage alarm, even when page patching fixed it silently.
• Keep at least two copies of every database on independent storage; page patching and reseeding both depend on a healthy copy.
• Alert on ESE events 474 and 476 and on disk and controller errors in the System log.
• Keep firmware and drivers current, and run the Exchange Server Health Checker regularly to catch configuration drift.

References#

• Manage mailbox database copies (Microsoft Learn)
• Extensible Storage Engine error codes (Microsoft Learn)