Операция ввода-вывода, инициированная реестром, завершилась неудачно.
Примерно каждые 10 секунд оба наших веб-сервера (сервер Windows 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
> ........
Я не могу найти никакой информации о том, что может вызвать такого рода ошибки. Процессор довольно загружен на 90-100%, но есть почти 1 ГБ неиспользуемой оперативной памяти.
Ниже приведен реальный случай, с которым я столкнулся на прошлой неделе.
Симптом тот же: несколько событий «Операция ввода-вывода, инициированная реестром, не удалась безвозвратно», были зарегистрированы в системном событии. Кроме того, одно приложение сообщило об ошибке создания процесса в событии приложения. Поскольку функция CreateProcess () редко дает сбой, появление этого события является хорошим индикатором пополнения ресурсов системы.
Фактически, я обнаружил событие «Предыдущее выключение было неожиданным», которое фактически означает, что Windows не смогла очистить временную метку при выключении. (http://support.microsoft.com/kb/950323) Операционная система даже не успела обновить значение в реестре! Как это могло случиться? Нетрудно догадаться, что в Windows происходит утечка памяти невыгружаемого или выгружаемого пула.
Поэтому я добавил два счетчика: байты невыгружаемого пула и байты выгружаемого пула, а также счетчик объектов ядра в случае утечки дескриптора. Неудивительно, что через 2 дня в системе произошел сбой, как показано на следующем рисунке, размер выгружаемого пула продолжает увеличиваться с 2009-10-24 09:28 до 2009-10-26 23:26, когда система дает сбой с размером выгружаемого пула почти 360 МБ. . Я использую Procexp для получения лимита выгружаемого пула, который действительно 360 МБ.
Последний шаг - выяснить, какой драйвер протекает, Poolmon (http://technet.microsoft.com/en-us/library/cc737099(WS.10).aspx) можно использовать для отслеживания подробной информации о выгружаемом и невыгружаемом пулах.
Диск / контроллер / оборудование RAID? Выключите машину и запустите chkdsk c: / v / f (а также на любых других разделах, которые у вас есть). Я знаю, что вы сказали, что проблема возникла на двух машинах, но, возможно, у них обоих есть диски из плохой партии.
Или ваш диск в порядке, но есть единовременный сбой, вызвавший повреждение реестра. 10-секундный интервал, вероятно, является функцией пульса, которую Windows выполняет периодически (и иногда приводит к появлению сообщения «завершение работы системы при .... было неожиданным» в журналах событий после сбоя).
У нас была точно такая же проблема. Та же ошибка EvenetID в средстве просмотра событий (333). Каждые несколько дней сервер (Windows Server 2003 x64) перестал отвечать. Было невозможно войти в систему на машине локально или удаленно, поэтому нам приходилось перезапускать ее каждый раз. Мы обновили RAID / Disk / FibreChannel - прошивку и драйверы и удалили какое-то приложение для онлайн-резервного копирования (IDrive или IStore или что-то в этом роде), и проблема исчезла. Поэтому я до сих пор не уверен, решило ли проблему обновление прошивки или неисправное приложение вызывало проблемы.
Я добавил столбец «количество дескрипторов» в представление процессов. Один процесс постоянно создает дескрипторы (SNMP). Мастер производительности показывает, что до последнего сбоя сервера у SNMP было более 2 миллионов обработчиков.
Это определенно утечка ручки. Запись в журнале событий - это просто результат истощения системных ресурсов. Вопрос в том, в каком процессе протекают ручки? Я рекомендую использовать perfmon для отслеживания различных счетчиков ресурсов всей системы, поэтому, когда система снова выйдет из строя, у вас будет достаточно данных, чтобы выяснить основную причину.
Следующие счетчики могут быть полезны: Объект, Память, Процесс \ Snmp
Кстати: в вашем случае виноват, очевидно, процесс snmp.