process name (process id) file nameUnable to write a shadowed header for file error code. Error %5.

Details
Product: Exchange
Event ID: 439
Source: ESE
Version: 6.5.0000.0
Message: process name (process id) file nameUnable to write a shadowed header for file error code. Error %5.
   
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

    may 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