Kdfe - анализ аварийного дампа памяти

Метки:  , ,

Данная публикация продолжает серию статей по обзору инструментов анализа аварийных дампов системы. В своем арсенале отладки современный специалист имеет еще одно достаточно полезное средство - это скрипт автоматизации отладчика ядра под названием kdfe. Kdfe расшифровывается как Kernel Debugger Front End, то есть интерфейс или надстройка для взаимодействия пользователя с ядерным отладчиком kd.exe (Kernel Debugger) на достаточно простом и понятном уровне. Фактически, kdfe представляет из себя скрипт, который автоматизирует определенные действия пользователя и позволяет в достаточно сжатый промежуток времени получить анализ аварийного дампа памяти системы, либо полностью автоматизировать действия по получению результата анализа и использовать их в более развитых и глобальных автоматизированный системах (правда в этом случае скрипт придется слегка поправить). В стандартном режиме kdfe перенаправляет вывод отладчика ядра kd.exe, что позволяет использовать только необходимые выходные данные отладчика. Можно говорить о том, что если бы не было kdfe, то нам бы пришлось вручную анализировать аварийный дамп памяти системы непосредственно в консоли при помощи ручного запуска отладчика ядра kd с определенными параметрами, что, согласитесь, менее удобно и более времязатратно. Автор скрипта, Александр Суховей (Alexander Suhovey), несомненно создал отличный инструментарий, за что хотелось бы сказать ему отдельное спасибо и за весомый вклад в науку отладки и сэкономленное время.

Подготовка к анализу

Как было уже сказано ранее, скрипт kdfe требует наличия в системе отладчика ядра kd.exe, входящего в состав комплекта Debugging Tools for Windows. Из этого следует, что нам требуется, в начале, установить Debugging Tools for Windows.

На следующем этапе нам необходимо получить в свое распоряжение сам скрипт kdfe. В сети мне удалось найти сайт, носящий название abandoned blog, который оказался домашней страницей автора скрипта. Могу предположить, что сайт давно не обновляется, поэтому я решил, на всякий случай, продублировать скрипт и на своем ресурсе.

Скачать: kdfe

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

После того, как мы получили в своё распоряжение скрипт, давайте теперь уже приступим непосредственно к работе. Лично я обычно помещаю все скрипты во временную папку (системная переменная %TEMP%), у меня она ссылается, по традиции, на C:\TEMP.
Еще один немаловажный момент у нас заключается в использовании символов. В принципе, определение символов у нас дано в других статьях, однако освежим свои знания:

Для анализа дампа памяти отладчику требуются символьные файлы компонентов системы.

У нас есть два варианта решения данной проблемы:

  • Скачать символы самостоятельно. Символы можно загрузить с сайта Microsoft, по ссылке пакеты символов Windows. Однако, последнее время вручную символы мало кто скачивает, потому что полный пакет довольно внушителен по размеру и качаться он будет долго, в добавок ко всему есть шанс ошибиться при выборе.
  • Скачивать символы автоматически. Современные отладочные средства умеют получать информацию о символах самостоятельно из сети интернет, для этого их необходимо предварительно на это настроить. Причем плюс данного подхода заключается в том, что отладчик скачает необходимые символы, то есть символы именно той системы, на которой создавался дамп, а не той, на которой происходит анализ.

Вам необходимы символы для той системы, которая создала дамп памяти, но не для той системы, на который Вы этот дамп анализируете!

Скрипт kdfe написан таким образом, чтобы указывать отладчику kd скачивать с сервера символов Microsoft только необходимые символьные файлы для работы с конкретным дампом памяти и сохранять их локально на диске для последующего использования. Задается это в скрипте при помощи переменной smbpath, которая указывает каталог, в который kd.exe будет сохранять необходимые файлы. По-умолчанию это %SYSTEMDRIVE%\symbols, соответственно, в большинстве случаев это C:\symbols. Надо ли вручную создавать эту директорию, либо kd создаст её сам?

Запуск скрипта

Если дамп для анализа у Вас располагается в стандартных директориях расположения дампов, то можно просто вызвать скрипт без параметров:

kdfe

Если же дамп у Вас расположен в местоположении, отличном от классических директорий, то можно вызвать скрипт с параметром полного пути к исследуемому дампу:

kdfe d:\junk\memory.dmp

Непосредственно после запуска скрипт kdfe определяет рабочую директорию средств отладки (Debugging Tools for Windows). Среди возможных вариантов перебираются все возможные пути установки средств отладки. Необходимо это для того, чтобы адресно запускать отладчик ядра kd.exe с указанием полного пути до исполняемого файла.

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

Если скрипт kdfe без параметров командной строки, то он анализирует параметры ветки реестра HKLM\SYSTEM\CurrentControlSet\Control\CrashControl и использует сконфигурированные в параметрах DumpFile и MinidumpDir места расположения дампов в системе. После этого сканирует директории и выводит все обнаруженные файлы дампов в виде меню выбора, предлагая пользователю указать требуемый файл дампа для анализа:

kdfe анализ аварийного дампа bsod

Соответственно, после того, как пользователь выбирает дамп для анализа, скрипт kdfe запускает отладчик kd.exe с определенными параметрами командной строки, дожидается результатов, фильтрует вывод отладчика и перенаправляет его на консоль.

Анализ некоторых дампов может занимать продолжительное время. Наберитесь терпения.

Анализ результатов

Теперь пришло время проанализировать вывод, предоставленный нам скриптом kdfe.

Параметр Описание
Crash date Дата и время произошедшего сбоя.
Stop error code Код СТОП-ошибки (BugCheck). В нашем случае это STOP 0x00000124.
Process name Сообщает имя процесса, в контексте которого произошел сбой.
Probably caused by Выводится возможный источник проблемы.

Прежде всего, нас интересует главный и самый важный параметр, который выводится после строки probably caused by. В нем обозначается источник проблемы, то есть причина синего экрана смерти BSOD. По выводу мы можем понять, что в данном конкретном случае виновато некое оборудование (hardware). Слегка забегая вперед скажу, что виновником оказался процессор. Да, да, да, сам был сильно удивлен, потому как столкнулся с подобным впервые, но после долгой диагностики всего железа с последующей заменой частей, последним вариантом оказался именно процессор. Итогом всего этого стала замена процессора, и вот только после этого синие экраны прекратились.
Однако, в большинстве случаев виновниками синих экранов являются драйвера, в подобном случае в строке probably caused by мы можем увидеть что-то вроде igxpdv32.dll. В этом случае необходимо понять, что именно это за драйвер и скачать+установить более новую либо более старую стабильную версию.
Довольно часто рекомендуется обращать внимание так же и на строку Process name, поскольку проблема бывает многосоставная и в этом параметре указывается контекст процесса, или виновник более общего, высокого уровня. Например, исполняемый .exe-файл какой-либо программы, библиотека .dll, и зачастую проблема может быть в указанной программе, а не в драйвере/компоненте. Дополнительно, имейте эту информацию в виду, и если проблема не устранилась непосредственной работой с источником, указанным в строке probably caused by, то попробуйте переустановить/обновить/удалить данную программу.

  • Поделиться:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *