Анализ дампов после BSOD с помощью Debugging Tools for Windows

Автор: | 18.02.2014

Debugging Tools for Windows – это набор утилит от Microsoft, предназначенный для разработчиков и администраторов. Установщик можно бесплатно скачать по ссылке — http://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx. Перед этим, вам нужно выбрать версию ОС, в которой вы будете использовать утилиты.

Debugging Tools for Windows - URL

Если вы разработчик драйверов и используете DDK то Debugging Tools for Windows входит туда, и его установку можно выбрать при установке DDK.

После перехода по ссылке, будет загружен веб установщик, который предложит установить Windows SDK (Software Development Kit), в который входит и Debugging Tools.

В ходе установки, вы можете выбрать только Debugging Tools

Установка Debugging Tools for Windows

После того, как установка завершится, вам нужно найти один из файлов установки Debugging Tools. В моей Windows XP SP3 (x86) файлы установки находятся по пути — C:Program FilesMicrosoft SDKsWindowsv7.1RedistDebugging Tools for Windows. Запускаем файл dbg_x86.msi и выполняем установку.

Установка Debugging Tools for Windows - 2

В моей системе набор программ для отладки Debugging Tools по-умолчанию установился в каталог «C:Program FilesDebugging Tools for Windows (x86)»

Теперь нам необходим фал дампа. О том, где его взять вы можете почитать на главной странице – здесь. Если его нет, вы можете его создать с помощью утилиты NotMyFault. Давайте так и поступим, при этом, в качестве ошибки в драйвере, мы выберем DRIVER_IRQL_NOT_LESS_OR_EQUAL. Запускаем программу, выбираем “Hihg IRQL fault (Kernel-mode)” и нажимаем “Crash”. Поскольку в Windows XP, которую я использую, по-умолчанию тип дампа – малый дамп (смотрите здесь — о типах дампов), файл дампа можно найти в каталоге %Systemroot%minidump (c:windowsminidump).

Среди утилит, которые входят в Debugging Tools есть несколько, с помощью которых можно анализировать файлы дампов:

  • windbg.exe
  • dumpchk.exe
  • dumpexam.exe
  • kd.exe

Одной из самых простых программ является dumpchk.exe. Давайте запустим ее и перенаправим вывод в файл. Мы получим приблизительно следующий результат (см. вложенный файл ниже)

По результатам анализа можно обратить внимание на следующую важную информацию.

1. Код ошибки (стоп-код) и его параметры, в файле — BugCheck 100000D1, {e2ee9008, 2, 0, badbc5ab}.

2. Строку с названием драйвера, который по мнению утилиты, привел к BSOD — Probably caused by : myfault.sys ( myfault+5ab )

3. Драйвера, которые использовались в системе на момент краха, строки вида:

804d7000 806e4000   nt        Sun Apr 13 21:31:06 2008 (4802516A)
806e4000 80704d00   hal       Sun Apr 13 21:31:27 2008 (4802517F)
b0b90000 b0ba8b00   bthpan    Sun Apr 13 21:51:32 2008 (48025634)
b0ba9000 b0beba80   bthport   Sun Apr 13 21:46:29 2008 (48025505)

….

В простейших случаях, уже этого достаточно для того, чтобы сделать выводы относительно причин BSOD – драйвер myfault.sys как раз и используется утилитой NotMyFault, то есть, мы нашли виновника.

Вы должны были также обратить внимание на наличие в отчете строк вида:

Symbol search path is: *** Invalid ***

Your debugger is not using the correct symbols

Symbols can not be loaded because symbol path is not initialized.

Символы играют важную роль при отладке драйверов разработчиками, в том числе при анализе BSOD. Они позволяют видеть названия функций, которые используются ядром, позволяют разработчикам драйверов видеть непосредственно код на С/С++ своих драйверов, выполнение которого привело к BSOD, а также получать другую информацию. “Символы” – это общее понятие, которое относится к дополнительной информации, которая обычно записывается в файлы .pdb или в исполняемый файл, в процессе работы линковщика. Для нас важно знать, что они содержат дополнительную информацию, которая упрощает анализ дампов. Более подробную информацию о символах вы можете узнать в файле помощи к Debugging Tools — debugger.chm.

Давайте запустим dumpchk.exe с параметром — “y”, который позволяет указать путь к файлам символов.

dumpchk.exe -y srv*C:Symbols*http://msdl.microsoft.com/download/symbols C:WINDOWSMinidumpMini021814-01.dmp > rep.txt

Если в каталоге c:symbols будут отсутствовать необходимые символы, они будут загружены с сайта Microsoft. Это может занять некоторое время.

Symbols

Вложенный файл ниже – это результат работы dumpchk.exe с включенной опцией местонахождения символов.

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

analyze –v

Запускаем windbg.exe

windbg.exe -y cache*C:Symbols;srv*http://msdl.microsoft.com/download/symbols

Выбираем “File / Open Crash Dump” открываем наш файла малого дампа.

Анализ дампа после BSOD с помощью Windbg.exe

Мы также увидим сообщение о ошибке — “ERROR: Module load completed but symbols could not be loaded for myfault.sys”. Так и должно быть поскольку для этого драйвера файлы символы не представлены. Теперь в строке ввода команд давайте введем:

!analyze -v

Мы получи намного больше информации, чем в случае использования dumpchk.exe (см. вложенный файл)

Вот сам отчет.

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: e2ee9008, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: badbc5ab, address which referenced memory

Debugging Details:
——————

READ_ADDRESS:  e2ee9008

CURRENT_IRQL:  2

FAULTING_IP:
myfault+5ab
badbc5ab 8b08            mov     ecx,dword ptr [eax]

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xD1

PROCESS_NAME:  NotMyfault.exe

LAST_CONTROL_TRANSFER:  from badbc9db to badbc5ab

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
b08f6bfc badbc9db 898ae698 b08f6c40 badbcb26 myfault+0x5ab
b08f6c08 badbcb26 8936b740 00000001 00000000 myfault+0x9db
b08f6c40 804ef18f 89668958 898ae698 806e6410 myfault+0xb26
b08f6c50 8057f982 898ae708 8936b740 898ae698 nt!IopfCallDriver+0x31
b08f6c64 805807f7 89668958 898ae698 8936b740 nt!IopSynchronousServiceTail+0x70
b08f6d00 80579274 00000094 00000000 00000000 nt!IopXxxControlFile+0x5c5
b08f6d34 8054161c 00000094 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
b08f6d34 7c90e4f4 00000094 00000000 00000000 nt!KiFastCallEntry+0xfc
0006f8e0 00000000 00000000 00000000 00000000 0x7c90e4f4

STACK_COMMAND:  kb

FOLLOWUP_IP:
myfault+5ab
badbc5ab 8b08            mov     ecx,dword ptr [eax]

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  myfault+5ab

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: myfault

IMAGE_NAME:  myfault.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4f806ca0

FAILURE_BUCKET_ID:  0xD1_myfault+5ab

BUCKET_ID:  0xD1_myfault+5ab

Followup: MachineOwner

Давайте рассмотрим полученную информацию.

1. DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) – это символическое описание ошибки

2. У данной ошибки, есть 4-е параметра, которые позволяют получить дополнительную информацию, все они представлены ниже

Arg1: e2ee9008, memory referenced (адрес памяти по которому происходило обращение)
Arg2: 00000002, IRQL (уровень IRQL на момент обращения)
Arg3: 00000000, value 0 = read operation, 1 = write operation (тип операции, в нашем случае, это операция чтения)
Arg4: badbc5ab, address which referenced memory (адрес в памяти инструкции, которая выполняла операцию чтения)

3.

FAULTING_IP:
myfault+5ab
badbc5ab 8b08            mov     ecx,dword ptr [eax]

Здесь показана непосредственно инструкция которая выполнялась – операция записи в регистр ecx содержимого по адресу указанному в eax. Эта инструкция находится по адресу myfault+5ab и относится к драйверу myfault.sys (myfault – это имя драйвера).

4.

PROCESS_NAME:  NotMyfault.exe

Это имя процесса пользовательского режима, который выполнялся во время краха.

5.

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
b08f6bfc badbc9db 898ae698 b08f6c40 badbcb26 myfault+0x5ab
b08f6c08 badbcb26 8936b740 00000001 00000000 myfault+0x9db
b08f6c40 804ef18f 89668958 898ae698 806e6410 myfault+0xb26
b08f6c50 8057f982 898ae708 8936b740 898ae698 nt!IopfCallDriver+0x31
b08f6c64 805807f7 89668958 898ae698 8936b740 nt!IopSynchronousServiceTail+0x70
b08f6d00 80579274 00000094 00000000 00000000 nt!IopXxxControlFile+0x5c5
b08f6d34 8054161c 00000094 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
b08f6d34 7c90e4f4 00000094 00000000 00000000 nt!KiFastCallEntry+0xfc
0006f8e0 00000000 00000000 00000000 00000000 0x7c90e4f4

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

nt!KiFastCallEntry+0xfc
nt!NtDeviceIoControlFile+0x2a
nt!IopXxxControlFile+0x5c5
nt!IopSynchronousServiceTail+0x70
nt!IopfCallDriver+0x31
myfault+0xb26
myfault+0x9db
myfault+0x5ab

С Ntdll.dll была вызвана функция KiFastCallEntry, которая затем вызвала NtDeviceIoControlFile и т.д., пока при выполнении инструкции по адресу myfault+0x5ab не произошел крах системы.

Анализ данных говорит нам о том, что виновником BSOD был драйвер myfault (myfault.sys)

Если бы мы не использовали символы, у нас была бы следующая информация о стеке

b08f6bfc badbc9db 898ae698 b08f6c40 badbcb26 myfault+0x5ab
b08f6c08 badbcb26 8936b740 00000001 00000000 myfault+0x9db
b08f6c40 804ef18f 89668958 898ae698 806e6410 myfault+0xb26
b08f6c64 805807f7 89668958 898ae698 8936b740 nt+0x1818f
b08f6d00 80579274 00000094 00000000 00000000 nt+0xa97f7
b08f6d34 8054161c 00000094 00000000 00000000 nt+0xa2274
b08f6d64 7c90e4f4 badb0d00 0006f888 b11b2d98 nt+0x6a61c
b08f6d68 badb0d00 0006f888 b11b2d98 b11b2dcc 0x7c90e4f4
b08f6d6c 0006f888 b11b2d98 b11b2dcc 00000000 vmscsi+0xd00
b08f6d70 b11b2d98 b11b2dcc 00000000 00000000 0x6f888
b08f6d74 b11b2dcc 00000000 00000000 00000000 0xb11b2d98
b08f6d78 00000000 00000000 00000000 00000000 0xb11b2dcc

Что менее информативно.

Вообще анализ дампов, кроме самых простых случаев (таких как рассмотренный) требует значительной подготовки и хорошего понимания как работы ОС и драйверов так и владение знанием ассемблера. В открытом доступе можно найти некоторые книги Дмитрия Востокова «Memory Dump Analysis Antology». Если вы их найдете, вы сможете приблизительно оценить уровень автора и приблизительно понять нетривиальность анализа дампов.

Как я уже говорил, мы разобрали простой случай анализа дампа после BSOD. Если результаты анализа показывают, что причиной BSOD являются файлы ядра, например – ntoskrnl.exe, обязательно прочитайте об использовании утилиты Driver Verifier.

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

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