XADM: How to Detect Header Damage in Databases, Log Files, Patch Files, and Checkpoint Files

The Esefile utility, available in the Support folder of Service Pack 3 for Exchange Server 5.5 can be used to detect damage to file headers for Exchange Server 5.0, 5.5, and Exchange 2000 Server.

Damage to 5.5 log files is often reported as a -514 or 0xfffffdfe (JET_errBadLogVersion). If you have not recently upgraded Exchange Server or are very sure you don't have mixed versions of files, the procedures in this article allow you to determine whether or not the problem is actually a damaged file header.

The primary function of Esefile is to verify the checksum integrity of every page in a database file. All log file headers are checksummed by the same method that database pages are checksummed, so Esefile can be used to verify headers, even in transaction log files.

The header page is the first physical 4 kilobyte (KB) page in the file. The second page in the file is a "shadow header" which is an exact duplicate of the first header page.

NOTE: Transaction log files do not have shadow headers. For additional information, click the article number below to view the article in the Microsoft Knowledge Base: Esefile can scan Exchange Server 5.0, 5.5, and Exchange 2000 files. Use the /X option to scan a 5.0 file, the /S option to scan a 5.5 file, and the /S option to scan an Exchange 2000 file.

Type the following commands at a command prompt:

• To scan a 5.0 database file:
  esefile /x priv.edb
• To scan a 5.5 log file:
  esefile /s edb.log
• To scan an Exchange 2000 checkpoint file:
  esefile /s e00.chk

Esefile scans files in physical page order. Esefile reports the header page as page -1 and the shadow header as page 0. Because the header is scanned first, you can press CTRL+BREAK to quit Esefile after several seconds. If you haven't seen a reference to page -1 or 0 by the time the first progress dot appears on screen, the header pages are good. Esefile lists only pages that have a problem. Output of Esefile for a bad header will look similar to the following: To test a log file, set the Screen Buffer Height on your command prompt window to a large value such as 9999. Log files use a different checksumming scheme than database files, except for the 4-KB header. Therefore, every page in a normal log file except the header page will fail the Esefile test, and Esefile will rapidly generate hundreds to thousands of lines of output. Scroll back to the beginning of the output. If the log file is good, it will look similar to the following: Notice that there is no page -1 listed above. Because there is no shadow header, it is not meaningful that page 0 fails the test. A bad log file, on the other hand, will look similar to the following: If a log file header is damaged, it cannot be repaired--another copy of the log file must be found. For files with shadowed headers, as long as one copy of the header is still good, the bad copy can be automatically "patched," and the problem is usually detected and fixed before you know it exists.

If both copies of a database or patch file header are damaged, another copy of the file must be found. If a checkpoint file is irreparably damaged, it can be re-created dynamically. A checkpoint file is nothing but header. All versions of Exchange Server quickly repair a damaged checkpoint file by either patching it, if one copy of the header is still good, or by reconstructing it from scratch.

IMPORTANT NOTE: Do not delete the checkpoint file arbitrarily, especially if the database is stopped at the time of deletion.

As the database starts, the checkpoint file controls which transaction log files, if any, will be replayed. If you have in any way altered the contents of the data directories since the last time the database was stopped, you may cause irreparable damage to the database by beginning log file replay at the wrong point.

Exchange 2000 adds new safeguards to prevent improper log file replay, regardless of any tampering with files. But even with Exchange 2000, deleting the checkpoint may still result in a startup failure.

It is not recommended that you delete the checkpoint file while the database is running. If the checkpoint file is missing, Exchange Server re-creates it the next time that it is accessed (usually within a few seconds or minutes). Nonetheless, deleting the checkpoint file while the database is running is not entirely risk free: if the database were to crash after deletion and before the file had been re-created, you would be in the same situation as if you had deleted the checkpoint file while the database was stopped.