Статья дополняет серию материалов, освещающих методы устранения проблем, приводящих к возникновению критической системной ошибки (BSOD). В материалах раздела рассматриваются ситуации, с которыми я сталкивался лично (в своей практике) и с которыми мне удалось разобраться. STOP-ошибка (STOP error), контроль дефекта (BugCheck) или в простонародье BSOD - фатальный системный сбой операционной системы Windows, являющийся причиной полного прекращения функционирования основных компонентов ядра операционной системы, влекущий за собой потерю динамических не сохраненных пользовательских данных и приводящий к появлению на экране монитора синего экрана смерти (BSOD). Числовое обозначение STOP-ошибки - идентификатор, характеризующий "природу" фатальной системной ошибки, используется при диагностике причины возникшей неполадки. В данной статье речь пойдет о сбое с идентификатором STOP 0000006B.
Восстановление хранилища компонентов при помощи средства проверки готовности системы к обновлению (SURT)
Сегодня вашему вниманию предоставляется еще одно пополнение цикла статей о методах восстановления хранилища компонентов Windows. Помимо изобретения широкой общественностью бесчисленного множества "наколеночных" методик восстановления работоспособности компонентной модели, сами разработчики из Microsoft предлагают вполне официальные методы. В данной публикации мы рассмотрим один из подобных методов, который заключается в восстановлении хранилища компонентов при помощи средства проверки готовности системы к обновлению или, иными словами восстановлении хранилища компонентов при помощи SURT. Фактически описываемым методом предусматривается проверка каталогов/файлов компонентной модели при помощи специализированного пакета и попытка устранения найденных ошибок.
больше о восстановлении хранилища компонентов при помощи средства SURT
Восстановление компонента прямой заменой файлов
Продолжаем цикл статей о разнообразных правильных (а порой и не очень) методах восстановления компонентов в рамках компонентной модели Windows. Честно говоря, подобные описанному в данном посте "кривому" методу восстановления работоспособности компонентной модели рождаются вовсе не от хорошей жизни, появляются они под воздействием многочисленных проблем с компонентами операционной системы. Во многих случаях официальные методы восстановления хранилища компонентов (dism и аналоги) не помогают, помимо этого отсутствует какая бы то ни было внятная официальная документация, из чего складывается недопонимание структуры и принципов работы компонентной модели. При подобном отношении со стороны разработчиков абсолютно любые средства вернуть компонентную модель в работоспособное состояние хороши!! В данной публикации речь пойдет о восстановлении компонента прямой заменой файлов. Фактически методом предусматривается прямая ручная замена поврежденных [кривых, неправильно функционирующих] файлов, являющихся причиной возникновения ошибок. Исправные файлы копируются с работоспособной станции-донора. Узкое место метода заключается в том, что для реализации требуется наличие находящейся на том же уровне обновлений нормально функционирующей операционной системы той же версии.
далее про восстановление компонента методом прямой замены файлов
Ошибка обновления 0x80092004
Настало радостное мгновение и корпорация Microsoft в очередной раз порадовала своих поклонников заплатками для систем Windows 7 и Windows Server 2008R2. При этом, все бы замечательно, если бы обновления устанавливались безотказно всегда и везде. Тем не менее, памятуя о том, что подсистема обслуживания на основе компонентов находится в перманентной бэте, процесс установки любого обновления от Microsoft представляет собой эксперимент с непрогнозируемым результатом. Так вышло и в ситуации, послужившей основой данной статьи: под руку попалась система, на которой установка обновлений KB4512486, KB4516033, KB4520003, KB4525233, KB4523206 и KB4525235 завершается с ошибкой 0x80092004. Ошибку можно лицезреть в Центре обновления Windows в следующем виде:
Зависает на classpnp.sys
Данный материал представляет собой своего рода исследование, робкую попытку разобраться в одной, набившей уже оскомину, загадке этапа загрузки операционной системы Windows. Многие специалисты согласятся со мной, что на практике довольно часто приходится наблюдать сбой при котором станция, загружаясь в безопасном режиме, отображает на экране монитора список загруженных драйверов (последним из которых часто выводится classpnp.sys) и сообщение "Подождите, пожалуйста...", после чего благополучно подвисает:
Debugger can't get KD version information
Иногда приходится наблюдать инциденты, когда при запуске отладчика WinDbg в режиме локальной отладки ядра (local kernel debugging), возникает следующая ошибка: Debugger can't get KD version information, Win32 error 0n5.
Ошибка возникает не смотря даже на то, что отладчик WinDbg запускается из-под учетной записи с правами локального администратора, с использованием механизма эскалации (повышения) привилегий (Запуск от имени администратора). Ошибка указывает на то, что отладчик не может получить (Win32 error 0n5, символическое имя ERROR_ACCESS_DENIED) информации о версии отладки ядра. Описанную ошибку можно наблюдать в версиях Windows, начиная с Vista. Существует несколько причин возникновения ошибки Debugger can't get KD version information, Win32 error 0n5, описанием которых мы сегодня и займемся.
подробнее об ошибке debugger cant get kd version information
Обслуживание на основе компонентов
Наверняка уже ни для кого не секрет, что как и в любом (без исключения) программном обеспечении, в коде операционных систем присутствуют ошибки. Периодически тем или иным образом их удается обнаружить, о чем рано или поздно узнает разработчик, в чьих интересах производить оперативное устранение найденных проблем. Но мало выпустить исправление (заплатку/патч), изменения эти требуется еще как-то доставить до пользовательских операционных систем, функционирующих по всему миру. Помимо ошибок, на всем протяжении цикла поддержки операционной системы, в неё добавляются и новые функциональные возможности. Все перечисленные виды вносимых в систему изменений (исправления, обновления, дополнения) на данный момент принято обобщать в огромный комплекс задач под названием обслуживание операционной системы.
С появлением и развитием сети Интернет, методы доставки контента обслуживания до географически-удаленных операционных систем претерпели существенные изменения: сперва в виде доступных на сайте Microsoft для скачивания файлов, затем, по мере развития архитектуры операционных систем и, в частности, алгоритмов обновления, трансформировались в сложные многоуровневые сервисы, производящие автоматическую загрузку и обновление. В последнее время Microsoft запустила уже непрерывный цикл обновлений настольных операционных систем, который подразумевает под собой не только (отдельные) текущие обновления, но так же и глобальные доработки, приводящие к (прозрачному) переходу к следующим редакциям ОС.
хотите еще больше информации об обслуживании на основе компонентов?
Ошибки центра обновления Windows
Как и во множестве иных компонентов, входящих в состав операционных систем Microsoft, вопрос о исчерпывающей информативности возникающих ошибок Центра обновления Windows, тем более рекомендаций по их устранению, никогда всерьез разработчиками не рассматривался :) Традиционно было решено ввести огроменный перечень числовых статусов (для того, чтобы хотя бы отдаленно понимать о чем идет речь) и завести специализированные танцесбубновые форумы поддержки (как например, незабвенный TechNet), на которых зачастую предлагаются довольно-таки абстрактные рекомендации. Все это, конечно же, сарказм, тем более что для человека думающего, подобные приведенному выше ресурсу является превосходной отправной точкой, задающей верное направление движения. Ну а в данном материале мы попытаемся каталогизировать ошибки Центра обновления Windows.
Сброс центра обновления Windows
Центр обновления Windows является механизмом операционной системы, который имеет множество точек потенциального отказа: ошибки в структуре зависимостей (связности) обновлений друг с другом, нестабильная среда передачи данных (клиент-сервер), превышение жестко заданного размера различных внутренних структур (к примеру: списков обновлений), повреждение файлов хранилища компонентов, повреждение базы/каталога распространения, задвоение идентификаторов клиентов и многое многое другое. Ошибок, возникающих в процессе работы Центра обновления Windows, более чем достаточно, по самым скромным подсчетам имеется порядка 700 событий отказа. На различных этапах функционирования центра обновлений Windows: получения, обработки и установки обновлений, данные пакетов обновлений могут повреждаться, либо сами обновления могут переходить в неустанавливаемое состояние из-за отсутствующих/поврежденных зависимостей. На основании изложенного, к слову сказать, далеко не полного перечня проблем центра обновления Windows, можно прийти к выводу, что вероятность сбоев в его работе довольно высока, что фактически и подтверждается миллионами сообщений на данную тематику с официальных форумов Microsoft. Результатом сбоев для конечного пользователя является возникновение разного рода отказов (ошибок) в процессе установки обновлений операционной системы.
Восстановление хранилища компонентов
В процессе работы разнообразных диагностических и сервисных утилит (модули, входящие в состав Центра обновления Windows), может быть выявлено повреждение хранилища компонентов WinSxS, о чем в лог-файлах нам красноречиво сигнализирует статус ERROR_SXS_COMPONENT_STORE_CORRUPT. Основные причины повреждения хранилища компонентов заключаются в том, что:
- в процессе обновления операционной системы могут повреждаться/удаляться файлы компонентов в местоположениях с корнем в: %SYSTEMROOT%\Servicing\Packages и %SYSTEMROOT%\WinSxS;
- в процессе обновления операционной системы могут повреждаться/удаляться ветви/ключи реестра в местоположениях: HKLM\Components, HKLM\Schema и HKLM\Software\Microsoft\Windows\CurrentVersion\Component Based Servicing;
Описанные проблемы впоследствии становятся причиной возникновения различного рода отказов установки обновлений. Повреждение/удаление файлов происходит по совершенно разнообразным причинам: сбои в сетевых модулях, дисковой подсистеме, ошибки чтения/записи оперативной памяти, аппаратные сбои любых компонентов станции, или же по причине ошибок в коде компонентов Центра обновления Windows. Чаще всего повреждаются *.cat, *.mum, *.manifest и *.dll-файлы. Все найденные методы восстановления хранилища компонентов я решил выделить в отдельную статью. И так, для восстановления хранилища компонентов у нас в распоряжении несколько разнообразных методик.
