STATUS_DS_SAM_INIT_FAILURE_CONSOLE (0xC00002ED) Fix when AD won’t boot
This error hits when a domain controller fails to boot because the SAM database is corrupt or the Directory Services Restore Mode password is wrong. I’ll walk you through the fix.
When this error shows up
You’re trying to boot a Windows Server domain controller — 2012 R2 or 2016 mostly — and instead of the login screen, you get a blue screen with STATUS_DS_SAM_INIT_FAILURE_CONSOLE (0xC00002ED). The system halts. No sign of life. The server might have been hit by a power failure, an unexpected shutdown, or a failed Windows update that corrupted the SAM database. I saw this last year on a client’s 2012 R2 DC after a UPS failure; the server powered off mid-write to the AD database.
What’s going on under the hood
The SAM (Security Accounts Manager) stores local user and group accounts. On a domain controller, it’s tightly coupled with Active Directory. This error means the SAM tried to initialize but hit a corrupt database file — usually ntds.dit (the AD database) or the related transaction logs. The corruption can be caused by a disk write failure, a buggy patch, or even a failing hard drive. The exact error code 0xC00002ED points to the SAM subsystem failing during boot, not the network stack.
Fix: Step-by-step
Step 1: Boot into Directory Services Restore Mode (DSRM)
You need to get the server into DSRM, which loads a minimal version of the SAM that doesn’t require the full AD database. Restart the server and press F8 before the Windows logo appears. Select Directory Services Restore Mode. If you don’t see that option, you might need to hold Shift while clicking Restart from the recovery console.
Step 2: Check the DSRM password
Once booted into DSRM, you’ll be prompted for the Administrator password you set when you promoted the server. If you don’t know it — and I’ve had clients forget it — you’re stuck. There’s a tool called ntdsutil that can reset it, but you need another admin account or boot from a repair disk. If you have the password, log in and open a command prompt as administrator.
Step 3: Run esentutl to check the database
The first diagnostic step is to check the integrity of the AD database. Run this command in the command prompt:
esentutl /g "C:\Windows\NTDS\ntds.dit"This will tell you if the database is corrupt. If you see errors like Error -501 or JET_errDatabaseCorruption, proceed to repair. If it reports clean, the issue might be in the transaction logs.
Step 4: Repair the database (if corrupt)
If the database needs repair, run:
esentutl /p "C:\Windows\NTDS\ntds.dit"The /p flag repairs the database by removing corrupt pages. This is risky — it can lose data. Always have a backup before doing this. On my client’s server, this fixed the boot, but a handful of users had to be recreated. After the repair, defragment with:
esentutl /d "C:\Windows\NTDS\ntds.dit"Step 5: Restart normally
Type shutdown /r /t 0 to reboot. If it boots into normal mode without the error, you’re golden. Test by logging in and checking AD users and computers.
What if it still fails?
If the error comes back, the corruption might be deeper — check disk health first. Run chkdsk /f /r from DSRM on the drive holding the NTDS folder. A failing disk can cause repeated corruption. Also, check the event logs for disk errors. If the drive is fine, restore from a system state backup. Use Windows Server Backup or a third-party tool to restore the %SystemRoot%\NTDS folder and the SAM registry hive. Don’t rely on esentutl for repeated repairs — it’s a band-aid, not a cure. Finally, consider demoting the DC and promoting it fresh if you have another DC in the domain. That cuts the risk of latent corruption.
Pro tip: After fixing, schedule a monthly reboot and check the AD database integrity with esentutl. Catches issues before they become boot failures.
Was this solution helpful?