Анализ дампа памяти в Windows при BSOD с помощью WinDBG

—>

The Windows Debugger (WinDbg) can be used to debug kernel-mode and user-mode code, to analyze crash dumps, and to examine the CPU registers while the code executes.

Download WinDbg Preview

WinDbg Preview is a new version of WinDbg with more modern visuals, faster windows, a full-fledged scripting experience, built with the extensible debugger data model front and center. WinDbg Preview is using the same underlying engine as WinDbg today, so all the commands, extensions, and workflows still work as they did before.

• Download WinDbg Preview from the Microsoft Store: WinDbg Preview.

• Learn more about installation and configuration in WinDbg Preview — Installation.

Debugging Tools for Windows 10 (WinDbg)

If you just need the Debugging Tools for Windows 10, and not Windows Driver Kit (WDK) for Windows 10 or Visual Studio 2017, you can install the debugging tools as a standalone component from the Windows SDK. In the SDK installation wizard, select Debugging Tools for Windows, and deselect all other components.

• Get Debugging Tools for Windows (WinDbg) from the SDK: Windows 10 SDK.

• Learn more about WinDbg and other debuggers in Debugging Tools for Windows (WinDbg, KD, CDB, NTSD).

Tip

If the Windows SDK is already installed, open Settings, navigate to Apps & features, select Windows Software Development Kit, and then click Modify to change the installation to add Debugging Tools for Windows.

Looking for the debugging tools for earlier version of Windows?

To download the debugger tools for previous versions of Windows, you need to download the Windows SDK for the version you are debugging from the Windows SDK and emulator archive. In the installation wizard of the SDK, select Debugging Tools for Windows, and deselect all other components.

Looking for related downloads?

• Windows Driver Kit (WDK)

• Windows Debugger Symbols

• Windows HLK, HCK, or Logo Kit

• Windows Assessment and Deployment Kit (Windows ADK)

• Windows Insider Preview builds

—>

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

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

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

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

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

В моей системе набор программ для отладки 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. Давайте запустим ее и перенаправим вывод в файл. Мы получим приблизительно следующий результат (см. вложенный файл ниже)

rep.txt

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

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

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

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

….

В простейших случаях, уже этого достаточно для того, чтобы сделать выводы относительно причин 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. Это может занять некоторое время.

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

rep1.txt

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

analyze –v

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

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

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

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

!analyze -v

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

rep3.txt

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

READ_ADDRESS:  e2ee9008

CURRENT_IRQL:  2

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xD1

PROCESS_NAME:  NotMyfault.exe

LAST_CONTROL_TRANSFER:  from badbc9db to badbc5ab

STACK_COMMAND:  kb

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.

4.

PROCESS_NAME:  NotMyfault.exe

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

5.

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

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

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

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

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

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

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

—>

For the lastest news on Windows Debugging tools, see WinDbg Preview — What’s New.

This section describes new debugging tools in Windows 10, version 1703.

• Eight new JavaScript topics including JavaScript Debugger Scripting
• Updates to the dx (Display Debugger Object Model Expression) command, to include new command capabilities.
• New dtx (Display Type — Extended Debugger Object Model Information) command.
• New !ioctldecode command.
• Updated Debugger Engine Reference to include additional interfaces and structures.
• Updates to Configuring tools.ini to document additional options for the command line debuggers.
• Published 75 previously undocumented stop codes in Bug Check Code Reference.
• New Supported Ethernet NICs for Network Kernel Debugging in Windows 10 topic.

This section describes new debugging tools in Windows 10, version 1607.

• New topic about Debugging a UWP app using WinDbg.
• Updates to the 30 most-viewed developer bug check topics in Bug Check Code Reference.

CDB Command-Line Options — Updated to include new command line options.</li>!analyze — Updated to include information about using this extension with UMDF 2.15.</li>!wdfkd.wdfcrashdump— Updated to include information about using this extension with UMDF 2.15</li>!irp — Updated. Starting with Windows 10 the IRP major and minor code text is displayed in command output.</li>Using Debugger Markup Language — Updated to describe new right click behavior available in the Debugger Markup Language (DML).</li>Crash dump analysis using the Windows debuggers (WinDbg) — Performance has increased in taking a memory dump over KDNET.</li>Debug Universal Drivers — Step by Step Lab (Echo Kernel-Mode)- New step by step lab that shows how to use WinDbg to debug the sample KMDF echo driver.

Looking to download the Debugging Tools?

For information on downloading the debugging tools, see Download Debugging Tools for Windows.

—></li>Используемые источники:

• https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools
• https://bsod-help.ru/analiz-dampov-posle-bsod-s-pomoshhyu-debugging-tools-for-windows/
• https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugging-tools-for-windows—new-for-windows-10