活动目录错误——事件ID：7；来源：密钥分发中心——本文中我们指的是KDC 7——非常难以排出故障。这不仅是因为在网络上难以搜索到这个错误的事件ID，还因为事件消息指错了问题的来源。

　　幸运的是，还是有办法找出问题的真正所在。最近我在自己的操作环境下也遇到了这个问题。这个环境里有一个大型的多域林，其中一个域的数个域控制器在日志里记录了“事件ID：7来源KDC”，如下所示：

事件类型: 错误
事件来源: KDC
事件分类: 无
事件ID: 7
日期: 08/01/2009
时间: 16:05:22
用户: 未知
计算机: Corp-DC3
描述：安全账户管理器在处理一条KDC请求时发生意外错误。错误发生于数据区。账户名是“wilnop”，查询类型是0x0。

　　注意事件数据的值是c0000017。这等效于：

• 　　十六进制数0xc0000017，等于十进制1073741801：这是定义在ntstatus.h中的STATUS_NO_MEMORY值
• 　　{没有足够的配额}
• 　　没有足够的虚拟内存或分页文件可用于
• 　　完成指定的操作

　　这些错误的出现没有规律——可能发生在任何一天，发生次数也是随机的——有时甚至一秒钟内会发生50次左右。这种状况已经持续了几个月，随着时间的推移，错误的发生也越来越频繁。

　　事件消息中的数据表明问题在于内存不足。然而域控制器是运行在拥有12GB RAM的64位机器上的，似乎不会发生内存不足的情况。因此，为了找到真正原因，我收集了发生错误的域控制器上的性能监视器的数据和事件日志，整理了所有标准计数器，包括：

•  缓存
•  逻辑磁盘
•  物理磁盘
•  内存
•  网络接口
•  处理器
•  服务器
•  服务器工作队列
•  系统
•  NT目录服务
•  进程——本地安全验证子系统服务（LSASS）

　　注意，因为这是一台域控制器，所以我也收集了NT目录服务对象计数器和LSASS进程对象计数器。

　　因为错误发生是随机的，所以错误都在几秒钟内发生，所以我配置了性能监视器，将数据存储在52MB大小的文件里。

　　看到的现象是，尽管LSASS使用了大量的内存，但是这时内存并没有耗尽，LDAP计数器（LDAP客户端会话、LDAP连接时间等）也没有任何异常。

分析KDC 7事件

　　这类的事件确实表明某项资源耗尽了——你只需找出到底是哪项资源。能够引起KDC 7事件的原因有多种，原因不同解决办法也会不同。

　　1、 如果是在域控制器关闭时记录的KDC 7事件，那么你可以使用微软知识库  的973667号文章中提供的修补程序。该修补程序会在日志中强制记录连接错误，以此避免程序出错。

　　2、 如果系统管理服务器目录清单代理程序——或者其它拥有目录清单代理的第三方程序——运行过于频繁，就有可能导致KDC 7事件被日志记录。

　　如果是这样的话，你应该修改程序运行计划，避免目录清单代理的频繁运行。

　　3、 第三方监视工具在收集数据时会加重活动目录的负载负担，使系统达到最大负荷，  从而引起KDC 7事件。

　　在我的事例中，我们安装了Quest软件公司的InTrust 和DirectoryAnalyzer工具。InTrust会产生自己的事件日志，当活动目录被访问时，就会记录相应的事件。查看InTrust的事件日志，发现如下事件被记录在案：

11/13/2009 8:39 Warning  None  1    ITAD Directory Changes    Corp-DC24
       CorpTest123$       Failed attempt to modify AD object.

　　该事件与KDC 7事件之间存在确切的相关性。

　　禁用InTrust并没有解决问题——但是禁用DirectoryAnalyzer却解决了问题。讽刺的是，Quest公司的InTrust编辑工具正好给了我解决问题的线索。没有它的话，我们可能还在拿着ADPlus到处找问题。

　　在这个例子中，虽然表面上是DirectoryAnalyzer引起了KDC 7事件，但其实并不能怪DirectoryAnalyzer程序本身——要怪就怪系统继续往一个已经很繁忙的活动目录中增加资源开销。

　　下篇文章中，我们将进一步介绍解决KDC 7问题的方法。