null

WinDBG и анализ дампов памяти BSOD

В прошлой статье была рассмотрена утилита WinDBG  и ее установка. Теперь же перейдем непосредственно к работе с ней.

Запускаем утилиту, скармливаем ей дамп памяти, видим нечто подобное:

 

Основное окно и окно команд отладчика независимы друг от друга, что достаточно удобно для изменения их расположения для одновременного просмотра, разворачивания окна по выбору на весь экран и тп.

После открытия файла дампа памяти WinDBG некоторое время подтягивает недостающие символы для отладки через сеть, поэтому придется подождать некоторое время. Во время загрузки в командной строке мы видим сообщение Debugee not connected, сигнализирующее о невозможности использования отладчика в данное время.

Как только в нижней части текстового окна мы увидим соощение Followup: MachineOwner , отладчик готов к работе.

Для начала, обратим внимание на коды ошибок, это может значительно скоратить время работы по поиску причин неисправности.

Коды ошибок отображаются в шестнадцатеричной форме вида 0xXXXXXXXX , или же в форматах

  • STOP: 0x0000009F
  • 03.06.2015 0009F
  • 0x9F

Microsoft предлагает обратится к их Bug Check Code Reference, где указаны коды ошибок и их описание.

Исходя из опыта и многочисленных описанных случаев в сети, можно выделить часто встречающиеся ошибки типа 0x124 - чаще всего аппаратная проблема, 0x116 - проблема с драйвером видеоподсистемы или аппаратный сбой самой видеокарты.

Рассмотрим алгоритм поиска конкретного драйвера(как наиболее частой причины BSOD-a), вызывающего сбой системы.

Выполняем в дебаггере команду

 !thread

после чего ищем значения Base и Limit

Допустим, получили

 Base ffff080500b9b000 Limit ffff080500b95000

следующим шагом выполняем команду dps ,указав аргументами значения Limit и Base , полученные нами выше - обратите внимание: сначала указывается Limit , потом Base (обратный порядок от результатов выполнения !thread)

В нашем случае это

 dps ffff080500b95000 ffff080500b9b000 

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

Предположим, нашли проблемный драйвер. Удаление через диспетчер устройств  может быть неполным, поэтому выполняем в командной строке( от имени администратора)

driverquery /v > "%USERPROFILE%\Desktop\drivers.txt"

Результатом станет текстовый документ со списком всех драйверов и их местоположением. Ищем проблемный, удаляем вручную.

Также полезным может оказаться средство проверки драйверов Windows, работу с которым рассмотрим в отдельной статье.

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

Коротко о себе:

Работаю инженером в компании Tune IT.

Ничего не найдено. n is 0