主页 / server / 问题 / 56121
Accepted
windyjonas
Asked: 2009-08-20 06:55:29 +0800 CST

由 Registry 发起的 I/O 操作不可恢复地失败

  • 772

每隔 10 秒左右，我们的两个 Web 服务器（windows server 2003，运行 iis6）都会在事件日志中报告相同的错误。

> Event Type:   Error Event
> Source:   Application Popup Event
> Category: None Event ID:  333
> Date:     2009-08-18 Time:        22:04:06
> User:     N/A Computer:   DFS273
> Description: An I/O operation
> initiated by the Registry failed
> unrecoverably. The Registry could not
> read in, or write out, or flush, one
> of the files that contain the system's
> image of the Registry.
> 
> For more information, see Help and
> Support Center at
> http://go.microsoft.com/fwlink/events.asp.
> Data: 0000: 00 00 00 00 01 00 6c 00  
> ......l. 0008: 00 00 00 00 4d 01 00 c0
> ....M..À 0010: 00 00 00 00 4d 01 00 c0
> ....M..À 0018: 00 00 00 00 00 00 00 00
> ........ 0020: 00 00 00 00 00 00 00 00
> ........

我找不到任何可能导致此类错误的信息。CPU 在 90-100% 时非常繁忙，但几乎有 1 GB 的未使用 RAM。

windows-server-2003 iis iis-6 low-memory windows-registry

4 个回答

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

    症状是一样的：在系统事件中记录了几个“由注册表启动的 I/O 操作无法恢复地失败”事件。此外，一个应用程序在应用程序事件中报告“创建进程失败”。由于 CreateProcess() 函数很少失败，因此该事件的出现是系统资源耗尽的良好指示。

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

    所以我添加了两个计数器：非分页池字节和分页池字节以及内核对象计数器，以防句柄泄漏。不出所料，2天后系统崩溃了，如下图所示，Paged Pool size从2009-10-24 09:28一直增长到2009-10-26 23:26，此时系统崩溃，paged pool size接近360MB . 我使用 Procexp 来获得分页池的限制，这确实是 360MB。

    最后一步是找出泄漏的驱动程序，Poolmon ( http://technet.microsoft.com/en-us/library/cc737099(WS.10).aspx ) 可用于监控详细的 Paged Pool 和 Non-分页池信息。

    替代文字

    替代文字

    • 4
  2. Best Answer

    磁盘/控制器/RAID 硬件？关闭机器并运行 chkdsk c: /v /f （以及您拥有的任何其他分区。）。我知道你说问题发生在两台机器上，但也许它们都有来自坏批次的磁盘。

    或者您的磁盘很好，但有一个一次性故障导致注册表损坏。10 秒间隔可能是 Windows 定期执行的心跳功能（有时会导致崩溃后事件日志中出现“系统关闭在……意外”消息。）

    • 1

  3. 我将“句柄计数”列添加到进程视图中。一个进程永久保持创建句柄 (SNMP)。性能向导显示，在我们上次服务器崩溃之前，SNMP 有超过 200 万个句柄。

    肯定是手柄泄漏。事件日志条目仅仅是系统资源耗尽的结果。问题是哪个进程泄漏了句柄？我建议使用 perfmon 来跟踪各种系统范围的资源计数器，这样当系统再次崩溃时，您就有足够的数据来找出根本原因。

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

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

    • 0

  4. 我们遇到了完全相同的问题。事件查看器中的相同 EventID 错误 (333)。每隔几天服务器（Windows Server 2003 x64）就会无响应。本地或远程登录机器是不可能的，所以我们每次都必须重新启动它。我们升级了 RAID/磁盘/光纤通道 - 固件和驱动程序并卸载了一些用于在线备份的应用程序（IDrive 或 IStore 或类似的东西），问题就消失了。所以我仍然不确定是固件升级解决了问题还是有问题的应用程序导致了问题。

    • 0

相关问题