STOP 0x0000006B

Метки:  , , , ,

Статья дополняет серию материалов, освещающих методы устранения проблем, приводящих к возникновению критической системной ошибки (BSOD). В материалах раздела рассматриваются ситуации, с которыми я сталкивался лично (в своей практике) и с которыми мне удалось разобраться. STOP-ошибка (STOP error), контроль дефекта (BugCheck) или в простонародье BSOD - фатальный системный сбой операционной системы Windows, являющийся причиной полного прекращения функционирования основных компонентов ядра операционной системы, влекущий за собой потерю динамических не сохраненных пользовательских данных и приводящий к появлению на экране монитора синего экрана смерти (BSOD). Числовое обозначение STOP-ошибки - идентификатор, характеризующий "природу" фатальной системной ошибки, используется при диагностике причины возникшей неполадки. В данной статье речь пойдет о сбое с идентификатором STOP 0000006B.

Подробнее о сбое STOP 0x0000006B

Восстановление хранилища компонентов при помощи средства проверки готовности системы к обновлению (SURT)

Метки:  , , , , , ,

Сегодня вашему вниманию предоставляется еще одно пополнение цикла статей о методах восстановления хранилища компонентов Windows. Помимо изобретения широкой общественностью бесчисленного множества "наколеночных" методик восстановления работоспособности компонентной модели, сами разработчики из Microsoft предлагают вполне официальные методы. В данной публикации мы рассмотрим один из подобных методов, который заключается в восстановлении хранилища компонентов при помощи средства проверки готовности системы к обновлению или, иными словами восстановлении хранилища компонентов при помощи SURT. Фактически описываемым методом предусматривается проверка каталогов/файлов компонентной модели при помощи специализированного пакета и попытка устранения найденных ошибок.

Метод подходит только для операционной системы Windows 7. Для более новых ОС (Windows 8+) средство SURT не требуется, поскольку весь функционал интегрирован в систему и доступен через API стека обслуживания, из скриптов Powershell и сервисной утилиты dism.exe. Это подтверждают высказывания некоторых сотрудников Microsoft: Instead of needing to download and run a separate tool, the diagnostic and repair functionality in the System Update Readiness Tool is now built into Windows in Windows 8 and Windows Server 2012.

больше о восстановлении хранилища компонентов при помощи средства SURT

Восстановление компонента прямой заменой файлов

Метки:  , , ,

Продолжаем цикл статей о разнообразных правильных (а порой и не очень) методах восстановления компонентов в рамках компонентной модели Windows. Честно говоря, подобные описанному в данном посте "кривому" методу восстановления работоспособности компонентной модели рождаются вовсе не от хорошей жизни, появляются они под воздействием многочисленных проблем с компонентами операционной системы. Во многих случаях официальные методы восстановления хранилища компонентов (dism и аналоги) не помогают, помимо этого отсутствует какая бы то ни было внятная официальная документация, из чего складывается недопонимание структуры и принципов работы компонентной модели. При подобном отношении со стороны разработчиков абсолютно любые средства вернуть компонентную модель в работоспособное состояние хороши!! В данной публикации речь пойдет о восстановлении компонента прямой заменой файлов. Фактически методом предусматривается прямая ручная замена поврежденных [кривых, неправильно функционирующих] файлов, являющихся причиной возникновения ошибок. Исправные файлы копируются с работоспособной станции-донора. Узкое место метода заключается в том, что для реализации требуется наличие находящейся на том же уровне обновлений нормально функционирующей операционной системы той же версии.

Описанный в статье метод рекомендуется к использованию только в критических случаях, поскольку представляет собой довольно непрофессиональную попытку замены файлов компонентов. С другой стороны, качество реализации компонентной модели в операционных системах Windows Vista/7 является моральным оправданием любых доступных методик восстановления работоспособности системы.

далее про восстановление компонента методом прямой замены файлов

Ошибка обновления 0x80092004

Метки:  , , , ,

Настало радостное мгновение и корпорация Microsoft в очередной раз порадовала своих поклонников заплатками для систем Windows 7 и Windows Server 2008R2. При этом, все бы замечательно, если бы обновления устанавливались безотказно всегда и везде. Тем не менее, памятуя о том, что подсистема обслуживания на основе компонентов находится в перманентной бэте, процесс установки любого обновления от Microsoft представляет собой эксперимент с непрогнозируемым результатом. Так вышло и в ситуации, послужившей основой данной статьи: под руку попалась система, на которой установка обновлений KB4512486, KB4516033, KB4520003, KB4525233, KB4523206 и KB4525235 завершается с ошибкой 0x80092004. Ошибку можно лицезреть в Центре обновления Windows в следующем виде:

wsus 80092004

больше информации по ошибке 80092004

Зависает на classpnp.sys

Метки:  , , , , , , , , , ,

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

classpnp.sys

читать далее по теме зависает на classpnp.sys

Debugger can't get KD version information

Метки:  , ,

Иногда приходится наблюдать инциденты, когда при запуске отладчика WinDbg в режиме локальной отладки ядра (local kernel debugging), возникает следующая ошибка: Debugger can't get KD version information, Win32 error 0n5.

cant get kd version

Ошибка возникает не смотря даже на то, что отладчик 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 является механизмом операционной системы, который имеет множество точек потенциального отказа: ошибки в структуре зависимостей (связности) обновлений друг с другом, нестабильная среда передачи данных (клиент-сервер), превышение жестко заданного размера различных внутренних структур (к примеру: списков обновлений), повреждение файлов хранилища компонентов, повреждение базы/каталога распространения, задвоение идентификаторов клиентов и многое многое другое. Ошибок, возникающих в процессе работы Центра обновления Windows, более чем достаточно, по самым скромным подсчетам имеется порядка 700 событий отказа. На различных этапах функционирования центра обновлений Windows: получения, обработки и установки обновлений, данные пакетов обновлений могут повреждаться, либо сами обновления могут переходить в неустанавливаемое состояние из-за отсутствующих/поврежденных зависимостей. На основании изложенного, к слову сказать, далеко не полного перечня проблем центра обновления Windows, можно прийти к выводу, что вероятность сбоев в его работе довольно высока, что фактически и подтверждается миллионами сообщений на данную тематику с официальных форумов Microsoft. Результатом сбоев для конечного пользователя является возникновение разного рода отказов (ошибок) в процессе установки обновлений операционной системы.

алгоритм сброса центра обновления Windows

Восстановление хранилища компонентов

Метки:  , , , , ,

В процессе работы разнообразных диагностических и сервисных утилит (модули, входящие в состав Центра обновления 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-файлы. Все найденные методы восстановления хранилища компонентов я решил выделить в отдельную статью. И так, для восстановления хранилища компонентов у нас в распоряжении несколько разнообразных методик.

больше информации о восстановлении хранилища компонентов