Error -550 dirty shutdown: Exchange will not mount a database missing its logs

Fix it now

Microsoft publishes -550 as JET_errDatabaseDirtyShutdown: the database was not shut down cleanly, and recovery must be run first. That is expected after a crash and is not damage. The trouble starts when the logs recovery needs are missing, which is what -543 and -528 are telling you.

Get-MailboxDatabase -Status | Format-List Name,Mounted,EdbFilePath,LogFolderPath
Get-MailboxDatabaseCopyStatus * | Format-Table Name,Status,CopyQueueLength,ReplayQueueLength

1. Copy the database file, the whole log folder and the checkpoint file to separate storage before running anything against them.
2. If the database has a healthy copy in a DAG, stop here and use it: activate the healthy copy, then suspend and reseed the damaged one with Update-MailboxDatabaseCopy. That is the documented route and it returns all the data.
3. With no copy, establish whether every required log generation is present in the log folder, with the same log prefix the database expects.
4. If they are all there, run a soft recovery with the engine utility, then mount with Mount-Database DB01.
5. If any generation is missing, stop. Restore from backup. Recovery cannot invent a log that does not exist, and a hard repair is not the answer to a missing one.

Microsoft requires a copy to be suspended before Update-MailboxDatabaseCopy will run, and -DeleteExistingFiles removes only the log files it checks for: it fails if other files are present.

If the database mounts and stays mounted, you are done. If recovery will not complete, the next section explains exactly what the engine is refusing and why.

Why it happens

The database engine writes ahead to the transaction log. A change is committed to the log first and written into the database file lazily afterwards, sometimes much later. A clean shutdown means every committed change was flushed into the file and the database needs no log at all. A dirty shutdown means it still does. Microsoft’s wording for -550 is that the database was not shut down cleanly, and that a recovery must first be run to properly complete database operations for the previous shutdown.

One naming detail causes real confusion and is worth settling. Older material calls -550 JET_errDatabaseInconsistent. Microsoft’s current error list marks that name obsolete and replaced by JET_errDatabaseDirtyShutdown, both being the same number. If a tool or an old runbook says inconsistent, it means dirty shutdown; there is no second condition hiding behind the older name.

The two companion codes are about the logs, not the database. -543 is JET_errRequiredLogFilesMissing, the required log files for recovery are missing. -528 is JET_errMissingLogFile, the current log file is missing. Both almost always have a human cause: logs deleted to free space on a full volume, a backup that truncated while the database was offline, or a restore that put back the database file without its matching log set.

Full reference

The codes and what Microsoft actually publishes

A note on the engine utility

Microsoft no longer publishes a current reference page for the Exchange database utility, so this article does not present its switches as documented syntax. The tool ships with Exchange and prints its own mode list when run without arguments. Confirm the mode you want there, run it against the copy you took rather than the original, and note that header inspection and soft recovery are different modes with different arguments. Everything in the fix layer above uses cmdlets that are documented.

Never delete transaction log files by hand to free space on a log volume. They are the only route back to a consistent database after a crash. Deleting them turns a routine recovery into a restore from backup, and where the backup is also missing, into permanent data loss.

Reading the state before deciding anything

The checkpoint file matters less than people assume. It records how far replay has already reached. If it is missing, recovery starts from the oldest log available, which takes longer and changes nothing about the outcome. A missing checkpoint is not a reason to reach for repair tools.

Why the DAG route is usually the right one

If another member holds a healthy copy of the same database, activating it returns every mailbox immediately and reduces this to a reseed you can schedule. Microsoft’s documented sequence is to suspend the copy, update it with Update-MailboxDatabaseCopy naming a source server that holds a passive copy, and resume. That is faster than any recovery, it does not touch the damaged files, and it leaves you a copy you can examine afterwards at leisure.

After it mounts

• Run a full Exchange-aware backup immediately and confirm the logs truncate as a result. Until they do, you are one full volume away from a repeat.
• Check every copy’s status and queue lengths, because a copy that is failed or suspended blocks truncation on the active server.
• Find out why the shutdown was dirty. A power event is one answer; a storage timeout that keeps recurring is another and needs its own work.
• Confirm the antivirus exclusions cover the database, log and checkpoint paths on every member.

Every code this article covers

Confirm the fix worked

1. The database header state reads clean shutdown with no required logs.
2. Get-MailboxDatabase -Status reports the database mounted, and a mailbox on it opens in a client.
3. Every copy of the database reports healthy with queues near zero.
4. A full backup completes and the logs truncate as a result.

Questions people ask about this