Active Directory 数据库损坏需先排除权限、驱动器号、压缩等干扰，再通过DSRM运行esentutl /g和/k验证；确认损坏后备份并用/p修复，再/d整理碎片，最后重启、备份、dcdiag检测及repadmin同步。
遇到 active directory 数据库损坏（如启动域控制器时报错 0xc00002e1、事件 id 1103/101/1168，或复制失败提示 error_ds_obj_not_found（8333）），需立即进入目录服务还原模式（dsrm）进行诊断与修复。整个过程以安全、可控、可逆为前提，避免盲目执行破坏性操作。
确认是否真为数据库损坏
不是所有“目录服务无法启动”都源于 ntds.dit 损坏。先排除常见干扰因素：
- 检查 NTFS 权限：确保 NT AUTHORITY\SYSTEM 和 DOMAIN\Administrators 对
%SystemRoot%\NTDS及其子文件（尤其是ntds.dit、edb*.log、edb.chk）拥有完全控制权限； - 确认驱动器号未变更：若系统盘从 C: 改为 D:，而注册表中仍指向旧路径，AD 将找不到数据库；
- 检查是否启用文件压缩：NTDS 文件夹绝不能被设为“压缩”属性，否则 ESE 引擎拒绝加载；
- 查看事件日志中是否含 Event ID 1004（目录已成功关闭）后紧接 101（数据库引擎已停止），这是典型数据库加载失败链路。
进入 DSRM 并验证数据库状态
重启服务器，在 BIOS 后按 F8 → 选择“目录服务还原模式” → 使用 DSRM 密码登录（非域账户密码）：
- 打开命令提示符，运行：
esentutl /g %SystemRoot%\NTDS\ntds.dit
该命令执行完整性检查（不修改数据），输出中若出现 "Database verification failed" 或大量 "Error -1003 (JET_errInvalidParameter)"，即确认损坏； - 若校验通过但启动仍失败，再运行：
esentutl /k %SystemRoot%\NTDS\ntds.dit
检查数据库头结构是否一致，异常返回常指向元数据损坏。
谨慎执行修复操作
/p 参数会强制修复并可能删除不可恢复的数据项（如部分对象、链接值），仅在 /g 和 /k 明确报错且无可用备份时使用：
- 先备份原始文件（复制整个
%SystemRoot%\NTDS文件夹到其他磁盘）； - 执行修复：
esentutl /p %SystemRoot%\NTDS\ntds.dit
等待完成（可能耗时数分钟至数小时，取决于数据库大小）； - 修复后必须立即脱机碎片整理以重建内部结构：
esentutl /d %SystemRoot%\NTDS\ntds.dit
注意：需保证临时路径（默认为系统盘）有 ≥1.2 倍 ntds.dit 的空闲空间； - 最后用
esentutl /g再次验证修复结果。
修复后关键收尾动作
修复不等于恢复可用性，以下步骤缺一不可：
- 重启进入正常模式，观察是否能成功加载 AD DS 服务；
- 立即执行完整系统状态备份（
wbadmin start systemstatebackup），因修复后的数据库处于“脆弱稳定”状态； - 运行
dcdiag /v全面检测域控制器健康度，重点关注 Replications、KnowsOfRoleHolders、RidManager 测试项； - 若曾发生 USN 回滚（事件 ID 2095），修复后必须对所有复制伙伴执行
repadmin /rodcpwd并强制重新同步，否则数据不一致将持续隐蔽存在。
