0X40000370: Directory Service Shutting Down Fix

Cause #1: A domain controller that's stuck in a restart loop or shutdown never finished

This is the most common thing I see with this error. You'll get STATUS_DS_SHUTTING_DOWN when a client or another DC tries to talk to a domain controller that's either rebooting, still starting up, or halfway through a shutdown that hung. The directory service literally tells you: can't talk right now, I'm busy dying.

Last month had a client with a 2016 DC that kept throwing this error every 15 minutes. Turned out the previous admin had scheduled a reboot via Windows Update that never completed—the server was running but the NTDS service was stuck in stop pending. Checking the system log showed event ID 1000 from LSASS, but the real tell was the NTDS service staying in 'Stopping' for hours.

Fix it:

1. Open Services.msc, find 'Active Directory Domain Services' (NTDS). If it says 'Stopping' or 'Starting', force it: run net stop ntds /y then net start ntds. Don't worry, it'll kick you out of the session—that's normal.
2. If the service won't stop gracefully, you have to kill it. taskkill /f /im lsass.exe is dangerous—you'll crash the server. Better to use ntdsutil in a command prompt:

   ntdsutil
   activate instance ntds
   quit
   quit

   Then restart the server cleanly.
3. After reboot, check event log for NTDS General events—should show 1000 (start) then 1394 (successful binding). If you see 1173, the database is corrupt—see cause #3.

Skip trying to restart the server remotely via shutdown /r. It might not trigger a clean service stop. Go physically or use iLO/iDRAC.

Cause #2: Replication timeout or dead replication partner

This error also pops up when a DC is trying to replicate with a partner that's offline or slow as hell. You'll get the error on a client trying to authenticate against a GC that's still waiting for replication from a dead DC. I've seen it most often when someone demotes a DC without cleaning up metadata—the remaining DCs keep trying to sync with a ghost.

Fix it:

1. Open Active Directory Sites and Services, expand your site, check each server's NTDS Settings. If you see a connection object pointing to a server that no longer exists, delete it.
2. Run repadmin /syncall /AdeP on each remaining DC. If you get access denied or 'server not responding', that partner is your problem.
3. Check DNS: nslookup -type=srv _ldap._tcp.dc._msdcs.<yourdomain>. Any IPs that don't exist anymore? Remove them from DNS forward lookup zones.
4. If replication is stuck but the partner is alive, try repadmin /options <DCname> +DISABLE_OUTBOUND_REPL then repadmin /options <DCname> -DISABLE_OUTBOUND_REPL to reset the replication schedule.

One thing: don't just delete and recreate the NTDS Settings object. That breaks the RID pool and USN rollback protection. Use ntdsutil metadata cleanup to properly remove dead servers.

Cause #3: Corrupt ntds.dit database

Less common but happens—especially on old 2012 R2 DCs that never had a proper offline defrag. The error appears when the database hits a bad page during a read operation. You'll also see event ID 1173 or 1578 alongside the 0X40000370.

Fix it:

1. Boot into Directory Services Restore Mode (F8 at startup, pick DSRM).
2. Run ntdsutil then activate instance ntds, then files, then integrity. That checks the database—takes a few minutes. If it reports any errors, you need to repair.
3. Repair: ntdsutil -> activate instance ntds -> files -> repair. This can take 30 minutes on a large DB. Don't interrupt it.
4. After repair, run semantic database analysis from ntdsutil to fix reference issues. Then compact the database: files -> compact to C:\temp\newntds.dit. Copy that file over the old one in C:\Windows\NTDS\.
5. Reboot normally, check event log for 1000 and 1394.

Important: if you have multiple DCs, don't bother repairing—just demote this one and promote a fresh DC. It's faster and safer. Only repair if this is your only DC.

Quick-reference summary table

If you're still seeing the error after all this, check your firewalls—port 389 and 3268 might be blocked between DCs. That's rare but I've seen it twice in ten years.