Как и во множестве иных компонентов, входящих в состав операционных систем Microsoft, вопрос о исчерпывающей информативности возникающих ошибок Центра обновления Windows, тем более рекомендаций по их устранению, никогда всерьез разработчиками не рассматривался :) Традиционно было решено ввести огроменный перечень числовых статусов (для того, чтобы хотя бы отдаленно понимать о чем идет речь) и завести специализированные танцесбубновые форумы поддержки (как например, незабвенный TechNet), на которых маститые сертифицированные специалисты зачастую предлагают довольно абстрактные рекомендации. Все это, конечно же, сарказм, тем более что для человека думающего, подобные приведенному выше ресурсу является превосходной отправной точкой, задающей верное направление движения. Ну а в данном материале мы попытаемся каталогизировать ошибки Центра обновления Windows.
Сброс центра обновления Windows
Центр обновления Windows является механизмом операционной системы, который имеет множество точек потенциального отказа: ошибки в структуре зависимостей (связности) обновлений друг с другом, нестабильная среда передачи данных (клиент-сервер), превышение жестко заданного размера различных внутренних структур (к примеру: списков обновлений), повреждение файлов хранилища компонентов, повреждение базы/каталога распространения, задвоение идентификаторов клиентов и многое многое другое. Ошибок, возникающих в процессе работы Центра обновления Windows, более чем достаточно, по самым скромным подсчетам имеется порядка 700 событий отказа. На различных этапах функционирования центра обновлений Windows: получения, обработки и установки обновлений, данные пакетов обновлений могут повреждаться, либо сами обновления могут переходить в неустанавливаемое состояние из-за отсутствующих/поврежденных зависимостей. На основании изложенного, к слову сказать, далеко не полного перечня проблем центра обновления Windows, можно прийти к выводу, что вероятность сбоев в его работе довольно высока, что фактически и подтверждается миллионами сообщений на данную тематику с официальных форумов Microsoft. Результатом сбоев для конечного пользователя является возникновение разного рода отказов (ошибок) в процессе установки обновлений операционной системы.
Восстановление хранилища компонентов
В процессе работы диагностической утилиты sfc, а так иных диагностических средств, может быть выявлено повреждение хранилища компонентов WinSxS, о чем в логах красноречиво говорит статус ERROR_SXS_COMPONENT_STORE_CORRUPT. В этом случае утилита sfc самостоятельно не может завершить процедуру проверки/восстановления. Причиной повреждения хранилища компонентов заключается в том, что в процессе штатной установки обновлений, в системе могут появляться "битые" файлы, которые затем способствуют возникновению отказов установки. Появляются они по причине сбоев в сетевых модулях, дисковой подсистеме, ошибок оперативной памяти или попросту аппаратных проблем, или же по причине ошибок в коде компонентов Центра обновления Windows. Чаще всего повреждаются *.cat, *.mum, *.manifest и *.dll-файлы. Все найденные методы восстановления хранилища компонентов я решил выделить в отдельную статью. И так, для восстановления хранилища компонентов у нас в распоряжении несколько разнообразных методик.
Шторм прерываний
В процессе работы с операционной системой Windows, пользователь может столкнуться с ощутимым снижением производительности рабочей станции. Естественно первое, что приходит на ум, это воспользоваться встроенным диагностическим средством под названием Диспетчер задач, при вызове которого на проблемной станции можно лицезреть следующую картину:
Останов на точке входа приложения в WinDbg
Как то раз столкнулся с интересной проблемой при открытии исполняемого файла в WinDbg на отладку. Для опытного реверсера ситуация, скорее всего, достаточно тривиальная, тем не менее с ней из раза в раз сталкиваются те, кто впервые пытается отладить типовой исполняемый модуль (.exe) при помощи отладчика WinDbg. Заключается она в том, что совершенно непонятно как поставить точку останова на непосредственно в точку входа, то есть на первую инструкцию (основной функции) отлаживаемого исполняемого файла. Обычно для отладки приложение открывается через меню File - Open Executable... (или просто нажатием комбинации клавиш Ctrl+E). По умолчанию, после загрузки исполняемого файла, отладчик останавливается задолго до начала непосредственно кода самой программы, где-то глубоко в коде загрузчика образов Windows. Вот типичный пример:
Последовательность вызова функций
Многие специалисты, по роду своей деятельности сталкивающиеся с исследованием различных модулей, анализом причин тех или иных сбоев и проводящие иную аналогичную работу, в своей практике часто сталкиваются с таким понятием как стек вызовов. Очевидно, что он фактически представляет собой очередность вызова функций в контексте выполняющегося потока. С первого взгляда может показаться, что стек вызовов достаточно тривиален, тем не менее, в нем далеко не все так очевидно, как хотелось бы, и поэтому я решил набросать (прежде всего для себя самого) небольшую шпаргалку относительно некоторых важных деталей. Помимо последовательности вызова функций, так же неплохо было бы обсудить формат описания функций в стеке, да и некоторые другие нюансы. Тем, кому доводилось работать с различного рода задачами в отладчиках, к примеру, над изучением различного рода дампов памяти, или отладкой приложения, понимали, что одним из центральных аспектов является так называемый стек вызовов потока, который представляет собой список, состоящий из записей вида:
portcls!PcHandlePropertyWithTable+0x1b
Очевидно, что приведен всего-лишь общий вид записи, но нам интересна сегодня, в первую очередь, сама структура данной записи. В приведенном выше формате отладчик выводит данные о вызываемых в ходе выполнения кода функциях. Формат записи в стеке вызовов следующий:
Контекст устройства отображения
В многозадачной операционной системе семейства Windows отсутствует возможность прямого бесконтрольного вывода на экран (как это было во времена MSDOS), тут все подчинено некоему регламенту. С целью обеспечения возможности вывода на устройство (экран, принтер, память) одновременно от множества источников (приложений), в Windows был создан специализированный механизм под названием контекст устройства (device context, DC) и подмножество обеспечивающих его работу функций. Указанные функции определяют размер клиентской области, шрифт, цвета и другие GDI-атрибуты и возвращают (предоставляют) приложению так называемый дескриптор контекста устройства (Device Context Descriptor). Поскольку контекст устройства является одним из основополагающих понятий в понимании механизмов вывода информации на устройство, я постараюсь дать некоторое количество определений для погружения в тему:
Консольное приложение на ассемблере
После разработки серии оконных приложений, мы познакомились с основными принципами программирования графических примитивов. И тут дернула меня нечистая написать простую программку для решения специфической микрозадачи. Понятное дело, что использовать оконный интерфейс для подобного случая не очень то и хотелось, поэтому было решено сделать приложение консольным .. лучше бы я в этот огород вообще не лез! :) Ну уж, как говорится "взялся за гуж, не говори что не дюж".
Было бы бессмысленно отрицать, что в последние десятилетия роль графического интерфейса существенно возросла, тем не менее в новейших операционных системах текстовые режимы всё еще сохраняются в виде разнообразных графических подсистем, в частности - текстового пользовательского интерфейса (окна командной строки/терминала). Из этого следует, что если уж текстовый режим до сей поры присутствует в операционных системах, значит он не является исключительно аппаратным рудиментом, поддержка которого существует лишь на уровне видеоадаптера, а представляет собой актуальный и активно используемый механизм. Основная причина по которой текстовый режим всё еще существует, заключается в следующем:
STOP 0x00000033
Критическая ошибка STOP 00000033 имеет символическое имя UNEXPECTED_INITIALIZATION_CALL (НЕПРЕДУСМОТРЕННЫЙ_СИСТЕМНЫЙ_ВЫЗОВ). По задумке разработчиков, данный системный сбой должен сообщать нам о некоем "неожиданном" системном вызове, который по идее, не должен был быть осуществлен в той ситуации (контекст работы, глобальные флаги и переменные), в которой он произошел. Как всегда у Microsoft с классификацией ошибок черт ногу сломит, и порой довольно сложно понять причину только лишь по символическому имени :) Иначе говоря, если вы видите останов STOP 00000033, то возникла ситуация, в которой в контексте (процесса/потока) ядра, был выполнен вызов внутренней функции одного из этапов инициализации и в этот самый момент ядро находилось в фазе, в которой оно в данный момент не должно было находиться. В общем то, как вы сможете увидеть далее в статье, символическое имя не лишено смысла, поскольку в некоторым алгоритмическим нюансам сложно бывает придумать внятное описание.
ci.dll - библиотека проверки цифровых подписей
И последним этапом в цепочке проверки целостности кода стадии загрузки 32-битной операционной системы Windows 7 является библиотека ci.dll (именуемая разработчиками Модулем Целостности Кода, Code Integrity Module). Данный компонент впервые появился в операционной системе Windows 7 и в своем составе имеет функции, обеспечивающие проверку целостности бинарных образов на этапе отображения/загрузки в адресное пространство ядра. Таким образом, можно сделать вывод, что фактически проверке по задумке разработчиков, подлежат только ключевые образы, являющиеся для системы критичными в плане безопасности. Область действия функционала ci.dll ограничивается только локальной системой, то есть той, на которой непосредственно происходит выполнение кода функций, иначе говоря библиотека является ни чем иным как изолированным идентификатором безопасности локальной системы.
Теперь, собственно, сделаем небольшое отступление для того, что бы дать краткое описание необходимых для понимания происходящего механизмов. С определенного времени в Windows появились так называемые сертификаты подписи кода.
