Troubleshoot Jet database errors and recovery steps


During operating system startup, domain controller installation/uninstallation, or Active Directory Replication, you may encounter Jet error messages. This article introduces Jet error messages and their solutions.


You can use these methods to troubleshoot Jet Database errors:

  1. Verify that all Active Directory databases and log files are deployed on suitable hardware.

    Many but not all SATA and IDE drives don’t support the write flush command. SAS drives do support it.

    Active Directory databases and log files should use SAS drives on SAS controllers DCs that have a battery backup on any write caching element.
  2. If 0xc00002e1 (c00002e1) and 0xc00002e2 (c00002e2) are virtual guest domain controllers that are running on Windows Server 2012 Hyper-V hosts, install corrective fixes from Loss of consistency with IDE-attached virtual hard disks when a Hyper-V host server experiences an unplanned restart on hosts and guest DCs as required.
  3. Check whether the event that preceded the LSASS 0xc00002e1 (c00002e1) and 0xc00002e2 (c00002e2) boot errors indicates one of the following issues:

    Unscheduled power outage.
    System hang.
    Installation of Windows updates or service pack installs.
    Addition or removal of disks, volumes or partitions to the local system.
    Hard drive failure.
    NTDS.DIT or one or more log files were copied from another computer or even from a previous point in this DCs life.
  4. Start the computer into Directory Services Restore mode.
  5. Best practice: Make a System State backup so that you can roll back any changes that are made during your recovery session.
  6. Best practice: Ask the administrator up front to locate the most recent system state backup so that you can factor the existence or nonexistence of System State backups into your recovery plans. Have the admin delegate the location of any backups, if possible.
  7. Run NTDSUTIL -> Files -> Info.

    Note the path to the NTDS.DIT and log files.
  8. Verify that the drive that hosts the NTDS.DIT or log files is available on OS startup.
  9. Open Windows Explorer and verify that the NTDS.DIT and log files are present at the log file path reported by step 7.

    If the files are present, proceed to step 10.

    If the files are not present, search all available drives and volumes for the NTDS.DIT and log files that belong to this instance of Active Directory.

    Warning: There may be multiple NTDS.DIT and log files present on local drives. Use date and time stamps to locate the correct instance.

    Correct the paths for the database and log file paths as required.
  10. Verify file permissions for the OS version in question.

    Note The OS needs sufficient permissions on Windows Server 2003.






    Full Control

    This folder, subfolders and files


    Full Control

    This folder, subfolders and files

    Creator Owner

    Full Control

    Subfolders and Files only

    Local Service

    Create Folders / Append Data

    This folder and subfolders


    • The root of the volume that is hosting the NTDS.DIT and NTDS log files (system requires fully control)
    • The %windir% folder (i.e., c:\windows or c:\winnnt) (system requires fully control)
    • The folder that hosts the NTDS.DIT and NTDS log files (see permissions table below)
    • The NTDS Log files themselves (see perms table below)
  11. Verify that the correct log files reside in the log file directory:

    NTDSUTIL /FILES will identify the database directory and log file directory if different.
    NTDSUTIL /MH will identify which log files are required in the log file directory.

    Under no circumstances should the database or log files from one DC be copied to another DC to make the second DC functional.
  12. Confirm that disk or file compression is not enabled on any volume that is hosting the NTDS.DIT or log file volume.
  13. Validate the health of the database in NTDS.DIT from the bottom up.

    Validate Jet Database health from the bottom up. Proceed up to the next layer only when the underlying layer completes without error.

    Troubleshooting any error reported by ESE logical or application logical consistency when physical consistency is still failing will lead you down an improper troubleshooting path.

    Equivalent NTDSUTIL and ESENTUTL commands for each later are shown below:


    NTDSUTIL command

    ESENTUTL equivalent command

    1. Physical consistency

    no equivalent


    2. ESE logical consistency



    3. Application logical consistency

    NTDSUTIL ->Semantic database analysis


    NTDSUTIL -> Offline Defrag

    No equivalent. Run NTDSUTIL -> SDA



  14. Look up the user action for the first failing Jet error encountered during step 13. Perform remediation if possible.
  15. Repair the Jet database:
    • Some Jet database errors can be repaired by using NTDSUTIL and ESENTUTL.

    • Some Jet database errors cannot be repaired, and any attempt to repair them will fail. In such cases, your only recourse may be to restore a system state backup that predates the corruption, or build a new server. If replica DCs are up-to-date, lead with promoting additional replicas into the domain after attempting to mitigate the root cause for any hardware or software-related errors.

Note The Jet error that is returned in NTDS General event 1168 is an application layer error. Don't act on this Jet error unless the Jet Physical consistency and Application logical consistency checks, (tested in that order) pass without error.

More Information

For more information, see the following Microsoft articles:

What is a lost IO / Lost Flush?

When an application writes data to a disk, the disk indicates the written operation success. However, when the application tries to read the data that it just wrote, the data does not exist. This issue is called as lost I/O, or lost flush.