Реестру не удалось очистить куст файл

Обновлено: 05.07.2024

Ошибка 333 относится к числу наиболее трудных для диагностики событий, регистрируемых в системном журнале Windows. С помощью системного монитора Microsoft, команд poolmon.exe и dureg.exe и рекомендаций специалиста Microsoft по технической поддержке можно ускорить процесс диагностики и устранения этой ошибки

Ошибка 333 появилась в системном журнале событий с выпуском Windows Server 2003 SP1 и быстро стала одной из наиболее частых причин обращения в службу технической поддержки Microsoft. В некоторых случаях на диагностику и устранение этой ошибки уходит несколько недель. В частности, приходится долго выяснять, к какой общей категории следует отнести данную ошибку. Ввиду непонятного описания диагностика занимает много времени. Ниже описано, как выяснить причину возникновения ошибки 333 для самостоятельного решения проблемы или получить информацию, которая повысит эффективность оказания технической поддержки.

Симптомы ошибки 333

Описание ошибки 333: «Неустранимый сбой операции ввода/вывода, запущенной реестром. Не удалось выполнить чтение, запись или запись буфера для одного из файлов, содержащих образ системного реестра». Это означает, что образ реестра, удерживаемый в памяти, не может быть записан на диск. Windows использует модуль отложенной записи для периодической записи измененных страниц памяти на диск. При отказе модуля отложенной записи в системном журнале событий регистрируется ошибка 333.

Симптомы, сопровождающие ошибку 333, включают:

«Зависание» сервера — сервер полностью перестает реагировать на нажатие клавиш и движения мыши и становится полностью недоступен, требуя «жесткой» перезагрузки. Медленная работа сервера — сервер чрезвычайно медленно реагирует на действия и обработка информации значительно заторможена. Замедленное подключение к службам терминалов — регистрация пользователей в сеансе при подключении к серверу терминалов осуществляется с задержкой. После регистрации в сеансе работа может идти, как обычно, но сама регистрация занимает несколько минут вместо нескольких секунд. Истощение ресурсов памяти. При попытке выполнения записи измененных страниц из кэша на диск модулем отложенной записи оказалось недостаточно ресурсов. Часто этот тип проблемы сопровождается событием 2020 или 2019. Диск был занят или недоступен. Иногда занятый диск недостаточно быстро реагирует на запрос модуля отложенной записи на сохранение измененных страниц памяти. «Раздувание» реестра. Реестр неожиданно увеличивается в размере, все более затрудняя сохранение изменений на диск, что обычно случается на терминальных серверах.

Особенно неприятно, что события продолжают регистрироваться в системном журнале (много раз в минуту) до перезагрузки сервера. Достаточно одного отказа модуля отложенной записи, чтобы события начали наводнять системный журнал. Хотя причина отказа модуля отложенной записи могла быть кратковременной (например, пик использования памяти), ошибки 333 продолжают регистрироваться в журнале даже при нормальном использовании памяти. Это происходит потому, что системе известно о неудачной попытке синхронизации реестра, а также о том, что версия реестра, содержащаяся в памяти, не соответствует версии на диске. Поэтому количество и частота ошибок 333 не являются достоверным индикатором остроты проблемы. По умолчанию модуль отложенной записи пытается записывать на диск изменения каждые пять секунд.

Средства диагностики ошибок 333

Диагностируя ошибку 333, сначала необходимо определить, к какой общей категории ее следует отнести. Полезно также проверить системный журнал на наличие других событий, сопровождающих ошибку 333,?— например, события 2020, указывающего на отсутствие памяти выгружаемого страничного пула, либо события 2019, свидетельствующего об утечке памяти невыгружаемого страничного пула.

В диагностике ошибки 333 могут помочь следующие инструменты.

Системный монитор. Отслеживаемые индикаторы — объекты системы, памяти, диска и процесса. Объект памяти. Отслеживается рост невыгружаемой или выгружаемой памяти. Объект процесса. Отслеживается непрерывный рост числа маркеров процесса непосредственно перед регистрацией ошибки 333. Объект системы. Счетчик «процент использования квоты реестра» указывает на долю используемой разрешенной квоты реестра. Чем больше эта доля, тем вероятнее, что проблема связана с разрастанием реестра. Физический диск. Отслеживается счетчик средней длины очереди ожидающих запросов к диску (Avg Disk Queue Length), указывающий на среднее число запросов чтения и записи. В случае всплеска показаний этого счетчика при возникновении проблемы следует проанализировать драйверы фильтра (т.?е. антивирусное программное обеспечение или программное обеспечение для резервного копирования) данной системы. Poolmon.exe. Эта команда, включенная в инструменты отладки Windows, используется для проверки использования пула памяти ядра по тэгу распределения пула. Применение poolmon.exe может вдвое сократить время диагностики, поскольку позволяет отыскать тэг, допускающий утечку памяти. Dureg.exe. Этот инструмент позволяет проследить размер каждой ветви реестра и выяснить, который из них занимает наибольшее пространство, чтобы определить, какая программа могла вызвать проблему.

Случай 1. Поиск драйвера, допускающего утечку памяти

Недавно я работал над проблемой полного зависания сервера Windows 2003 SP2 у одного из клиентов. Ошибку 333 сопровождало событие 2019 — сервер не смог выделить память из невыгружаемого пула памяти, так как он пуст. Наличие ошибки 2019 указывало на то, что проблема заключается в истощении ресурсов, поэтому следующим шагом был поиск драйвера, допускающего утечку памяти. Как показано на экране 1, выходные данные команды poolmon.exe позволяют определить тэг, резервирующий максимальный объем памяти.

Для быстрого определения тэга, допускающего утечку, следует воспользоваться параметром -b, чтобы выполнить сортировку выходных данных по числу потребляемых байтов для каждого тэга. В самом верху таблицы указан тэг, потребляющий максимальную память (в байтах).

Следующий шаг — использование встроенной утилиты Windows Findstr для нахождения драйвера, ассоциированного с тэгом NTID:

Параметр/m предписывает вывод только имени файла, а параметр /s предусматривает поиск только в текущей папке и ее вложенных папках. Выходным результатом Findstr оказался драйвер C:WINDOWSSYSTEM32DRIVERSCPQTEAM.?SYS.

Случай 2. Отслеживание интенсивного использования реестра

Не все ошибки с ID 333, однако, вызваны проблемами ресурсов. Некоторые из них нельзя связать с истощением памяти. Одна из подобных ситуаций в моей практике возникла на сервере служб терминалов, где ошибка 333 «наводняла» системный журнал. С помощью системного монитора удалось выяснить, что показатель «процент использования квоты реестра» превышает 98 (т. е. система использует более 98% разрешенной системной квоты на размер реестра). Установив, что система интенсивно использует реестр, мы вновь просмотрели записи в журнале событий приложений за период с момента возникновения проблемы, и среди них оказалось событие 1517, показанное на экране 2.

Dureg.exe — еще одна утилита, широко используемая для диагностики ошибок 333. Выходные данные Dureg.exe нужно собрать один раз, еще до возникновения неполадок, а затем вновь — в ходе проблемного периода, чтобы определить, не наблюдается ли «раздувание» реестра. Первое выполнение dureg.exe (до обнаружения проблемы) выглядит так:

C:>dureg.exe/a
Size of HKEY_CLASSES_ROOT: 11627272
Size of HKEY_USERS: 56739224
Size of HKEY_LOCAL_MACHINE: 47719408
Total Registry data size: 115985904

Второй раз dureg.exe следует выполнить при возникновении замедленной регистрации в системе и появлении ошибок 333:

C:>dureg.exe/a
Size of HKEY_CLASSES_ROOT: 11879338
Size of HKEY_USERS: 335257592
Size of HKEY_LOCAL_MACHINE: 46006166
Total Registry data size: 392142994

Можно заметить увеличение размера раздела HKEY_USERS — с 56 до 334 Мбайт. Хотя этот факт не обязательно содержит решение возникшей проблемы, данная информация дает ценную отправную точку для проведения анализа, что может значительно ускорить процесс исправления ошибки.

В данном примере логично выполнить regedit и перейти в папку HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionTerminal ServerInstallSoftware. Затем следует искать дублированные разделы реестра, связанные с каким-либо приложением, поскольку значения этого раздела копируются в профиль пользователя (HKEY_USERS) при его входе в сеанс на терминальном сервере. Возможно, одно из приложений заполняет раздел Software значениями, что в результате вызывает «раздувание» реестра и ошибку 333. Одного лишь удаления дублированных значений из раздела HKEY_USERS недостаточно, поскольку при очередной регистрации пользователя дублированные разделы будут вновь копироваться из раздела Software в раздел HKEY_USERS, и проблема останется.

Сокрытие ключей реестра от программ, работающих с неактивным реестром, при сохранении возможности обычной работы с этими ключами стандартными средствами операционной системы Windows (в составе активного реестра) может быть использовано для достижения двух целей:

сокрытие внесенных в реестр изменений от криминалистического исследования (например, сокрытие ключей определенного сервиса, которые будут корректно прочитаны и использованы операционной системой Windows в процессе загрузки, но не будут видны для сторонних программ, работающих с неактивным реестром, во время исследования накопителя);
сокрытие внесенных в реестр изменений от предзагрузочного контроля целостности (например, внесение таких изменений в ключи реестра, которые не будут видны для модулей доверенной загрузки во время контроля целостности, но будут видны для самой операционной системы Windows).

Как это происходит?

Реестр Windows состоит из двух частей: энергозависимая часть (ключи реестра и значения, которые будут потеряны после отключения куста из-за того, что они не сохраняются в файл; пример: ключ «CurrentControlSet» куста «SYSTEM»), энергонезависимая часть (синхронизируется с файлом куста реестра).

Поскольку во время записи энергонезависимой части в файл куста необходимо обеспечить целостность сохраняемых данных (например, в случае сбоя электропитания, прерывающего операции записи данных), ядро Windows использует журналирование реестра — записываемые данные сохраняются сначала в файл журнала (этот файл находится в одной директории вместе с основным файлом и имеет расширение «.LOG», «.LOG1» или «.LOG2») и только потом в основной файл куста (если запись в файл журнала не будет успешно завершена, то основной файл останется целым и нетронутым, а если запись в основной файл не будет успешно завершена, то его целостность можно восстановить с помощью данных из журнала, которые были успешно записаны до сбоя).

Предлагаемый способ сокрытия ключей (и их значений, а также других элементов) заключается в сохранении соответствующих данных только в журнал, но не в основной файл куста реестра. Сторонние программы, работающие с неактивным реестром, в подавляющем большинстве случаев игнорируют файл (файлы) журнала, а потому ключи реестра, хранимые в журнале, но не в основном файле, будут невидимыми для этих программ. Ядро Windows, с другой стороны, использует журнал для восстановления целостности куста при его подключении, а потому обсуждаемые ключи будут видимыми для ядра и, соответственно, других запущенных программ.

Для блокирования записи в основной файл куста можно использовать отладочный механизм, который появился в Windows Vista. Для понимания сути этого механизма необходимо рассмотреть появившуюся в Windows Vista схему журналирования.

Журналирование до Windows Vista

В Windows XP и более ранних версиях Windows каждому энергонезависимому кусту реестра соответствует один основной файл и один файл журнала. Исключением из этого правила является куст SYSTEM в Windows 2000 и более ранних версиях Windows, который зеркалируется (в файл с именем «system.alt»), а не журналируется, чтобы упростить код загрузчика (который должен загрузить в память указанный куст) и не добавлять в него поддержку восстановления из журнала (под зеркалированием понимается поочередная запись данных в два основных файла, которые в результате будут иметь одинаковую логическую структуру ключей, значений и других элементов).

Журналирование происходит путем компактного (без выравнивания по смещениям) сохранения в файл журнала подлежащих записи в основной файл данных вместе со структурой — битовой картой секторов основного файла, которая позволяет определить, по каким смещениям нужно записать в основной файл блоки данных из файла журнала. Если при подключении куста будет установлено, что в его основной файл не была завершена запись данных, то будут прочитаны блоки из файла журнала, определены (с помощью битовой карты) смещения этих блоков в основном файле, а затем эти блоки будут записаны в основной файл, таким образом завершая ранее прерванную из-за сбоя запись.

Подобная схема имеет существенный недостаток — если во время записи в основной файл произойдет ошибка ввода-вывода (например, из-за попытки записи в сбойный сектор), то дальнейшие операции синхронизации куста с основным файлом окажутся невозможными до перезагрузки компьютера (даже в том случае, если сбойный сектор будет нейтрализован переназначением секторов на уровне драйвера файловой системы или хранилища). Это происходит из-за того, что журналирование каждый раз очищает файл журнала от старых данных, а значит ошибка записи в основной файл приведет к нарушению целостности этого файла, и новая попытка синхронизации куста потребует стирания данных из журнала, который остался единственным способом восстановить уже нарушенную целостность основного файла.

Следовательно, если такое стирание журнала допустить, возможно возникновение ситуации, когда из-за нового сбоя будет нарушена целостность единственного файла журнала, при этом целостность основного файла была нарушена предыдущим сбоем.

Журналирование начиная с Windows Vista (до Windows 8.1)

Для решения проблемы синхронизации куста с основным файлом в условиях повторяющихся сбоев была реализована схема двойного журналирования. В этой схеме каждому основному файлу соответствуют два файла журнала (с расширениями «.LOG1» и «.LOG2»). По умолчанию используется первый файл журнала («.LOG1»).

Если при записи в основной файл произошла ошибка, то происходит смена файла журнала (с «.LOG1» на «.LOG2» и наоборот). Таким подходом обеспечивается постоянное наличие корректного файла журнала, в котором есть данные от предыдущей попытки синхронизации. В результате сбой во время записи в файл журнала (после сбоя во время записи в основной файл) не приведет к неисправимому нарушению целостности куста реестра (кстати говоря, если такая ситуация все же возникнет, в ядре Windows есть механизмы самовосстановления, исправляющие явные ошибки в логической структуре куста).

Но такую схему журналирования нужно отладить, а потому в ядро Windows была внедрена переменная, позволяющая имитировать повторяющиеся ошибки записи в основные файлы всех кустов реестра, — CmpFailPrimarySave. По неизвестным причинам эта переменная есть и в обычных версиях ядра (а не только в отладочных версиях). Если в эту переменную записать некоторое значение, отличное от нуля, то функция записи данных в основной файл будет имитировать ошибку на разных этапах такой записи.

Следует отметить, что в процессе подключения куста реестра ядро должно выбрать, какой из двух файлов журнала использовать для восстановления, для чего реализуется относительно сложный алгоритм, определяющий, какой из файлов журнала сохранил целостность, какой из них содержит более позднюю версию записываемых данных и т. д. До Windows 8 этот алгоритм содержал серьезную ошибку, в результате которой почти во всех случаях, вне зависимости от конкретных деталей, выбирался первый файл журнала («.LOG1»). В частности, для Windows 7 соответствующие исправления алгоритма были выпущены лишь в марте 2016 года (следовательно, все это время двойное журналирование в Windows 7 предоставляло защиту целостности не лучше, чем Windows XP). Для преодоления описанной ошибки необходимо не только блокировать запись в основной файл куста, но и блокировать переход ко второму файлу журнала («.LOG2») в случае сбоя (чтобы первый файл журнала всегда содержал наиболее поздние данные, пусть даже и в ущерб целостности в случае сбоя; в противном случае при следующей загрузке системные кусты реестра могут быть восстановлены в состояние, неожиданно более раннее, чем при завершении штатного выключения компьютера). К счастью, следующее значение обсуждаемой переменной позволяет достигнуть желаемого эффекта без смены файла журнала — 3.

Эта же переменная будет работать так же и в более новых версиях Windows (8.1 и 10), где применяется другой способ журналирования (вне рамок данной статьи).

Эксперимент

В качестве эксперимента создадим невидимые ключ и его значение в операционной системе Windows 7 (Service Pack 1). Для этого в запущенной операционной системе изменим (редактированием памяти) значение переменной ядра CmpFailPrimarySave с 0 на 3, а затем создадим ключ реестра «HKEY_LOCAL_MACHINE\SYSTEM\invisible_key» со значением с именем «invisible_value», содержащим строку «123456». Затем выключим операционную систему штатным способом и экспортируем файлы куста реестра SYSTEM.

После повторного включения операционной системы запустим редактор реестра и отметим, что искомые ключ и значение в нем видны (рис. 1).

Рис. 1: Редактор реестра Windows

В то же время в экспортированных файлах реестра искомые ключ и значение сторонние программы (например, Windows Registry Recovery и Registry Explorer) не отображают (рис. 2 и 3).

Рис. 2: Windows Registry Recovery

Рис. 3: Registry Explorer

Win 7 х64 test mode - 1C 8.1
Сеть -
Ethernet adapter Подключение по локальной сети:

DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Realtek PCIe GBE Family Controller
Физический адрес. . . . . . . . . : имеется
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
IPv4-адрес. . . . . . . . . . . . : 192.168.2.201(Основной)
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз. . . . . . . . . : 192.168.2.250
DNS-серверы. . . . . . . . . . . : 8.8.8.8
192.168.2.250
днс провайдера - до недавнего времени был на 1м месте
NetBios через TCP/IP. . . . . . . . : Включен

Terminal Patch - 10 RDP users =5 локальная сеть +5 удалённых
Ammyy Admin service v 3.1
TeamViever 8 as servise
Антивирус ЕСЕТ НОД 32 антивирус 6
Брандмауэр отключен
все обновления накатаны по состоянию на 01,08,2013
Дата проверки Антивирусом ДРВЕБ КУР ИТ 05,08,2013

Проблема: совершенно непроизвольно пропадает доступ к РДП.

проблема 1 - Слетал Шлюз по умолчанию и удалённые пользователи не могли войти, прописывается в свойсвах адаптера нормально, но после перезагрузки слетает.
прописал в реестре шлюз, теперь не слетает, хотя сама проблема интересна

Проблема 2 - Отбрасывает пользователей рдп по локальной сети и удаленных не давая залогинится.

10,22 Люди пробовали зайти но не смогли - их отбрасывало как внутри сети так и удалённо

1. Драйвер браузера сети инициировал выборы в сети \Device\NetBT_Tcpip_, так как был остановлен основной браузер сети.
Код события: 8033

2.
Имя журнала: System
Источник: Service Control Manager
Дата: 08.08.2013 10:22:10
Код события: 7042
Категория задачи:Отсутствует
Уровень: Сведения
Ключевые слова:Классический
Пользователь: система
Компьютер: 1CS-PC
Описание:
Службе Модуль поддержки NetBIOS через TCP/IP было успешно отправлено управление остановить.

Указана причина: 0x40030011 [Операционная система: Сетевые проблемы (Запланированное)]

3. 10,22 Служба "Модуль поддержки NetBIOS через TCP/IP" перешла в состояние Остановлена.
Код события: 7036

4. 10,22 Не удается запустить сервер DCOM: как /. Ошибка:"8"
возникла при запуске команды:
C:\Windows\System32\mobsync.exe -Embedding
Код события: 1001

5. 10:29:29
Служба "Модуль поддержки NetBIOS через TCP/IP" перешла в состояние Работает.
код 7036

6.
10:29:29
Службе Модуль поддержки NetBIOS через TCP/IP было успешно отправлено управление остановить.
Код события: 7042
Указана причина: 0x40030011 [Операционная система: Сетевые проблемы (Запланированное)]

7.
Служба "Модуль поддержки NetBIOS через TCP/IP" перешла в состояние Остановлена.

8.
Не удается запустить сервер DCOM: как /. Ошибка:
"1450"
возникла при запуске команды:
C:\Windows\System32\mobsync.exe -Embedding

9.
08.08.2013 10:29:34
Поддержка IPv4 отключена в WMPNetworkSvc, так как при получении таблицы IP-адресов была обнаружена ошибка "1450". Для включения поддержки IPv4 необходимо перезапустить службу WMPNetworkSvc.
код 14361

10
08.08.2013 10:29:49
Неустранимый сбой операции ввода-вывода, инициированной реестром. Реестру не удалось очистить куст (файл): "".
код 6

11.
Управление драйверами завершило процесс добавления службы tunnel для экземпляра устройства с ИД ROOT\*ISATAP\0001 со следующим состоянием: 0.
код 20003

12.
08.08.2013 10:29:52
Поддержка IPv4 отключена в WMPNetworkSvc, так как при получении таблицы IP-адресов была обнаружена ошибка "1450". Для включения поддержки IPv4 необходимо перезапустить службу WMPNetworkSvc.

13,
Источник: TermDD
Дата: 08.08.2013 10:30:39
Код события: 56
Уровень безопасности сервера терминалов обнаружил ошибку в потоке протокола и отключил этот клиент. IP-адрес клиента: 92. - мой ип адрес

14.
Имя журнала: Application
Источник: Microsoft-Windows-User Profiles Service
Дата: 08.08.2013 10:31:44
Код события: 1532
Категория задачи:Отсутствует
Уровень: Сведения
Ключевые слова:
Пользователь: система
Компьютер: 1CS-PC
Описание:
Служба профилей пользователей остановлена.

15.
Имя журнала: Application
Источник: Microsoft-Windows-User Profiles Service
Дата: 08.08.2013 10:31:43
Код события: 1530
Категория задачи:Отсутствует
Уровень: Предупреждение
Ключевые слова:
Пользователь: система
Компьютер: 1CS-PC
Описание:
Система Windows обнаружила, что файл реестра используется другими приложениями или службами. Файл будет сейчас выгружен. Приложения или службы, которые используют файл реестра, могут впоследствии работать неправильно.

16.
Имя журнала: Application
Источник: Desktop Window Manager
Дата: 08.08.2013 10:31:43
Код события: 9009
Категория задачи:Отсутствует
Уровень: Сведения
Ключевые слова:Классический
Пользователь: Н/Д
Компьютер: 1CS-PC
Описание:
Диспетчер окон рабочего стола завершил работу с кодом (0x40010004)

17.
Имя журнала: Application
Источник: Desktop Window Manager
Дата: 08.08.2013 10:30:54
Код события: 9010
Категория задачи:Отсутствует
Уровень: Сведения
Ключевые слова:Классический
Пользователь: Н/Д
Компьютер: 1CS-PC
Описание:
Процесс (AA_v3.exe) сделал запрос на отключение диспетчера окон рабочего стола - это амми админ

ДАЛЕЕ ПОСЛЕДОВАЛ РЕСЕТ - после которого доступ восстановился. и такое по 2-3 раза в неделю