由registry启动的I / O操作失败，无法恢复

磁盘/控制器/ RAID硬件？ 取下机器并运行chkdsk c：/ v / f（以及其他任何分区）。 我知道你说这个问题发生在两台机器上，但是也许他们都有坏批次的磁盘。

或者你的磁盘没问题，但有一个一次性故障导致registry损坏。 10秒的时间间隔可能是Windows定期执行的心跳function（有时会导致崩溃后事件日志中的“系统在….中意外关机”是意外的）消息。

下面是我上周遇到的一个真实案例。

症状是一样的：在系统事件中logging了几个“registry发起的I / O操作无法恢复”的事件。 此外，一个应用程序在应用程序事件中报告了“创build过程失败”。 由于CreateProcess（）函数很less失败，这个事件的出现是系统资源重新利用的一个很好的指示。

事实上，我发现“以前的关机是意外的”事件，这有效地意味着Windowsclosures时无法清除某些时间戳（ http://support.microsoft.com/kb/950323 ）操作系统甚至没有更新registry中的值的机会！ 这怎么可能发生？ 不难猜测Windows正在泄漏非分页或分页池内存。

所以，我添加了两个计数器：非分页池字节和分页池字节以及内核对象计数器在处理泄漏的情况下。 不出所料，系统在2天后崩溃，如下图所示，分页池大小从2009-10-24 09:28至2009-10-26 23:26增加，当系统崩溃时，分页池大小接近360MB 。 我使用Procexp来获得页面缓冲池的限制，这确实是360MB 。

最后一步是找出哪个驱动程序正在泄漏，Poolmon（ http://technet.microsoft.com/en-us/library/cc737099 (WS.10) .aspx ）可用于监视详细的分页池和非分页分页池信息。

我也有同样的问题。 它每9天发生一次。 我必须重新启动服务器closures它，使其如此繁忙，甚至不让我本地login。

FDisk没有为我解决它。 我也尝试了一些MSKB文章中推荐的其他方法。

编辑：我发现了一些非常有趣的东西：我在进程视图中添加了“handles count”列。 一个进程永久保持创build句柄（SNMP）。 性能向导显示，在上次服务器崩溃之前，SNMP有超过2百万个句柄。

我在进程视图中添加了“句柄计数”一栏。 一个进程永久保持创build句柄（SNMP）。 性能向导显示，在上次服务器崩溃之前，SNMP有超过2百万个句柄。

这绝对是一个处理泄漏。 事件日志条目仅仅是系统资源耗尽的结果。 问题是哪个进程正在泄漏句柄？ 我build议使用perfmon来跟踪各种系统资源计数器，所以当系统再次崩溃时，您有足够的数据来找出根本原因。

以下计数器可能会有帮助： 对象，内存，进程\ Snmp

顺便说一句：在你的情况下，罪魁祸首显然是snmp过程。

我们有完全一样的问题。 事件查看器中的相同EvenetID错误（333）。 每隔几天，服务器（Windows Server 2003 x64）就无法响应。 这是不可能的本地或远程login到机器，所以我们不得不每次重新启动它。 我们升级了RAID /磁盘/光纤通道 – 固件和驱动程序，并卸载了一些在线备份应用程序（IDrive或IStore或类似的东西），问题就没有了。 所以我仍然不确定是固件升级解决了问题还是有问题的应用程序造成了问题。