process name (process id) file nameUnable to read the header of logfile error code. Error %5.

Unable to read the header of the log file named in the Event ID 412

message. This may be due to a mismatching log signature, a corrupt log

file, or a corrupt log header.

The cause depends on the Jet (ESE) Error code in the Description section of

the event. The most common causes are listed below.

• Error -530 =

  JET_errBadLogSignature= Bad signature for a log file. A signature for

  log files is used only to ensure that we are replaying the “right” set of log

  files. For example, if Log 45 from another storage group ended up in the set of log files of another storage group, then ESE will detect a signature

  mismatch and not replay this log file. A portion of each database header

  includes the signature of the current log file generation; if they do not

  match, then we error out indicating a mismatch.

• Error -501 =

  JET_errLogFileCorrupt = Log file corrupt. Error-1022 is

  returned from corrupting the header of a log file. Corrupting other areas of

  the log file returns -501 JET_errLogFileCorrupt.

• Error -1022 = JET_errDiskIO =

  Disk IO error. The -1022 error is a generic error that appears whenever

  a disk input/output (I/O) problem prevents Exchange from gaining access to a

  requested page in the database or to a transaction log. The most common reason for a -1022 error is a

  database file that was severely damaged or truncated. If this issue occurs,
  Exchange requests a page number that is larger than the number of pages in the

  database file, and a -1022 error results. This issue can occur because of

  issues in the file system or because of improper transaction log replay. In

  the case of a log file, Error-1022 is returned from corrupting the header of a

  log file.

• Restore from online backup.
• If there is no valid backup,

  repair the database by running the eseutil /p command,

  and then run the isinteg -fix command on the affected store repeatedly until

  you receive 0 fixes or the same result for fixes twice. CAUTION: After you

  repair the database by using the eseutil /p switch and isinteg -fix,

  the database may not be stable and reliable. Because the repair process

  deletes database pages, data loss is likely. NOTE: If you have to run a hard

  repair on your production database, Microsoft recommends that you move the

  data out of the repaired database to a new database or rebuild the database

  using Move Mailbox or ExMerge.