| Previous | Next |
| BOOTING_IN_SAFEMODE_NETWORK | SESSION_HAS_VALID_POOL_ON_EXIT |
BOOTING_IN_SAFEMODE_DSREPAIR
Directory Services Repair Mode marker for BOOTING_IN_SAFEMODE_DSREPAIR
BOOTING_IN_SAFEMODE_DSREPAIR is bug check code 0x000000AA. This boot-state marker is meaningful on domain controllers or systems entering Directory Services Repair Mode. It changes which services and identity stores are expected to be active during diagnosis.
How to read it in a dump
- Interpret the dump with the DSRM boot profile in mind.
- Directory services, storage, security policy, and boot-critical drivers are more relevant than normal workstation logon behavior.
- The marker is not itself a failing component.
What to check
- Check whether the machine is a domain controller or was intentionally started in DSRM.
- Review directory-service database, security policy, and storage health.
- Compare with normal and minimal Safe Mode boot results.
References
- Installing a boot-start driver
- Microsoft Bug Check Code Reference
- Analyze a kernel-mode dump with WinDbg
Dump evidence
Preserve the complete dump, the four bug-check parameters, the exact Windows build, loaded-module list, and the event timeline immediately before the stop. AllStat summarizes the condition as “The system is booting in safemode - Directory Services Repair”; that sentence identifies the failure class, while the parameters and stack determine which object, driver, processor, or subsystem instance was involved.
Analysis order
- Run WinDbg
!analyze -v, then inspect the documented meaning of each parameter instead of relying only on the probably-caused-by line. - find the earliest abnormal event: driver update, firmware change, device reset, storage error, verifier report, resource exhaustion, or application hang connected with booting / in / safemode / dsrepair.
- keep third-party filter, security, storage, graphics, and virtualization drivers in the module inventory; removing evidence before dump analysis can obscure the responsible path.
Do not repeatedly reboot a machine affected by this result before collecting the dump and event logs. Recovery actions should follow the component identified by the stack and parameters, not merely the symbolic stop-code name.
Looking for a different code? Search another status or error code.