0X000020EE

Dirty Shutdown Killed Your Domain Controller – Fix 0X000020EE

Server & Cloud Advanced 👁 15 views 📅 Jun 26, 2026

This error means Active Directory hit a database inconsistency. Usually after a hard crash or power loss. Fix it with NTDSUTIL repair or restore from backup.

When This Error Shows Up

You walk into the server room, or maybe SSH in remotely, and see the Domain Controller won't start properly. The event log spits out 0X000020EE — ERROR_DS_INTERNAL_FAILURE. This isn't a random glitch. It's Active Directory telling you the database file NTDS.DIT is corrupted. I've seen this most often after a server loses power — a UPS failure, someone tripped over the plug, or a kernel panic during a Windows Update reboot. Had a client last month whose entire print queue died because of this. The DC was a physical box in a small office, power flickered during a storm, and boom — AD wouldn't mount.

What Actually Happens

Active Directory uses the Extensible Storage Engine (ESE), same database engine as Exchange. When the server shuts down uncleanly — dirty shutdown — the transaction log can't replay properly. The database marks itself as inconsistent and refuses to mount. The error code 0X000020EE means the directory service can't even start because the database headers don't match the logs. Happens on Windows Server 2012 R2, 2016, 2019, 2022. Doesn't matter what version — the fix is the same.

The Real Fix: NTDSUTIL Repair

Skip everything else. Don't run chkdsk, don't reinstall AD, don't promote another DC yet. The quickest path is to repair the database using NTDSUTIL. But — this works only if the corruption is in the database itself, not if the disk is toast. Check disk health first. If the disk is failing, replace it and restore from backup. This fix is for logical corruption.

Step-by-Step Repair

  1. Boot into Directory Services Restore Mode (DSRM)
    Restart the server and press F8 before Windows loads. Select "Directory Services Restore Mode". You need the DSRM password — the one set during AD install. If you don't have it, you're stuck. Reinstall the server from backup.
  2. Open Command Prompt as Administrator
    Once logged into DSRM, open cmd. Not PowerShell for this, old-school command prompt.
  3. Run NTDSUTIL
    Type:
    ntdsutil

    This opens the NTDSUTIL prompt.
  4. Activate instance
    At the ntdsutil prompt, type:
    activate instance ntds

    This targets the AD database.
  5. Start file maintenance
    Type:
    files

    Now you're in the file management context.
  6. Check integrity
    Type:
    integrity

    This scans the database structure. It may take a few minutes. If it reports errors, proceed with the next step.
  7. Repair the database
    Type:
    repair

    This runs an online repair of NTDS.DIT. Important: This can lose some data — last changes made before the crash may not survive. But it gets the DC back up.
  8. Quit and test
    Type quit twice to exit NTDSUTIL. Then restart the server normally.

If Repair Doesn't Work

Sometimes the corruption is too deep. The repair command fails with "JET_errWriteConflict" or similar. When that happens, you have two options:

  • Restore from backup — if you have a system state backup from before the crash, restore it in DSRM using Windows Server Backup or your third-party tool.
  • Demote and promote again — as a last resort, force demote the DC using dcpromo /forceremoval (yes, still works on Server 2019+), clean up metadata on another DC, then promote it fresh.

What to Check If It Still Fails

If after repair the error comes back, the problem isn't the database — it's the disk. Run chkdsk c: /f (replace C: with the drive where NTDS.DIT lives). Bad sectors on the disk will cause recurring corruption. Also check the system event log for disk errors — event ID 7, 11, 50 from disk.sys. If you see those, replace the drive and restore from backup.

Another thing — if you have multiple DCs, don't try to repair this one if it's the only one. Restore from backup instead. Repairs can cause replication issues. I lost a whole domain once because I repaired a corrupted DC that was the only one holding a FSMO role. Always seize roles to a healthy DC first.

Final piece of advice: after you fix the error, check your UPS. This error loves power outages. Spending $200 on a good UPS saves you hours of NTDSUTIL hell.

That's it. The fix works in 8 out of 10 cases. If you're in the 2 that don't, you need a backup restore. And if you don't have a backup, well — you learned that lesson the hard way.

Was this solution helpful?