How to Fix 0XC00002EC When Active Directory Won't Start

You rebooted your Domain Controller after a power outage or a pending Windows Update and now you get this black screen with the message: "Directory Services could not start because of the following error: A device attached to the system is not functioning. Error Status: 0xc00002ec". The server hangs at the logon screen and eventually kicks you out. I’ve seen this exact error on Server 2012 R2, 2016, and 2019 after an abrupt shutdown corrupted the NTDS database. It looks terrifying, but it’s fixable.

What Does 0XC00002EC Actually Mean?

The Directory Service (NTDS) database file — ntds.dit — got corrupted. When Windows boots, it tries to mount the Active Directory database. If the file has even one bad page, the whole thing fails and Windows rolls back to a boot loop or a login prompt that never works. This isn’t a hardware failure 90% of the time, it’s a database that needs repair.

Step 1: Boot into Directory Services Restore Mode (DSRM)

You need to boot the server in DSRM to bypass the database mount and get a command prompt. Without DSRM, AD won’t start and you can’t do anything.

1. Restart the server. At the POST screen, press F8 repeatedly until you see the Advanced Boot Options menu.
2. Select Directory Services Restore Mode. If you’re on Server 2016 or later (UEFI), you might need to hit Shift+F8 during boot — sometimes it fails. If that doesn’t work, force a crash three times by pushing the power button during boot, then choose Repair from the recovery screen, then Advanced Options -> Startup Settings -> Restart, then press F6 for DSRM.
3. Log in with the DSRM administrator account. This isn’t your domain admin — it’s the local admin you set when you promoted the DC. If you don’t remember the password, you’ll need ntdsutil to reset it (but that’s a separate headache).

Step 2: Locate and Back Up the NTDS Database

Once in DSRM, open a command prompt as Administrator. First, find where the database lives.

dsamain -dbpath C:\Windows\NTDS\ntds.dit

If that command fails or the file isn’t there, check the registry: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Database backup path. Standard location is %SystemRoot%\NTDS\ntds.dit.

Copy the database file somewhere safe before you poke at it:

copy C:\Windows\NTDS\ntds.dit C:\NTDS_backup\ntds.dit

Step 3: Run ESEUTIL to Repair the Database

ESEUTIL is the Exchange Server database tool, but it works on NTDS.dit too. It’s your best friend here.

esentutl /p C:\Windows\NTDS\ntds.dit /o

The /p flag tells it to repair the database. The /o flag suppresses the prompt asking if you’re sure — you’re sure. This can take 10–30 minutes depending on the size of your AD database. Let it run. If it throws an error about log files, delete the log files in C:\Windows\NTDS first (just the .log files, not the .dit or .edb).

Step 4: Verify the Repair

After the repair completes, you need to check if it actually worked. Run:

esentutl /g C:\Windows\NTDS\ntds.dit

The /g flag runs a checksum check. If it says “integrity check successful,” you’re golden. If it says “error encountered,” you need to restore from a backup or rebuild the DC.

Step 5: Reboot Normally

Once the integrity check passes, reboot the server. This time, boot normally (not DSRM). If the error doesn’t come back, congratulations — you saved your domain controller. But you’re not done yet.

Step 6: Run a Full Consistency Check (Non-Destructive)

After the system comes up, AD will do a consistency check, but you can force a comprehensive one from an elevated command prompt:

ntdsutil
activate instance ntds
integrity
check
quit
quit

This ensures all database indexes are rebuilt. Skipping this step can lead to replication errors later.

Still Broken? Check These

If the server still fails after the repair, here’s what to look at:

• Hard drive health. Run chkdsk /f /r C: to check for bad sectors. A dying disk can corrupt the database over and over.
• Log file mismatch. If you deleted the log files earlier, you might have lost recent changes. Accept that and force replication from another DC.
• Backup restore. If your backup software supports Active Directory-aware restore (like Windows Server Backup), restore the System State from before the corruption.
• Demote and promote. As a last resort, demote the server from the domain, then promote it again. It’s faster than restoring from backup if you have another DC.

I’ve used this repair on at least a dozen DCs over the years. It doesn’t always work if the corruption is severe, but it’s saved me from rebuilding AD more times than I can count. If you get stuck, the logs at %SystemRoot%\debug\ntds\ntds.dmp might tell you exactly which page failed.