Screenshot Verification failure: Active Directory blue screen

This article describes troubleshooting a restored Active Directory machine or screenshot verification receiving either error:

"STOP: c00002e2"

"0xc00002e2"

Environment

  • Datto SIRIS
  • Datto ALTO

Description

The error is specific to Active Directory machines, but can be caused by a few different issues. The most common causes include unhealthy protected machine or services, incorrect virtualization configuration, or missing required volumes from the backup.

An in-place upgrade of an existing domain controller to Windows Server 2025 can leave Active Directory unable to start, producing c00002e2 on every boot of the restored or virtualized machine. Microsoft does not recommend in-place upgrades of domain controllers and documents a different supported process; see Upgrade domain controllers to a newer version of Windows Server (external link).

Confirming the cause

If you know an in-place upgrade to Windows 2025 was performed, you may skip this section. If you are unsure, confirm using test virtualizations that the OS version changed within the existing backup chain. Screenshots and/or test virtualizations on recovery points taken before the upgrade may succeed, but fail on every point after it.

If you can boot the VM into DSRM using the steps below, check Application and Services Logs > Directory Services in Event Viewer for the recorded Active Directory startup error.

If an in place upgrade is confirmed to have taken place, then the troubleshooting steps provided after this section will be unable to correct the error. The condition exists in the protected operating system, not in the backup, and cannot be corrected by changing backup settings or storage controllers, or by forcing new backups.

IMPORTANT  Do not destroy the live dataset to force a new full backup in this scenario. The error will recur on the new backup, and pre-upgrade recovery points may be needed — verify their status first.

Available Next steps

  • Recovery points taken before the in-place upgrade are unaffected. Restoring or virtualizing one of those points is the available path to a bootable domain controller. Confirm those points are still within retention before taking any other action.

  • To retrieve files or configuration only, boot the virtualization into DSRM using the steps below, or perform a file-level restore or bare metal restore instead.

  • Repairing or replacing an affected domain controller, and planning a supported upgrade, are Active Directory administration tasks. While this is the recommended path, it is outside the scope of Datto support to assist.

Troubleshooting common causes

  1. Verify that the Datto appliance is backing up all volumes holding Active Directory data. Missing database files can cause a STOP: c00002e2 (external link)error. The database file ntds.dit commonly causes this. If you discover that a volume holding Active Directory data was excluded from the backup, include the volume, and then start a backup from the Protect tab of the appliance Remote Web.

    The default path to the database is as follows:

    C:\Windows\Ntds\ntds.dit

    If a custom path was configured, Windows stores the location of the NTDS database, in this registry key:

    HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

  2. Try to virtualize with each storage controller. In some instances, if the VM is using an incorrect storage controller, the restore will boot to a 2e2 error.

  3. In Configure Agent Settings > VSS Writer Exclusion, make sure NTDS is not checked. The NTDS Writer is important for properly backing up these database files.
    vss3.png

  4. Ensure you are not receiving VSS failures in the backup agent logs, and check the state of vss writers on the server during a backup. Refer to VSS: Description, Compatibilities, and Troubleshooting Resources, for more information.

  5. If you are experiencing a 2e2 error message during an offsite virtualization, boot into DSRM mode (on the domain controller) and change the system date to the date of the restored point.

    For example, if the backup is from July 10th at 2:00 pm EST, and you are booting on July 22nd, boot into DSRM and change the date back to July 10th at any point before 2:00 pm EST.

Booting up the Virtual Machine on the Datto in Directory Services Restore Mode

The general steps for booting into DSRM mode are the same for all restore types.

If the production machine is still working, it can be reset.

  1. Open an administrative command prompt.

  2. Run the following

    ntdsutil

  3. Set the dsrm password.

  4. Reset the password on server null.

  5. Enter a new password twice.

Datto Support can assist with attaching partner provided recovery ISOs to virtualizations to facilitate password resets. Partner responsibilities in these cases are:

  • Obtain the recovery disk / ISO.
  • Create a public share on the Datto device to house the ISO.
  • Syncing the public share to the cloud if the ISO is needed offsite.
  • Booting to said recovery disk and making the necessary registry changes.

  1. Start a local virtualization with networking enabled. If the production machine is still live on the network, use the Firewalled on a private subnet or the Firewalled on a private subnet, with no Internet access option.

  2. While the VM is booting, use the connect to VNC option by clicking on the preview window.

  3. When the VNC connection is up, click restart in the Datto UI to restart the virtualization.

  4. The virtual machine will start to boot on the screen. Immediately press F8 to get to the Advanced Boot Options screen. If access fails, power down the VM and repeat the previous step.

  1. From this screen, select Directory Services Restore Mode.

Once you are booted into the server

There is an event log that should log the specific cause of the 2e2 error, which is available when booted into DSRM mode and may speed up the troubleshooting process. To access the log, open the Windows Event Viewer and navigate to Application and Services Logs > Directory Services.

  1. Verify that all required drive letters for the VM are correctly assigned in Disk Management.

    • You can change the assigned drive letter of any disk shown by right-clicking the drive's entry and selecting Change Drive Letter and Paths.

    • For each offline disk, mark it online. This step is especially important for servers where the AD database lives on a separate drive from the OS.

  2. Make sure that the virtual machine time is close to the snapshot time you're booting from. Once booted normally, the time can be changed back to the present.

  3. Old log files in C:\windows\ntds\ can sometimes cause boot issues. You can try renaming all of the .log files to .old and moving them to a different folder in order to retain them if needed. Once they’ve been renamed and moved, try a reboot.

Next Steps

If the VM is still unable to boot after performing the above steps, try the following:

Checking AD Database Integrity Using esentutl

  1. Boot back into DSRM and login as .\Administrator.

  2. In an administrative command prompt run:

    esentutl /g c:\Windows\NTDS\ntds.dit

    It will warn you about AD logs, but this message can be ignored.

    If the database passes integrity checks, something else is causing the system not to boot. Event logs may shed light on the reason for the boot failure.

    If integrity checks mark the database corrupt or failed, you can attempt to repair using:

    esentutl /p c:\windows\ntds\ntds.dit.

    NOTE  This is a repair attempt and is potentially damaging to the database. Any other utilities such as chkdsk and sfc scan can be utilized at this point as well at your discretion.

In a recovery scenario; should maintenance tools fail to bring the database online in a healthy state, attempt restoration from earlier recovery points.

Outside of a live recovery; screenshots may be corrected by a new full backup or differential merge.

  • Attempt differential merge:

    1. Force a differential merge for the protected system.
    2. When completed, force a screenshot for the resulting backup.
    3. If the issue persists, check the production system's filesystems from an administrator-level command prompt with chkdsk /r.
    4. Repeat Step 1 and Step 2 of this section.
    5. If the issue persists, proceed to the next section of this article.

  • Take a new full backup by destroying the live dataset:

Additional Resources