() Unable to write a shadowed header for file . Error .

Details
Product: Exchange
Event ID: 439
Source: ESE
Version: 6.5.6940.0
Component: Microsoft Exchange Extensible Storage Engine
Message: <process name> (<process id>) <storage group name>Unable to write a shadowed header for file <file name>. Error <error code>.
   
Explanation

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: MSExchangeIS (xxxx) Unable to write a shadowed header for file [path\filename].

Common causes of this issue include:

  • Another process has “stolen” the file. A virus checker may mistakenly quarantine a file, or a backup process may temporarily deny access. In this case, you may see Error -1032 in the Description section of Event ID 439. Error -1032 is equivalent to JET_errFileAccessDenied, which is defined as cannot access file — the file is locked or in use.
  • 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 439 Event. In this case, you could see Error -1022 in the description of Event ID 439. 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.
  • 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.
   
User Action
  • Check for alerts related to full disks and resolve as necessary.
  • To troubleshoot such errors, you must determine what has suddenly blocked the database service from access to its files. In many cases, restarting the affected server “breaks” the lock if you cannot find another way to do it.
  • Confirm that there is sufficient access to the disks.
  • If the database is still running, you may have to use Move Mailbox or ExMerge to move the mailboxes to another server.
  • If the database will not mount, you may need to restore from online backup. If there is no valid backup, as a last resort, you may need to repair the database with Eseutil /P, run isinteg -fix until all fixes are removed, and then mount the database and ExMerge to a new, blank database.

Related:

Leave a Reply