Windows Server Common Errors, Boot, Driver, and Update Fixes
Why This Is Happening
I've seen this exact situation play out on dozens of enterprise networks: an admin makes what seems like a routine change, removing a role, applying an update, swapping a driver, and the next morning, the server either refuses to boot or drops into a recovery menu that nobody expected. If you're dealing with Windows Server common errors right now, you're not alone, and the fact that the error messages Microsoft shows you are often cryptic and unhelpful makes it even worse.
Take the STOP: c00002e2 blue screen, for instance. The full message reads: "Directory Services could not start because of the following error: The specified procedure could not be found. Error status: 0xc000007a." That sounds like a driver problem, right? Or maybe a missing DLL. But it's neither. That specific stop code is almost always the result of someone removing the Active Directory Domain Services role from a domain controller without properly demoting it first, and Windows has no graceful way to recover without manual intervention.
On Windows Server 2012 and all later versions, the experience is different but equally confusing. Instead of a blue screen, you land on a "Choose an option" menu, the same one you'd see after a failed Windows update or a boot configuration problem. There's no error code, no obvious hint. Most admins spend twenty minutes assuming it's a hardware fault before the real cause dawns on them.
The root cause in the AD DS scenario is specific: servicing tools like Dism.exe, Pkgmgr.exe, and Ocsetup.exe are perfectly happy to strip out the DirectoryServices-DomainController role from a live domain controller. They don't check whether the machine is actively serving as a DC. Server Manager and the ServerManager PowerShell module do run that validation, which is exactly why Microsoft's own guidance says to always use those tools when touching role binaries on a DC.
Beyond that specific scenario, Windows Server boot failures also stem from corrupted Boot Configuration Data (BCD), failed cumulative updates that leave drivers in a broken state, hardware changes that invalidate driver signing, and virtual machine snapshot restores that create USN rollback conditions in Active Directory replication. Each of these has a different fix path, and mixing them up wastes hours.
This guide walks through all of them, clearly, in the right order, with exact commands you can copy and run. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you go deep into recovery procedures, eliminate the obvious. If your Windows Server domain controller is showing the "Choose an option" screen after a recent role or feature change, this is the fastest path back to a healthy state.
From the "Choose an option" menu, go to Troubleshoot → Startup Settings → Restart. After the restart, select Directory Services Repair Mode (DSRM) from the Startup Settings list, it's typically option 4 or accessible by pressing F4. Log in with your DSRM account password (this is set separately from your domain admin password, and if you don't know it, that's a separate recovery path we'll cover below).
Once you're at the command prompt in DSRM, run this to confirm what's actually missing:
dism.exe /online /get-featuresLook at the output and find the entry for DirectoryServices-DomainController. If its state shows as Disabled, that confirms the role was removed, and that's your culprit. Now add it back:
dism.exe /online /enable-feature /featurename:DirectoryServices-DomainControllerThat command will complete without error. Do not restart yet. Stay in DSRM, then run the PowerShell force-removal to properly clean up the domain controller's AD DS metadata:
Uninstall-AddsDomaincontroller -ForceRemovalNow restart into normal mode. If you had other healthy domain controllers in the domain, your network should come back cleanly. If this was your only DC, stop here, restoring from a system state backup is the only safe path forward, and you should not proceed with force removal.
ntdsutil "set dsrm password" "reset password on server null" quit quit, no reboot required.
This is the entry point for almost every domain-controller-specific boot fix. DSRM is a special safe mode for Windows Server that loads the OS without starting Active Directory Domain Services, giving you the access you need to repair the AD database or correct role configuration.
Windows Server 2012 and later: At the "Choose an option" screen, click Troubleshoot, then click Startup Settings, then click Restart. After the system restarts, you'll see a numbered list. Press 4 or F4 to enable Directory Services Repair Mode.
Windows Server 2008 R2 / 2008: Restart the server while holding Shift+F8 to intercept the boot loader. From the Advanced Boot Options menu that appears, select Directory Services Repair Mode.
At the login screen, log on as .\Administrator using the DSRM password, not your domain administrator password. These are distinct credentials. If you don't know the DSRM password and you have another working DC, you can reset it remotely before rebooting (see the Pro Tip above).
Once logged in, you'll see a desktop environment with limited functionality. Open an elevated Command Prompt by right-clicking the Start button and selecting Command Prompt (Admin) or Windows PowerShell (Admin). You should see your session is running as the local Administrator, not as a domain account. That's correct, proceed to the next step.
If DSRM itself fails to load, you may be dealing with a corrupted BCD store or a hardware driver issue rather than an AD DS role problem. In that case, skip to Step 4 for BCD repair.
Once you're inside DSRM, you need to confirm that the role binary is actually missing before you do anything else. Running the role check takes about ten seconds and rules out other possibilities like a corrupt ntds.dit database or a failed Windows update that left drivers in an inconsistent state.
Run the following command from an elevated Command Prompt:
dism.exe /online /get-featuresThis outputs every Windows feature and its current state. Scroll through the list, or pipe it to findstr /i "directory" to narrow it down, and find the line for DirectoryServices-DomainController. If the state reads Disabled, the role was removed without proper demotion. If it shows Enabled, the problem lies elsewhere (skip to Step 4).
To re-add the role, run:
dism.exe /online /enable-feature /featurename:DirectoryServices-DomainControllerDISM will show a progress bar. The process typically takes two to five minutes depending on your server's storage speed. When complete, it will confirm success without requesting a reboot. Do not reboot at this point, you still need to perform the clean force-removal in the next step, or the DC will enter a boot loop.
Why add the role back just to remove it again? Because the proper demotion process requires the role binaries to be present. The tools (dcpromo on older versions, Uninstall-AddsDomaincontroller on newer ones) need those files to safely strip Active Directory from the machine, clean up the registry, and update replication metadata on other DCs in the forest.
After DISM completes, restart back into DSRM and confirm you can log in again before proceeding to Step 3.
This step is where the actual fix happens. With the role binaries restored, you now have the tools available to do what should have happened before the role was stripped, a proper AD DS demotion using the force-removal flag.
Windows Server 2012 and later, PowerShell method: Open an elevated PowerShell window in DSRM and run:
Uninstall-AddsDomaincontroller -ForceRemovalYou'll be prompted to enter and confirm a new local Administrator password for the server (since it will no longer be a domain controller after this). Enter a strong password, confirm it, and let the process run. It will automatically restart when finished.
Windows Server 2008 R2 / 2008, dcpromo method: From an elevated Command Prompt in DSRM, run:
dcpromo.exe /forceremovalThis launches a wizard in some versions. Step through it and accept the force-removal option. Again, you'll set a local admin password before the wizard completes.
After the reboot, the server will come up as a standalone member server, not a DC. That's the goal. It should boot normally into the Windows login screen without any stop errors or recovery menus. Log in with the new local Administrator password you set during the force-removal.
One important note: the server's metadata still exists in Active Directory on your other domain controllers. That metadata needs to be cleaned up, or you'll see replication warnings and lingering DC references across the domain. Step 4 handles that.
After you force-remove AD DS from a domain controller, the other DCs in your forest still have records pointing to the now-demoted machine. These stale metadata entries cause a range of Windows Server replication errors, failed DNS lookups, and confusing event log entries that can haunt you for weeks if not cleaned up.
Microsoft provides two tools for this job. The GUI approach uses Active Directory Users and Computers (dsa.msc), and the command-line approach uses ntdsutil.exe. I prefer ntdsutil for this because it works even in degraded environments where the GUI snap-ins fail to load.
On a healthy domain controller in the same domain, open an elevated Command Prompt and run:
ntdsutil
metadata cleanup
connections
connect to server [YourWorkingDCName]
quit
select operation target
list domains
select domain 0
list sites
select site 0
list servers in site
select server [NumberOfOrphanedDC]
quit
remove selected server
quit
quitReplace [YourWorkingDCName] with the hostname of any healthy DC in your domain, and replace [NumberOfOrphanedDC] with the number that corresponds to your force-removed DC in the list servers in site output.
Alternatively, open dsa.msc, navigate to the Domain Controllers OU, right-click the orphaned DC object, and select Delete. You'll be prompted to confirm you understand the server is permanently offline. Select yes.
After cleanup, run repadmin /replsummary from a healthy DC to confirm replication is healthy across all remaining domain controllers.
There's a second category of Windows Server domain controller failure that's far more insidious because it doesn't crash the server, it just silently breaks replication. I'm talking about a USN rollback, and if you're running virtualized domain controllers, this is something you need to know about.
A USN (Update Sequence Number) rollback happens when an older copy of the Active Directory database gets restored or pasted into place, typically when someone reverts a VM snapshot without understanding the consequences. The DC comes back online and looks perfectly healthy. No blue screen, no warning, no "Choose an option" menu. But the other DCs in the forest think they're already up to date with it, so they stop replicating changes to and from it. Your AD environment silently diverges.
The tell-tale sign is Directory Services Event ID 2095 in the Directory Services event log. To check, open Event Viewer (eventvwr.msc), navigate to Windows Logs → Directory Service, and filter for Event ID 2095. The event text will explicitly reference a USN rollback and direct you to recovery steps.
The fix is deliberate. On the affected DC, open an elevated Command Prompt and run:
repadmin /showreplThis shows the current replication status. A rolled-back DC often shows no errors at all in repadmin output, because its replication partners think it's current. That's the silent nature of this failure. Cross-reference with Event Viewer on the replication partners and look for errors related to the suspect DC's GUID.
Once confirmed, the safest resolution is to demote the rolled-back DC properly, clean its metadata as described in Step 4, and re-promote it as a fresh domain controller. Attempting to "fix" the USN state in place by manipulating the registry is not recommended for production environments, that approach leaves too many variables that can resurface during the next replication cycle.
If your environment is small and this is the only DC, restore the most recent known-good system state backup, not the snapshot. A proper system state backup captures Active Directory in a consistent state and is the only reliable recovery path when you have no other DCs available.
Advanced Troubleshooting
The five steps above cover the most common root causes of Windows Server domain controller boot failures. But if you've worked through all of them and you're still seeing problems, or if your issue is more broadly related to Windows Server common errors outside of the AD DS context, here's where to dig deeper.
Analyzing Event Viewer for Domain Controller Boot Errors
Event Viewer is your first stop for any Windows Server error that isn't self-explanatory. After any failed boot or unexpected recovery mode entry, boot into DSRM, open eventvwr.msc, and go to Windows Logs → System and Windows Logs → Directory Service. Sort by Date/Time descending and look at the events logged in the 60-second window before the failed boot. Event IDs to watch for include:
- Event 2095, USN rollback detected (covered in Step 5)
- Event 1168, AD DS internal error, often database corruption
- Event 1168 / 2103, NTDS service failed to start, which maps to the
c00002e2stop code - Event 5774 / 5781, DNS registration failure (often follows improper DC removal)
Repairing the Boot Configuration Data Store
If your server isn't a domain controller and you're hitting a generic Windows Server boot error, not the AD DS-specific errors above, the Boot Configuration Data (BCD) store is often the culprit, especially after failed Windows cumulative updates or driver rollbacks. Boot from Windows Server installation media, open the Repair options, launch a Command Prompt, and run:
bootrec /fixmbr
bootrec /fixboot
bootrec /rebuildbcdRun all three in sequence. The /rebuildbcd command scans all disks for Windows installations and asks you to add them to the BCD store. Confirm when prompted. Reboot and test.
Checking Windows Server Update Failures with DISM and SFC
A cumulative update that fails mid-install can leave system files in a broken state. Run these two commands in sequence from an elevated Command Prompt to detect and repair component store corruption:
DISM.exe /Online /Cleanup-Image /RestoreHealthsfc /scannowDISM contacts Windows Update to download replacement files (your server needs internet access for this, or you can point it at a local WIM with /Source). SFC then verifies and replaces protected system files. Run DISM first, SFC alone can miss component store issues that DISM catches.
Group Policy and Startup Script Interference
In domain-joined environments, Group Policy startup scripts and logon scripts sometimes interact badly with service initialization during boot, particularly when DCs are involved. If your server boots but hangs at the "Applying Group Policy" screen for more than five minutes, boot into Safe Mode, open gpmc.msc or run rsop.msc, and look for startup scripts assigned to the machine. Also check HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History in the registry for any GPO that recently changed.
Prevention & Best Practices
Most of the Windows Server common errors covered in this guide are completely avoidable. The c00002e2 stop error? It only exists because someone bypassed the right tool. USN rollbacks on virtual DCs? They happen because VM snapshot policies don't account for AD replication windows. None of these are obscure edge cases, they're predictable, repeatable failure modes that proper discipline eliminates.
The single most important rule: always use Server Manager or the ServerManager PowerShell module to add or remove roles and features on domain controllers. These tools check whether the machine is an active DC before allowing you to remove critical components. DISM, Pkgmgr, and Ocsetup don't make that check. They'll happily hollow out a live DC without a single warning. Use them for standalone servers only.
For virtualized domain controllers specifically, configure your hypervisor snapshot policies to exclude DC VMs, or at minimum, ensure that any snapshot taken of a DC VM is never older than your AD replication tombstone lifetime (default 60 days, often set to 180 in modern environments). Restoring a snapshot older than the tombstone lifetime guarantees a USN rollback condition. Some organizations use a simple automation rule: if a VM is tagged as a domain controller, snapshots are automatically deleted after 24 hours. That's a good default.
Maintain at least two domain controllers in every domain. A single-DC environment has no recovery path for most of these failures except restoring from backup, and that only works if you have a backup. Two DCs means you always have a replication partner to serve as the source of truth during recovery.
Test your DSRM passwords quarterly. Log them in your privileged account management system (CyberArk, Thycotic, or even a locked secrets vault) immediately after setting them. A forgotten DSRM password during a boot failure turns a 30-minute fix into a multi-hour ordeal.
- Always use Server Manager or
Install-WindowsFeature/Uninstall-WindowsFeaturefor role management on DCs, never raw DISM on a live domain controller - Enable VM Generation ID awareness on all virtualized DCs, Windows Server 2012 and later support this natively, and it automatically detects and prevents USN rollbacks when a VM is cloned or snapshotted
- Schedule monthly system state backups using
wbadmin start systemstatebackupand verify restorability at least once per quarter - Run
repadmin /replsummaryweekly as a health check, a one-line script in Task Scheduler takes three seconds to set up and gives you early warning of replication drift before it becomes a crisis
Frequently Asked Questions
My domain controller is stuck on "Choose an option" after a Windows update, is my AD database corrupted?
Not necessarily, and don't assume the worst before investigating. The "Choose an option" screen on Windows Server 2012 and later is a generic recovery menu that appears whenever the boot process fails for almost any reason, including AD DS role issues that have nothing to do with database corruption. Boot into DSRM, check Event Viewer for IDs 2095, 1168, or 2103, and run dism.exe /online /get-features to see if the DirectoryServices-DomainController role is still enabled. In the majority of cases that trigger this specific menu after a routine change, the role was inadvertently removed and the NTDS database itself is completely intact and recoverable.
What is the STOP c00002e2 error code and how do I fix it on Windows Server 2008 R2?
The STOP c00002e2 error, full message: "Directory Services could not start because of the following error: The specified procedure could not be found. Error status: 0xc000007a", means Windows is trying to start Active Directory Domain Services but the required role binaries are missing. It almost always happens when someone used Dism.exe, Pkgmgr.exe, or Ocsetup.exe to remove the DirectoryServices-DomainController role without first demoting the server. On Server 2008 R2, the fix is: restart while holding Shift+F8 to get to DSRM, log on with the DSRM account, re-add the role with dism.exe /online /enable-feature /featurename:DirectoryServices-DomainController, restart back into DSRM, then run dcpromo.exe /forceremoval. After that completes and the server reboots normally, clean up the orphaned DC metadata using ntdsutil on another healthy DC.
How do I know if my server has a USN rollback without it showing an error?
That's exactly what makes USN rollbacks dangerous, the affected DC looks fine. The clearest indicator is Event ID 2095 in the Directory Services event log on either the affected DC or its replication partners. You can also run repadmin /showrepl across all DCs and compare the reported USN values, if one DC's reported USN from a partner is significantly higher than what the partner thinks it last sent, something is off. Another approach: run repadmin /replsummary on all DCs and look for any that show zero successful replications in the last 24 hours, which often indicates a partner has stopped replicating with it. The silent nature of this failure means routine replication monitoring isn't optional, it's the only way to catch it before it causes serious divergence.
I forgot my DSRM password and can't log into the DC in repair mode, what do I do?
If you have at least one other domain controller running and accessible, you can reset the DSRM password on the affected DC remotely without a reboot. Open an elevated Command Prompt on any healthy DC and run: ntdsutil "set dsrm password" "reset password on server [AffectedDCName]" quit quit. You'll be prompted to enter a new DSRM password. This change takes effect immediately, no reboot required on either machine, and you can then use that password to boot the affected DC into DSRM. If the affected DC is your only DC and you can't access DSRM, you're in a more difficult position; Microsoft Support or a third-party AD recovery tool may be needed to get you back in.
Can I remove the Active Directory Domain Services role from a DC using DISM if I add /forceremoval first?
No, and this is a common misconception. DISM's /enable-feature and /disable-feature flags operate on role binaries at the servicing layer. They don't have any concept of domain controller demotion, metadata cleanup, or replication partner notification. Even if you use DISM to remove the AD DS binaries and it "succeeds," you've left orphaned metadata on every other DC in the forest, and you haven't given Active Directory the chance to transfer FSMO roles, replicate final changes, or update DNS records. The right sequence is always: Server Manager or Uninstall-AddsDomaincontroller -ForceRemoval in PowerShell for the demotion, followed by ntdsutil metadata cleanup on a healthy DC. DISM's only role in the DC recovery workflow is to restore the binaries when they've already been improperly removed, as a prerequisite to running the proper demotion tools.
My Windows Server replication shows no errors in repadmin but AD changes aren't propagating, where do I start?
Start with Event ID 2095 in the Directory Services event log on all DCs in the affected site, this is the first place a USN rollback surfaces. If 2095 is clean, run repadmin /showrepl * /csv > repl.csv to generate a comprehensive replication report across your entire forest, then open it in Excel and filter for any rows with a non-zero error count. Also check that the Windows Time Service is synchronized across all DCs, a time skew of more than five minutes between DCs blocks Kerberos authentication and silently breaks replication. Run w32tm /query /status on each DC and confirm all are syncing from the same authoritative time source. Time skew is responsible for more "unexplained" replication failures than most admins expect.