| Event Id | 412 |
| Source | ESE |
| Description | |
| Event Information | According to Microsoft Cause: 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. 1.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. 2.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. 3.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. Resolution: 1.Restore from online backup. 2.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. |
| Reference Links | "Event Id:412 of Source Id:ESE" |
Catch threats immediately
We work side-by-side with you to rapidly detect cyberthreats
and thwart attacks before they cause damage.