Fix ERROR_DS_CANT_START (0X00002153) on Windows Server
Active Directory won't start after a failed restore or boot into DS Repair Mode. Usually a database corruption or missing system state files.
When You'll See This Error
You're rebooting a Windows Server 2012 R2 or 2016 domain controller after a failed backup restore or a hard crash. The server hangs on 'Applying security policy' then blue-screens with 0X00002153 (ERROR_DS_CANT_START). Or you see it in the System event log — event ID 1000, source LSASS, with that same error code. The DC won't boot normally. It's almost always a corrupted Active Directory database (NTDS.dit) or a missing log file.
Root Cause
The Directory Service can't mount the database. That's it. Two common triggers:
- Restore from an incomplete backup — maybe the backup didn't capture the SYSVOL or system state fully. The DB file is there but transactions in the logs don't match, so LSASS bails out.
- Unexpected shutdown during a replication cycle — power loss or a forced reboot leaves the database in a dirty state. NTFS is fine, but the Extensible Storage Engine (ESE) says nope.
The real kicker: if you try to boot normally, LSASS tries to mount the DB, fails, and throws the 0x2153. You can't fix this from normal mode. You need Directory Services Restore Mode (DSRM).
Fix It — Step by Step
1. Boot into Directory Services Restore Mode
Restart the server. During boot, press F8 repeatedly before the Windows logo appears. Select Directory Services Restore Mode from the Advanced Boot Options menu. This boots the server with the AD database offline — you get a command prompt as the local Administrator.
Note: DSRM uses the local Administrator account, not a domain admin. If you don't know the DSRM password, you're stuck. Hopefully you set it during dcpromo.
2. Check the Database Health
Open a command prompt as Administrator. Navigate to where NTDS.dit lives — usually C:\Windows\NTDS or D:\NTDS if you moved it. Run:
ntdsutil
activate instance ntds
files
integrity
This checks the database headers and flags corruption. If it reports errors like 'Jet error -1216' or 'Database corrupt', move to the next step.
3. Repair the Database with esentutl
If ntdsutil flagged corruption, esentutl is your real tool. First, make a backup copy of the database files:
copy C:\Windows\NTDS\ntds.dit C:\Windows\NTDS\ntds.dit.bak
copy C:\Windows\NTDS\*.log C:\Windows\NTDS\logs_backup\
Then run the repair:
esentutl /p C:\Windows\NTDS\ntds.dit
Wait. This can take 20-30 minutes on a large database. /p stands for repair (don't confuse with /p on other commands). After it finishes, run integrity again:
ntdsutil
activate instance ntds
files
integrity
If integrity passes clean, move on.
4. Recover the Database
Still in ntdsutil, run:
files
recover
This replays any committed transactions from the log files into the database. Without this step, even after repair, the DB might not mount.
5. Check SYSVOL
Corruption often takes SYSVOL down too. While in DSRM, run net share and verify SYSVOL is shared. If not, you'll need to perform an authoritative restore of SYSVOL via ntdsutil after reboot — but that's a different article.
For now, just verify the SYSVOL folder exists and has data:
dir C:\Windows\SYSVOL\sysvol
6. Exit ntdsutil and Reboot Normally
Type quit twice to exit ntdsutil. Then restart the server normally — don't press F8 this time. The DC should boot into Active Directory without the 0x2153 error.
If It Still Fails
Two things to check:
- Event log after reboot: Look for event ID 1000 from LSASS or 2153 from NTDS. If you see 'Jet error -1602' or 'Database inconsistent', you need a more aggressive repair — run
esentutl /pagain, but with the/iflag to ignore corrupted pages:esentutl /p /i C:\Windows\NTDS\ntds.dit. That skips bad database pages and drops the data. Not ideal, but gets the DC up. - Hardware issue: If the repair works but the error comes back after a few days, check the disk for bad sectors with
chkdsk /forwmic diskdrive get status. A failing hard drive will corrupt the database repeatedly. Replace the drive and restore from a known-good backup.
Rule of thumb: if you're spending more than an hour fixing this database, consider promoting a new DC and demoting the old one. It's faster and cleaner.
Was this solution helpful?