Debugger can't get KD version information

18.09.2019  ·  в Отладка Windows  ·  комментарии: 0
Метки:  , ,

Иногда приходится наблюдать инциденты, когда при запуске отладчика 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

Обслуживание на основе компонентов

03.08.2019  ·  в Обновление Windows  ·  комментарии: 0
Метки:  , , , , , , , , , , , , , ,

Наверняка уже ни для кого не секрет, что как и в любом (без исключения) программном обеспечении, в коде операционных систем присутствуют ошибки. Периодически тем или иным образом их удается обнаружить, о чем рано или поздно узнает разработчик, в чьих интересах производить оперативное устранение найденных проблем. Но мало выпустить исправление (заплатку/патч), изменения эти требуется еще как-то доставить до пользовательских операционных систем, функционирующих по всему земному шару. Помимо ошибок, на всем протяжении цикла поддержки операционной системы, в неё добавляются и новые функциональные возможности. Все перечисленные виды вносимых в систему изменений (исправления, обновления, дополнения) на данный момент принято обобщать в огромный комплекс задач под названием обслуживание операционной системы.
С появлением и развитием сети Интернет, методы доставки контента обслуживания до географически-удаленных операционных систем претерпели существенные изменения: сперва в виде доступных на сайте Microsoft для скачивания файлов, затем, по мере развития архитектуры операционных систем и, в частности, алгоритмов обновления, трансформировались в сложные многоуровневые сервисы, производящие автоматическую загрузку и обновление. В последнее время Microsoft запустила уже непрерывный цикл обновлений настольных операционных систем, который подразумевает под собой не только (отдельные) текущие обновления, но так же и глобальные доработки, приводящие к (прозрачному) переходу к следующим редакциям ОС.

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

Ошибки центра обновления Windows

01.07.2019  ·  в Обновление Windows  ·  комментарии: 0
Метки:  , , , ,

Как и во множестве иных компонентов, входящих в состав операционных систем Microsoft, вопрос о исчерпывающей информативности возникающих ошибок Центра обновления Windows, тем более рекомендаций по их устранению, никогда всерьез разработчиками не рассматривался :) Традиционно было решено ввести огроменный перечень числовых статусов (для того, чтобы хотя бы отдаленно понимать о чем идет речь) и завести специализированные танцесбубновые форумы поддержки (как например, незабвенный TechNet), на которых зачастую предлагаются довольно-таки абстрактные рекомендации. Все это, конечно же, сарказм, тем более что для человека думающего, подобные приведенному выше ресурсу является превосходной отправной точкой, задающей верное направление движения. Ну а в данном материале мы попытаемся каталогизировать ошибки Центра обновления Windows.

перейти к каталогу ошибок Центра обновления Windows

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

06.06.2019  ·  в Обновление Windows  ·  комментарии: 0
Метки:  , , , , , ,

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

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

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

28.05.2019  ·  в Обновление Windows  ·  комментария 2
Метки:  , , , , , ,

В процессе работы разнообразных диагностических и сервисных утилит (модули, входящие в состав Центра обновления Windows), может быть выявлено повреждение хранилища компонентов WinSxS, о чем в лог-файлах нам красноречиво сигнализирует статус ERROR_SXS_COMPONENT_STORE_CORRUPT. Основные причины повреждения хранилища компонентов заключаются в том, что:

  • в процессе обновления операционной системы могут повреждаться/удаляться файлы компонентов в местоположениях: %SYSTEMROOT%\Servicing\Packages и %SYSTEMROOT%\WinSxS\Manifests;
  • в процессе обновления операционной системы могут повреждаться/удаляться ветви/ключи реестра в местоположениях: HKLM\Components, HKLM\Schema и HKLM\Software\Microsoft\Windows\CurrentVersion\Component Based Servicing;

Описанные проблемы впоследствии становятся причиной возникновения различного рода отказов установки обновлений. Повреждение/удаление файлов происходит по совершенно разнообразным причинам: сбои в сетевых модулях, дисковой подсистеме, ошибки чтения/записи оперативной памяти, аппаратные сбои любых компонентов станции, или же по причине ошибок в коде компонентов Центра обновления Windows. Чаще всего повреждаются *.cat, *.mum, *.manifest и *.dll-файлы. Все найденные методы восстановления хранилища компонентов я решил выделить в отдельную статью. И так, для восстановления хранилища компонентов у нас в распоряжении несколько разнообразных методик.

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

Шторм прерываний

29.04.2019  ·  в Диагностика Windows  ·  комментарии: 0
Метки:  , , , , , , , , , , , , , , , , ,
Открытая статья. В процессе доработки.

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

interrupt storm

больше информации о шторме прерываний

Останов на точке входа приложения в WinDbg

27.03.2019  ·  в Отладка Windows  ·  комментарии: 0
Метки:  ,

Как то раз столкнулся с интересной проблемой при открытии исполняемого файла в WinDbg на отладку. Для опытного реверсера ситуация, скорее всего, достаточно тривиальная, тем не менее с ней из раза в раз сталкиваются те, кто впервые пытается отладить типовой исполняемый модуль (.exe) при помощи отладчика WinDbg. Заключается она в том, что совершенно непонятно как поставить точку останова на непосредственно в точку входа, то есть на первую инструкцию (основной функции) отлаживаемого исполняемого файла. Обычно для отладки приложение открывается через меню File - Open Executable... (или просто нажатием комбинации клавиш Ctrl+E). По умолчанию, после загрузки исполняемого файла, отладчик останавливается задолго до начала непосредственно кода самой программы, где-то глубоко в коде загрузчика образов Windows. Вот типичный пример:

Узнать больше об останове на точке входа приложения

Последовательность вызова функций

07.02.2019  ·  в Отладка Windows  ·  комментарии: 0
Метки:  , ,

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

portcls!PcHandlePropertyWithTable+0x1b

Очевидно, что приведен всего-лишь общий вид записи, но нам интересна сегодня, в первую очередь, сама структура данной записи. В приведенном выше формате отладчик выводит данные о вызываемых в ходе выполнения кода функциях. Формат записи в стеке вызовов следующий:

Больше о последовательности вызова функций

Контекст устройства отображения

15.01.2019  ·  в Ассемблер Windows  ·  комментарии: 0
Метки:  ,

В многозадачной операционной системе семейства Windows отсутствует возможность прямого бесконтрольного вывода на экран (как это было во времена MSDOS), тут все подчинено некоему регламенту. С целью обеспечения возможности вывода на устройство (экран, принтер, память) одновременно от множества источников (приложений), в Windows был создан специализированный механизм под названием контекст устройства (device context, DC) и подмножество обеспечивающих его работу функций. Указанные функции определяют размер клиентской области, шрифт, цвета и другие GDI-атрибуты и возвращают (предоставляют) приложению так называемый дескриптор контекста устройства (Device Context Descriptor). Поскольку контекст устройства является одним из основополагающих понятий в понимании механизмов вывода информации на устройство, я постараюсь дать некоторое количество определений для погружения в тему:

больше информации о контексте устройства

Консольное приложение на ассемблере

01.12.2018  ·  в Ассемблер Windows  ·  комментарии: 0
Метки:  , , , , , , , , , ,

После разработки серии оконных приложений, мы познакомились с основными принципами программирования графических примитивов. И тут дернула меня нечистая написать простую программку для решения специфической микрозадачи. Понятное дело, что использовать оконный интерфейс для подобного случая не очень то и хотелось, поэтому было решено сделать приложение консольным .. лучше бы я в этот огород вообще не лез! :) Ну уж, как говорится "взялся за гуж, не говори что не дюж".
Было бы бессмысленно отрицать, что в последние десятилетия роль графического интерфейса существенно возросла, тем не менее в новейших операционных системах текстовые режимы всё еще сохраняются в виде разнообразных графических подсистем, в частности - текстового пользовательского интерфейса (окна командной строки/терминала). Из этого следует, что если уж текстовый режим до сей поры присутствует в операционных системах, значит он не является исключительно аппаратным рудиментом, поддержка которого существует лишь на уровне видеоадаптера, а представляет собой актуальный и активно используемый механизм. Основная причина по которой текстовый режим всё еще существует, заключается в следующем:

Большое количество системных утилит, входящих в состав операционной системы, используют исключительно текстовый интерфейс и рассчитаны на использование аргументов командной строки.

еще о консольном приложении на ассемблере

Помощь сайту