Fix ERROR_DS_INIT_FAILURE 0X00002154 Active Directory

Directory Services fails to boot on Windows Server. Usually happens after a bad restore or disk corruption. Here's how to fix it without rebuilding the domain.

When this error shows up

You're booting a Windows Server 2016, 2019, or 2022 domain controller. The screen goes black after the Windows logo. Then you get a blue error screen with STOP: 0X00002154 and the message "Directory Services cannot start." Or you see the same code in Event Viewer under System log — event ID 1000 with source "LSASS".

This almost always happens right after you tried to restore Active Directory from a backup, or after a hard shutdown that corrupted the database file ntds.dit. Sometimes it follows a failed disk check. The server won't boot into normal mode at all. You can only get into Directory Services Restore Mode (DSRM).

Why it happens

Active Directory stores all domain data in one file: C:\Windows\NTDS\ntds.dit. That's a Jet database — same engine that Outlook uses. If that file gets corrupted, the Directory Services service can't mount it at boot. The LSASS process (which handles authentication) fails, and Windows throws a blue screen.

The error code 0X00002154 translates to STATUS_DS_INIT_FAILURE. What's actually happening here is the database engine tries to read the header of ntds.dit, finds a checksum mismatch or a page that's out of order, and refuses to load it. The system then halts because without AD, the domain controller can't do anything useful.

Common triggers:

Using an old or incompatible backup tool (not Windows Server Backup)
Hard power loss while the server was writing to the database
A disk that has bad sectors exactly where ntds.dit lives
Running chkdsk /f without first taking the AD offline (rare but possible)

The fix — repair the database

Don't reinstall the server yet. You can fix this in under 30 minutes if the corruption isn't severe. You'll need to boot into DSRM and run a repair tool called esentutl. It's built into Windows Server. No downloads needed.

Step 1: Boot into DSRM

Restart the server. Press F8 before the Windows logo appears.
Select Directory Services Restore Mode from the boot options menu.
Log in with the local Administrator account and the DSRM password you set when you promoted this domain controller. If you forgot it, you're stuck — you'll need to rebuild.

Step 2: Check the database integrity

Open a command prompt as Administrator.
Run this command — adjust the path if your ntds.dit is somewhere else (check the NTDS folder):
```
esentutl /g "C:\Windows\NTDS\ntds.dit"
```
Look at the output. If it says "Integrity check passed", the database is fine — the problem is something else (bad driver, missing system file). If it says "Error" or "Corruption detected", move to step 3.

Step 3: Repair the database

Run the repair command. This is the step that actually fixes the corruption:
```
esentutl /p "C:\Windows\NTDS\ntds.dit"
```
It will scan every page in the database file. Corrupt pages get replaced with blank ones. Expect this to take 5–15 minutes depending on database size.
When it finishes, run the integrity check again to confirm:
```
esentutl /g "C:\Windows\NTDS\ntds.dit"
```

Note: The /p flag means "repair". It's aggressive. It drops any page it can't read. This can lose some AD objects — users, groups, policy settings that were stored on those corrupted pages. But the alternative is a dead domain controller. After repair, you'll use replication to pull fresh data from another DC (if one exists).

Step 4: Defragment the database

The repair leaves empty spots in the file. This isn't dangerous, but it slows down AD. Run this to clean it up:

esentutl /d "C:\Windows\NTDS\ntds.dit"

This creates a temporary compacted copy then swaps it in. Disk space needed: roughly 110% of the original file size.

Step 5: Reboot normally and test

Restart the server. This time, boot normally — not into DSRM.
If AD starts, you'll see the login screen. Log in with a domain admin account.
Open Event Viewer. Check the Directory Service log. Look for event IDs 1000 or 1030 that confirm the database was repaired.
Run dcdiag /test:replications /test:connectivity to verify the DC can talk to other domain controllers.

If it still fails

Three things to check:

The disk is dying. Run wmic diskdrive get status from command prompt. If it says "Bad", replace the drive immediately. Also check the System event log for disk errors like event 7 or 153.
The DSRM password is wrong. You can reset it from another DC in the domain using ntdsutil — but that's a whole other article.
The corruption is too deep. If esentutl repair finished but the server still bluescreens, try restoring from a verified backup using Windows Server Backup. If no backup exists, demote this DC (forcefully) and promote a new one from a replica. That's the nuclear option, but sometimes it's the only way.

One last thing: If you have another domain controller in the domain, you can also try non-authoritative restore. Boot into DSRM, then run ntdsutil -> authoritative restore. But that's for cases where the database is intact but the data is wrong — not for this specific blue screen error.