Select the product you need help with
- Internet Explorer
- Windows Phone
- More products
Error events are logged when the Exchange Server database service is denied write access to its own .edb files or to the .chk file
Article ID: 253111 - View products that this article applies to.
This article was previously published under Q253111
If the Exchange Server database service is denied write access to its own database files (*.edb) or to the checkpoint file (*.chk), errors similar to the following may be seen:
Event Type: Error
Event Type: Error
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:
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: