To troubleshoot such errors, you must discover what has suddenly blocked the database service from access to its files. In many cases, restarting the affected server "breaks" the lock if you are unable to find another way to do it.
Common causes of this issue include:
- Another process has "stolen" the file. A virus checker may mistakenly quarantine a file, or a backup or restore process may temporarily deny access.
- A disk or controller failure has occurred, and access to the entire drive has been lost, sometimes temporarily. Check the System Log for I/O or drive errors near the time of the 158 Event.
- Permissions have been removed from the folder where the file resides.
- The file has been marked read-only. This is most likely to happen to a checkpoint file.
- The folder containing the file has been renamed or deleted. This is also mostly likely to happen to a checkpoint file.
What Is a "Shadowed Header"?
Exchange Server database, checkpoint, and log files begin with a 4-kilobyte (KB) header section. The header contains important identification and configuration information about the file. Headers can be viewed with the Eseutil utility by using the
/MH (database file),
/ML (transaction log file), or
/MK (checkpoint file) options.
NOTE: The
/ML option was first included in Exchange Server 5.5 Service Pack 1 (SP1).
Database and checkpoint file headers are frequently modified during normal operation, while log file headers are never modified after a log file has been created. For file headers that are frequently modified, a "shadow header" safeguards the header during updates. The primary header is the first 4-KB block in the file; the shadow header, identical to the primary header, is the second 4-KB block. Both header pages are checksummed, and the checksum is written to each page. Damage to even a single bit of either page can be reliably detected because changes to the data change the checksum that should be on the page.
When a header is updated, modifications are made first to the shadow header page. If a crash occurs before the shadow update finishes (causing a "torn write"), the primary header is still intact.
After the shadow has been updated, the primary header is updated. If a crash occurs at this point, the shadow header is still intact. Thus, even during an update, a valid header exists at all times.
Damage to a page is detected by recalculating the checksum each time the page is accessed. If the calculated checksum doesn't match the one already on the page, the page is bad. As long as the other copy of the header is good, it can be used to "patch" the damaged page.
If an access-denied condition occurs, and the next write attempted by the database is to a header, an "unable to write shadowed header" error is written to the Event Log. This happens because the shadow page is the first header page updated. If the write attempt is elsewhere than in a header, different errors will be reported, including -1032 or 0xfffffbf8(JET_errFileAccessDenied), and -510 or 0xfffffe02 (JET_errLogWriteFail).
The headers of transaction log files (*.log) are not shadowed, and therefore, denial of access to a log file does not result in a "shadowed header" error. Conversely, checkpoint files are nothing but header (4 KB of primary header and 4 KB of shadowed header), and thus always report a "shadowed header" error on a write failure.
If a database file or log file cannot be written to, the database service stops to preserve the integrity of the database. If the checkpoint file cannot be written to, database operation continues normally in most respects. The checkpoint file tracks progress in writing out log file transactions to the database file. If the checkpoint file is "frozen," data is still written to the database file, and the checkpoint is advanced, but new checkpoints are not recorded in the checkpoint file until it again becomes available.
There are three issues you may encounter if the checkpoint file cannot be written to for a long period of time:
- The log file referenced in the checkpoint file may be deleted before the checkpoint is updated. In this case, if the database is stopped abnormally, it may be unable to start again, because the checkpoint file references a nonexistent file. For additional information, click the article number below
to view the article in the Microsoft Knowledge Base:
176239 XADM: Database Won't Start; Circular Logging Deleted Log File Too Soon
- Old log files may not be permanently deleted during online backup. The online backup process relies on the checkpoint file to determine which log files may be safely deleted. If the checkpoint file is "frozen," logs newer than the checkpoint are not purged, even if the checkpoint file is several days behind.
- If the checkpoint file is damaged, online backup may fail entirely. Online backup must be able to at least read the checkpoint file. In a normal operation, a damaged checkpoint file is detected and corrected within minutes of the damage. But if the file is also locked against a write operation, the damage can't be corrected until the lock is removed.