What's Happening
Your domain controller hits the blue screen at boot with STATUS_DS_INIT_FAILURE (0XC00002E2). The directory service can't mount the database. This usually happens after a power failure, bad disk, or a failed restore. I've seen it most often on Server 2016 and 2019 when the NTDS database file (ntds.dit) gets corrupted during an unexpected shutdown.
Fix 1: Boot into Directory Services Restore Mode (DSRM) – 30 seconds
This is the first thing to try. You need to boot into DSRM to access the database without Active Directory running.
- Restart the server. Press F8 during boot (or hold Shift+Restart in newer versions).
- Select Directory Services Restore Mode from the list.
- Log in with the DSRM password (you set this when you promoted the DC). If you don't know it, you're stuck – that's a different problem.
- Once logged in, check the event logs:
Event Viewer > Windows Logs > System. Look for ESENT or NTDS errors. The culprit here is almost always a corrupt transaction log file (edb.logorxxxx.log) in the NTDS folder (C:\Windows\NTDS).
Fix 2: Run an ESENT Repair – 5 minutes
If DSRM boots fine, run a repair on the database. This works about 70% of the time for me.
- Open Command Prompt as Administrator (in DSRM).
- Navigate to the NTDS folder:
cd C:\Windows\NTDS - Run repair:
esentutl /p ntds.dit - Ignore the warnings – yes, it says to use ntdsutil instead, but that's for non-corrupt databases. For a broken one, ESENT is quicker.
- When done, check integrity:
esentutl /g ntds.dit - If it passes, reboot normally. If it fails, you need step 3.
Caution: ESENT repair can lose some data – replication will fill it back in later. Better than a dead DC.
Fix 3: ntdsutil Repair – 15+ minutes
If ESENT can't fix it, ntdsutil is your last shot before restoring from backup. This takes longer but is more thorough.
- In DSRM, open Command Prompt as Admin.
- Type
ntdsutiland hit Enter. - Type
activate instance ntds(if you have multiple partitions, select the right one). - Type
filestheninfo– check the path to ntds.dit. Default isC:\Windows\NTDS\ntds.dit. - Type
quittwice to go back to main prompt. - Type
semantic database analysisthengo. This checks for broken references. - If errors show, type
go fixto repair them. - After repair, type
quittwice. - Reboot. If still fails, you're looking at a full restore from backup.
What Not to Waste Time On
- Rebuilding the NTDS folder – deleting log files rarely helps; the issue is the database itself.
- Running chkdsk – only useful if you see disk errors in event logs. Otherwise skip it.
- Demoting the DC – if it won't boot, you can't demote cleanly. Don't try.
Real-World Trigger
I've seen this error pop up after an ESXi host crash caused multiple VMs to lose power. The DC's NTFS volume had a dirty bit, but the real damage was to the transaction log sequence. The ESENT repair fixed it in 2 minutes.
Summary Table
| Step | Time | Success Rate |
|---|---|---|
| Boot DSRM | 30 sec | Check logs only |
| ESENT repair | 5 min | ~70% |
| ntdsutil repair | 15+ min | ~85% combined |
| Restore from backup | Varies | 99% |
If all else fails, restore from a recent backup. Make sure you have a good system state backup before this happens next time.