Fix 0xC00002E1 Active Directory Won't Start

When This Error Hits

You're staring at a black screen on your Domain Controller after a reboot. The server boots to the login screen, then throws a popup: "The directory service cannot start. The system cannot find the file specified." Event ID 1006 in the Directory Service log pairs with this error code. I've seen this most often after a hard power loss on an older 2008 R2 or 2012 R2 DC, but it'll bite you on Server 2016 too. The database file — ntds.dit — got corrupted during a dirty shutdown. You can't promote a new DC, you can't sign in with domain accounts, and the clock's ticking.

Root Cause — Plain English

Active Directory stores everything in a single Jet Blue database file called ntds.dit. It's a transactional database — writes hit a log first, then the database. If the server loses power or crashes before those logs flush, that database file gets marked as dirty. The NTDS service refuses to mount a dirty database because it can't guarantee data integrity. The error 0xC00002E1 means "the database is corrupted or inconsistent." It's not a permissions issue, not a DNS problem, not a network timeout — it's a database-level failure. Skip the usual AD troubleshooting steps; they won't help here.

The Fix — Step by Step

You have two paths. Path A: boot into Directory Services Restore Mode (DSRM) and run esentutl to repair the database. Path B: restore from a known-good System State backup. Try Path A first — it's faster and doesn't require a backup tape.

Step 1: Boot into DSRM

Restart the server. Press F8 during boot (before the Windows logo).
Select Directory Services Restore Mode from the Advanced Boot Options menu.
Log in with the local Administrator account and the DSRM password you set during promotion.

If you don't know the DSRM password, you're stuck. You'll need to restore from backup or rebuild the DC. Write that password down next time.

Step 2: Locate the Database Files

Open a command prompt as Administrator. The default NTDS folder is C:\Windows\NTDS. Run these commands:

cd C:\Windows\NTDS
dir *.dit

You should see ntds.dit. If it's missing or 0 KB, you have a bigger problem — jump to the backup restore section.

Step 3: Run Esentutl to Repair

First, check the database integrity. Run:

esentutl /g ntds.dit

You'll see output like Operation terminated with error -1216 (JET_errDatabaseCorrupted). That confirms corruption. Now run the repair:

esentutl /p ntds.dit

The /p flag (repair) is aggressive. It rebuilds the database structure, but it will drop any transactions that can't be resolved. That means you might lose recent password changes or group membership updates. There's no way around that — it's better than a dead DC.

Wait for it to finish. On a large database (over 10 GB), this can take 30-60 minutes. Don't interrupt it.

Step 4: Verify the Repair

esentutl /g ntds.dit

If it reports No errors found, you're good. If it still fails, you need the backup.

Step 5: Restart Normally

Type shutdown /r /t 0. Let the server boot normally. If everything worked, Active Directory starts, domain users can log in, and you've saved yourself a rebuild.

When the Repair Fails — Restore from Backup

If esentutl can't fix the database, or if ntds.dit is missing entirely, you need a System State backup. Here's the drill:

Boot into DSRM again.
Open Windows Server Backup (or whatever tool created the backup).
Select Recover → System State → choose the most recent backup before the error.
Recover to original location. This overwrites ntds.dit and all log files.
Reboot normally.

No backup? You're rebuilding the DC. Demote it (forcefully, using ntdsutil), clean up metadata, then promote a fresh DC. It stinks, but it's the only safe path.

What to Check If It Still Fails

Disk space — The NTDS volume needs free space to rebuild logs. If it's below 1 GB, the database won't mount. Free up space or add a new disk.
Volume health — Run chkdsk /f on the drive containing NTDS. Bad sectors on the disk can corrupt the database again. If chkdsk finds hardware issues, replace the drive.
Antivirus exclusions — I've seen real-time scanning on ntds.dit cause this error. Exclude the NTDS folder and all .DIT files from AV scans.
Log file mismatch — Sometimes the logs are inconsistent. Try deleting all .log files in the NTDS folder (except edb.log and res1.log / res2.log), then run esentutl again. Back up the logs first in case you need them.
Hardware failure — If this keeps happening, the disk controller or storage subsystem is dying. Check the server's hardware logs and replace the drive or controller.

One last thing — if this is a virtual machine, make sure your hypervisor isn't doing live snapshots on the DC without quiescing the NTDS service. That's a common trigger for this exact error.