This project has moved and is read-only. For the latest updates, please go here.

Consistent shadow header page error on Windows 2003

Nov 2, 2012 at 12:26 AM

First off, I know this is a bad question since it lacks a repro, I just don't know how easy a reproducing case will be, so I'm hoping this at least tickles a faint memory about this issue. If it doesn't, I'll work on a small repro.

Basically, whenever I load an ESE instance, on Windows 2003, this error is always reported:

"[processname] (pid) The shadow header page of file [ESE filename] was damaged. The primary header page was used instead."

I believe everything to be fairly vanilla in setup (unfortunately, most of the setup was done 2 years ago, but people are only now asking about it), aside from possibly having three database files in a single instance. It reports the error for each file that has data in it; one of the three is generally always empty.

Since it happens consistently across several machines, and always only on Windows 2003, it seems unlikely that it's actually a disk issue, but probably something in my configuration that I'm doing wrong or, more unlikely, an an issue with esent.

Also, this is not using ManagedESENT, but the C api directly.




Nov 5, 2012 at 11:49 PM

It doesn't ring any bells off the top of my head. Sorry.

Is the database generated on each machine separately? Or do you create the database on a central machine, and then distribute it along with your product? If the latter, then please make sure that you generate the database on the oldest platform you wish to support (e.g. generate it on an XP machine if you need to support XP). The ESE engine does not generally support reading a database written with a newer version of the DLL. (We usually end up breaking something with each release. The newer DLL/OS can still read data from the older DLL/OS, but not vice versa.)


Nov 7, 2012 at 12:29 AM

Thanks for the response.

The database is generated on each machine separately. There is a case where we do distribute "base" database files, but we make sure to distribute them in an ESE-agnostic format for the reasons you gave.

I'll work on the separate test app to reproduce the issue.


Nov 7, 2012 at 7:21 PM

Hi Michael.

I don't know the exact reason either. However, I'd suggest you to check a few things:

  1. Your problem might be the way your application quits. Ensure you stop accessing your DB, call JetTerm, then your process quits, in that order. Ensure you don't use dirty tricks to quit your application (such as calling TerminateProcess, TerminateThread, ExitProcess API).
  2. It might be a permission or sharing violation issue. You could use e.g. Process Monitor software (, set up the filter to "only show I/O by your application" AND "only show errors"", and verify your application receives no "access denied", "sharing violation", or other errors while performing the file I/O.

Regards, Konstantin.