Fix STATUS_DS_SAM_INIT_FAILURE (0XC00002CB) on Domain Controller

You reboot your domain controller after a power outage or a failed update, and instead of the login screen you get a black screen with STATUS_DS_SAM_INIT_FAILURE (0XC00002CB). The server sits there, unresponsive, until you force a restart. This typically happens on Windows Server 2012 R2 through 2022, and the trigger is almost always a corrupt Active Directory database (NTDS.DIT) or a schema version mismatch after a partial upgrade.

What's Actually Happening Here

The SAM (Security Account Manager) initialization failure means the local Security Accounts Manager database — or more often, the Active Directory database it depends on — failed to load during boot. The error code 0XC00002CB maps to STATUS_DS_SAM_INIT_FAILURE in the Windows bugcheck database. What's happening at the kernel level is that the Directory Service module (lsass.exe) tries to mount NTDS.DIT, verifies its schema version against the registry, and if those don't match — or the database is corrupt — it bails out with this error.

The reason this appears during boot and not at runtime is that the SAM subsystem initializes before the network stack is fully up. So no remote recovery, no safe mode with networking — you're stuck at a console.

The Fix – Step by Step

I'm going to assume you have physical or out-of-band console access. The fix uses Directory Services Restore Mode (DSRM), which is the only way to get a degraded DC to boot and let you touch the database.

Boot into Directory Services Restore Mode. Reboot the server and press F8 during POST (or hold Shift while clicking Restart from the recovery menu, if you can get there). Select Directory Services Restore Mode. You'll boot to a minimal command-line environment where Active Directory is not started.
Log in with the DSRM administrator account. This is the password you set when you promoted the DC. Not your domain admin — it's a local account specific to DSRM. If you don't have this password, you're hosed. Microsoft doesn't provide a backdoor. You'll need to reinstall or restore from backup.
Open an elevated command prompt. Run cmd.exe as Administrator.
Check the database integrity. Run:
```
ntdsutil
activate instance ntds
files
integrity
```
This runs a database integrity check on NTDS.DIT. It's read-only — won't corrupt anything further. If it reports errors, proceed to step 5. If it says clean, your issue is schema version mismatch — jump to step 7.
Repair the database. Still inside ntdsutil, run:
```
repair
```
This can take 10–30 minutes depending on database size. Important: This is a semantic repair, not a full defrag. It marks corrupt objects as unreachable but doesn't delete them. After repair, run integrity again to confirm it passes.
Compact the database to reclaim space. Run:
```
compact to C:\temp\ntds
```
(Create the C:\temp\ntds folder first.) This writes a clean, defragmented copy of the database. Copy it back:
```
copy C:\temp\ntds\ntds.dit C:\Windows\NTDS\ntds.dit
```
Remove the temp files afterward.
Check schema version match. The registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters has a value Schema Version. For Windows Server 2019, that should be 88. Open regedit (you're in DSRM, so registry is mounted), compare this to what the database expects. If they mismatch, you need to update the schema using adprep /forestprep from a working DC — but since this DC is down, you're likely looking at a restore scenario.
Exit DSRM and reboot normally. Run shutdown /r /t 0.

If It Still Fails After the Repair

Two scenarios. First, the database is beyond repair — physically corrupt sectors on the disk. Check the system event log (you can view it from DSRM using eventvwr.msc) for disk errors like Event ID 55 or 153. If the disk is failing, restore from a verified system state backup. Second, the schema version in the registry doesn't match the database. This usually happens when you applied an update on a replica DC and the schema didn't replicate fully. In that case, your only clean options are:

Seize FSMO roles from another DC and demote this one via ntdsutil metadata cleanup.
Force a non-authoritative restore from a system state backup taken before the schema change.

I've seen people try to hack the registry key to match the database version. Don't. That's how you get replication conflicts that bring down the whole forest. Let this DC go and rebuild it — it's faster and safer.

One last thing: If you have multiple domain controllers, the real fix is to never let this DC become a single point of failure. Run two+ DCs per site. Then a boot failure like this means you just seize roles and rebuild at your leisure.