AD DS Won't Start? Fix 0x00002138 SAM Init Failure

What Actually Causes Error 0x00002138?

I've seen this error across dozens of Domain Controllers running Windows Server 2008 R2 through 2019. The short version: the Security Account Manager (SAM) database — which is part of the NTDS.dit file on a Domain Controller — got corrupted or can't be read at boot. Your server will either blue-screen with that hex code or get stuck in a boot loop trying to load AD DS.

The three most common triggers I've personally run into are:

1. A failed disk that corrupted the NTDS.dit file or its transaction logs.
2. A bad Windows Update that partially patched the SAM hive file.
3. Someone (maybe you, maybe an intern) accidentally deleted or altered the database files in C:\Windows\NTDS.

Let's start with the fix that works nine times out of ten.

Cause 1: Corrupted SAM Hive in the Registry

This is the most common cause in my experience. The SAM hive (C:\Windows\System32\config\SAM) got borked. This can happen after a forced shutdown, a disk write error, or a bad security update. The fix is to boot into Directory Services Restore Mode (DSRM) and restore that hive from a backup.

Step 1: Boot into DSRM

Restart the server. Press F8 just before the Windows logo appears — you'll see the Advanced Boot Options menu. Select Directory Services Restore Mode. On newer servers (2012 R2 and later) you might need to press F8 repeatedly after POST. If you still can't get in, use a Windows installation media DVD/USB and choose "Repair your computer" > "Troubleshoot" > "Advanced Options" > "Command Prompt". Then run:

bcdedit /set safeboot dsrepair

Reboot. That forces DSRM.

Step 2: Restore the SAM Hive from a System State Backup

Once you're in DSRM, you need a recent system state backup. If you don't have one, skip to the next cause — you'll need to rebuild the DC. But if you do have one (from Windows Backup, or a third-party tool), here's the process:

1. Open an elevated command prompt (right-click Command Prompt, Run as Administrator).
2. Type wbadmin get versions to list your backups. Note the version identifier (looks like 08/15/2024-14:30).
3. Run wbadmin start systemstaterecovery -version:08/15/2024-14:30 — replacing the date with yours.
4. When it asks if you want to perform the recovery, type Y and press Enter.

This will restore the SAM, SECURITY, and SYSTEM hives plus the entire AD database. The server will reboot automatically after it finishes.

What you should see: After the reboot, the server should boot normally into Windows (not DSRM). If you used the bcdedit trick earlier, run bcdedit /deletevalue safeboot from a command prompt to get out of safe mode. AD DS should start without error 0x00002138.

If you don't have a backup, here's a last-ditch trick that sometimes works: copy the SAM hive from C:\Windows\System32\config\RegBack\SAM to C:\Windows\System32\config\SAM. Windows 10 and Server 2016+ keep a copy of the hives in RegBack, but it might be old. It's worth trying because you've got nothing to lose.

Expected outcome after this fix: Server boots, AD DS loads, error gone. If not, move to the next cause.

Cause 2: NTDS.dit File Corruption from a Disk Error

If the registry hives are fine but the actual Active Directory database (NTDS.dit) is corrupted, you'll still get 0x00002138. This usually happens after a disk failure that wasn't caught by RAID — a bad sector that hit the database file. You can't just restore the SAM hive for this; you need to repair the database itself.

Step 1: Boot into DSRM Again

Same process as above. Get into Directory Services Restore Mode.

Step 2: Run NTDSUTIL to Check and Repair

Open a command prompt as Administrator. Type:

ntdsutil
activate instance ntds
files
check integrity

This scans the NTDS.dit file for corruption. If it reports errors, run:

semantic database analysis
go

That fixes most logical corruptions. If you get a message like "The database is corrupt and cannot be repaired", you'll need to restore from a system state backup (same as Cause 1) or promote a new DC from your remaining domain controllers.

What you should see: After repair, run check integrity again — it should return clean. Type quit twice to exit ntdsutil. Reboot normally.

Expected outcome: Server boots, AD DS loads, error resolved. If it still fails, the corruption is likely too deep, and you'll need to demote and re-promote this DC.

Cause 3: Permissions on the NTDS Folder Got Nuked

This one's rarer but I've seen it twice — once from a backup software that reset permissions during a restore, and once from an admin who manually changed folder permissions. If the SYSTEM account can't read C:\Windows\NTDS or the files inside, SAM can't initialize.

Step 1: Check Folder Permissions in DSRM

Boot into DSRM. Open an elevated command prompt. Run:

icacls C:\Windows\NTDS

You should see entries for SYSTEM: (F) (Full Control), Administrators: (F), and CREATOR OWNER: (OI)(IO)(F). If SYSTEM is missing or has only Read, that's your problem.

Step 2: Restore Permissions

Run these commands in order:

icacls C:\Windows\NTDS /reset /t /c
icacls C:\Windows\NTDS /grant SYSTEM:(F) /t
icacls C:\Windows\NTDS /grant Administrators:(F) /t

This resets all permissions to inherited defaults, then explicitly grants Full Control to SYSTEM and Administrators. The /t flag applies to all subfolders and files. The /c flag continues on errors — use it.

What you should see: After each command, you'll see "Successfully processed N files." No errors. Reboot normally.

Expected outcome: Server boots, AD DS starts, error gone. If it still fails, you're dealing with corruption, not permissions.

Quick-Reference Summary Table

If none of these fix it, you're looking at hardware failure (bad RAM, failing hard drive) or a full demotion/re-promotion of this Domain Controller. In that case, seize the FSMO roles onto another DC and build a new one. Error 0x00002138 is a showstopper — don't waste hours trying to baby a corrupted DC back to life when you can replace it in 45 minutes.