Windbg windows 10 как пользоваться

Обновлено: 24.01.2025

отладка устройства Windows 10 IoT Базовая с помощью мощного Windows отладчика WinDbg.

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

WinDbg — очень мощный отладчик, с которым знакомы большинство Windows разработчиков. Однако если вы только приступите к работе и хотите узнать больше о WinDbg, перейдите по следующим ссылкам:

MinnowBoard Max (МИКРОТЕСТОВ)

Вы можете подключить WinDbg к устройству MinnowBoard Max с помощью сетевого подключения.

Настройка сетевого подключения

Чтобы включить отладку ядра с помощью WinDbg по сети, убедитесь, что:

Кабель Ethernet подключен к сети MinnowBoard Max Device.

MinnowBoard Max Device имеет допустимый IP-адрес в вашей сети.

Активное подключение к устройству MinnowBoard Max с помощью PowerShell

Используя активное подключение PowerShell, выполните следующие команды в параметре MinnowBoard Max, чтобы включить отладку по сети.

bcdedit -dbgsettings net hostip:<DEV_PC_IP_ADDRESS> port:<PORT_NUM> key:<KEY>

Эта команда включает отладку по сети. Кроме того, он указывает IP-адрес компьютера, на котором будет выполняться WinDbg (DEV_PC_IP_ADDRESS), номер сетевого порта, используемого для подключения (PORT_NUM), и уникальный ключ, который будет использоваться для различения нескольких подключений (ключ).

Для PORT_NUM и ключа можно использовать следующие значения в качестве примеров: 50045 и 1.2.3.4 соответственно, хотя вы можете изменить их по своему усмотрению.

bcdedit -debug on

На компьютере разработчика запустите WinDbg с PORT_NUM и КЛЮЧЕВЫМи значениями, приведенными в предыдущих шагах, как показано ниже. "c:\Program Files (x86)\Debugging Tools for Windows (x86)\windbg.exe" -k net:port=<PORT_NUM>,key=<KEY>

если вы установили какой бы то ни было комплект Windows, вы можете найти WinDbg в разделе C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\WinDbg.exe</code>

Перезагрузка устройства Иоткоре для повторного подключения к отладчику

Raspberry Pi 2 или 3 (RPi2 или RPi3)

Вы можете подключить WinDbg к Raspberry Pi 2 или 3 с помощью последовательного подключения.

Настройка последовательного подключения

Чтобы включить отладку ядра с помощью WinDbg через последовательное подключение, убедитесь, что:

У вас есть отладочный кабель, такой как последовательный кабель от USB до TTL от Adafruit или фтди.

Кабель Ethernet или активный WiFi, соединяющий устройство Raspberry Pi 2 или 3 с вашей сетью (для IP-подключений, таких как SSH или PowerShell).

Устройство Raspberry Pi 2 или 3 имеет допустимый IP-адрес в сети

Активное подключение к устройству Raspberry Pi 2 или 3 с помощью PowerShell или SSH

UART0 будет использоваться на устройстве Raspberry Pi 2 или 3 для подключения отладки ядра. Ниже показаны сопоставления ПИН-кода для Raspberry Pi 2 или 3, а также последовательных кабелей:

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

Соединение ЕФИЕСП больше не создается. Его необходимо подключить самостоятельно. для получения идентификатора GUID можно использовать команду mountvol. mkdir C:\EFIESP mountvol C:\EFIESP \?\Volume

Используя активное подключение PowerShell, выполните следующие команды на устройстве Raspberry Pi 2 или 3, чтобы включить отладку по последовательному подключению.

bcdedit /store c:\EFIESP\EFI\Microsoft\Boot\BCD -dbgsettings serial

Приведенная выше команда включает последовательное подключение для отладки.
Скорость передачи для Raspberry Pi 2 или 3 жестко запрограммирована на 921600, поэтому вам не нужно указывать его.

bcdedit /store c:\EFIESP\EFI\Microsoft\Boot\BCD -debug on

На компьютере разработчика получите порт номера порта COM, назначенный в системе для кабеля USB – TTL. Он будет доступен в диспетчер устройств в разделе "порты (COM & LPT)".

"C:\Program Files (x86)\Debugging Tools for Windows (x86)\windbg.exe" -k com:port=<PORT>,baud=921600

если вы установили какой бы то ни было комплект Windows, вы можете найти WinDbg в разделе C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\WinDbg.exe

Перезагрузка устройства Иоткоре для повторного подключения к отладчику

Драгонбоард (DB)

Вы можете подключить WinDbg к Драгонбоард с помощью последовательного или USB-подключения.

Используя активное подключение PowerShell или SSH к Драгонбоард, выполните следующие команды, чтобы включить отладку.

bcdedit /store c:\EFIESP\EFI\Microsoft\Boot\BCD /debug ON
- Включает отладчик
Настройка USB-подключения

По умолчанию параметры отладчика USB настраиваются в тестовых образах.

Когда отладчик ядра USB включен, порты USB на устройстве Драгонбоард могут не работать (например, клавиатура, USB-порт Ethernet может не работать).

Настройка последовательного подключения

bcdedit /store c:\EFIESP\EFI\Microsoft\Boot\BCD /dbgsettings Serial debugport:1 baudrate:115200

12.07.2019

Windows 10, Windows Server 2016

комментариев 7
В момент критического сбоя операционная система Windows прерывает работу и показывает синий экран смерти (BSOD). Содержимое оперативной памяти и вся информация о возникшей ошибке записывается в файл подкачки. При следующей загрузке Windows создается аварийный дамп c отладочной информацией на основе сохраненных данных. В системном журнале событий создается запись о критической ошибке.
Внимание! Аварийный дамп не создается, если отказала дисковая подсистема или критическая ошибка возникла на начальной стадии загрузки Windows.
Типы аварийных дампов памяти Windows

На примере актуальной операционной системы Windows 10 (Windows Server 2016) рассмотрим основные типы дампов памяти, которые может создавать система:

Как включить создание дампа памяти в Windows?

С помощью Win+Pause откройте окно с параметрами системы, выберите «Дополнительные параметры системы» (Advanced system settings). Во вкладке «Дополнительно» (Advanced), раздел «Загрузка и восстановление» (Startup and Recovery) нажмите кнопку «Параметры» (Settings). В открывшемся окне настройте действия при отказе системы. Поставьте галку в чек-боксе «Записать события в системный журнал» (Write an event to the system log), выберите тип дампа, который должен создаваться при сбое системы. Если в чек-боксе «Заменять существующий файл дампа» (Overwrite any existing file) поставить галку, то файл будет перезаписываться при каждом сбое. Лучше эту галку снять, тогда у вас будет больше информации для анализа. Отключите также автоматическую перезагрузку системы (Automatically restart).

В большинстве случаев для анализа причины BSOD вам будет достаточно малого дампа памяти.

Теперь при возникновении BSOD вы сможете проанализировать файл дампа и найти причину сбоев. Мини дамп по умолчанию сохраняется в папке %systemroot%\minidump. Для анализа файла дампа рекомендую воспользоваться программой WinDBG (Microsoft Kernel Debugger).

Установка WinDBG в Windows

Файл называется winsdksetup.exe, размер 1,3 МБ.

Запустите установку и выберите, что именно нужно сделать – установить пакет на этот компьютер или загрузить для установки на другие компьютеры. Установим пакет на локальный компьютер.

Можете установить весь пакет, но для установки только инструмента отладки выберите Debugging Tools for Windows.

После установки ярлыки WinDBG можно найти в стартовом меню.

Настройка ассоциации .dmp файлов с WinDBG

Для того, чтобы открывать файлы дампов простым кликом, сопоставьте расширение .dmp с утилитой WinDBG.
1. Откройте командную строку от имени администратора и выполните команды для 64-разрядной системы: cd C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
  windbg.exe –IA
  для 32-разрядной системы:
  C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
  windbg.exe –IA
2. В результате типы файлов: .DMP, .HDMP, .MDMP, .KDMP, .WEW – будут сопоставлены с WinDBG.
Настройка сервера отладочных символов в WinDBG

Отладочные символы (debug-символы или symbol files) – это блоки данных, генерируемые в процессе компиляции программы совместно с исполняемым файлом. В таких блоках данных содержится информация о именах переменных, вызываемых функциях, библиотеках и т.д. Эти данные не нужны при выполнении программы, но полезные при ее отладке. Компоненты Microsoft компилируются с символами, распространяемыми через Microsoft Symbol Server.

Настройте WinDBG на использование Microsoft Symbol Server:

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

Если подключение к интернету отсутствует, то загрузите предварительно пакет символов с ресурса Windows Symbol Packages.

Анализ аварийного дампа памяти в WinDBG

Отладчик WinDBG открывает файл дампа и загружает необходимые символы для отладки из локальной папки или из интернета. Во время этого процесса вы не можете использовать WinDBG. Внизу окна (в командной строке отладчика) появляется надпись Debugee not connected.

Команды вводятся в командную строку, расположенную внизу окна.

Отладчик предлагает выполнить команду !analyze -v, достаточно навести указатель мыши на ссылку и кликнуть. Для чего нужна эта команда?
- Она выполняет предварительный анализ дампа памяти и предоставляет подробную информацию для начала анализа.
- Эта команда отобразит STOP-код и символическое имя ошибки.
- Она показывает стек вызовов команд, которые привели к аварийному завершению.
- Кроме того, здесь отображаются неисправности IP-адреса, процессов и регистров.
- Команда может предоставить готовые рекомендации по решению проблемы.
Основные моменты, на которые вы должны обратить внимание при анализе после выполнения команды !analyze –v (листинг неполный).

*****************************************************************************
* *
* Bugcheck Analysis *
* *
*****************************************************************************
Символическое имя STOP-ошибки (BugCheck)
KERNEL_SECURITY_CHECK_FAILURE (139)
Описание ошибки (Компонент ядра повредил критическую структуру данных. Это повреждение потенциально может позволить злоумышленнику получить контроль над этой машиной):

A kernel component has corrupted a critical data structure. The corruption could potentially allow a malicious user to gain control of this machine.
Аргументы ошибки:

Arguments:
Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove).
Arg2: ffffd0003a20d5d0, Address of the trap frame for the exception that caused the bugcheck
Arg3: ffffd0003a20d528, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, Reserved
Debugging Details:
------------------

Счетчик показывает сколько раз система упала с аналогичной ошибкой:

Основная категория текущего сбоя:

Код STOP-ошибки в сокращенном формате:

Процесс, во время исполнения которого произошел сбой (не обязательно причина ошибки, просто в момент сбоя в памяти выполнялся этот процесс):

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

ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

Последний вызов в стеке:

LAST_CONTROL_TRANSFER: from fffff8040117d6a9 to fffff8040116b0a0

Стек вызовов в момент сбоя:

STACK_TEXT:
ffffd000`3a20d2a8 fffff804`0117d6a9 : 00000000`00000139 00000000`00000003 ffffd000`3a20d5d0 ffffd000`3a20d528 : nt!KeBugCheckEx
ffffd000`3a20d2b0 fffff804`0117da50 : ffffe000`f3ab9080 ffffe000`fc37e001 ffffd000`3a20d5d0 fffff804`0116e2a2 : nt!KiBugCheckDispatch+0x69
ffffd000`3a20d3f0 fffff804`0117c150 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiFastFailDispatch+0xd0
ffffd000`3a20d5d0 fffff804`01199482 : ffffc000`701ba270 ffffc000`00000001 000000ea`73f68040 fffff804`000006f9 : nt!KiRaiseSecurityCheckFailure+0x3d0
ffffd000`3a20d760 fffff804`014a455d : 00000000`00000001 ffffd000`3a20d941 ffffe000`fcacb000 ffffd000`3a20d951 : nt! ?? ::FNODOBFM::`string'+0x17252
ffffd000`3a20d8c0 fffff804`013a34ac : 00000000`00000004 00000000`00000000 ffffd000`3a20d9d8 ffffe001`0a34c600 : nt!IopSynchronousServiceTail+0x379
ffffd000`3a20d990 fffff804`0117d313 : ffffffff`fffffffe 00000000`00000000 00000000`00000000 000000eb`a0cf1380 : nt!NtWriteFile+0x694
ffffd000`3a20da90 00007ffb`475307da : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
000000ee`f25ed2b8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffb`475307da

Участок кода, где возникла ошибка:

FOLLOWUP_IP:
nt!KiFastFailDispatch+d0
fffff804`0117da50 c644242000 mov byte ptr [rsp+20h],0
FAULT_INSTR_CODE: 202444c6
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiFastFailDispatch+d0
FOLLOWUP_NAME: MachineOwner

Имя модуля в таблице объектов ядра. Если анализатору удалось обнаружить проблемный драйвер, имя отображается в полях MODULE_NAME и IMAGE_NAME:

MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe

Если кликнете по ссылке модуля (nt), то увидите подробную информацию о пути и других свойствах модуля. Находите указанный файл, и изучаете его свойства.

1: kd> lmvm nt
Browse full module list
Loaded symbol image file: ntkrnlmp.exe
Mapped memory image file: C:\ProgramData\dbg\sym\ntoskrnl.exe\5A9A2147787000\ntoskrnl.exe
Image path: ntkrnlmp.exe
Image name: ntkrnlmp.exe
InternalName: ntkrnlmp.exe
OriginalFilename: ntkrnlmp.exe
ProductVersion: 6.3.9600.18946
FileVersion: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)

В приведенном примере анализ указал на файл ядра ntkrnlmp.exe. Когда анализ дампа памяти указывает на системный драйвер (например, win32k.sys) или файл ядра (как в нашем примере ntkrnlmp.exe), вероятнее всего данный файл не является причиной проблемы. Очень часто оказывается, что проблема кроется в драйвере устройства, настройках BIOS или в неисправности оборудования.

Если вы увидели, что BSOD возник из-за стороннего драйвера, его имя будет указано в значениях MODULE_NAME и IMAGE_NAME.

Image path: \SystemRoot\system32\drivers\cmudaxp.sys
Image name: cmudaxp.sys

Откройте свойсва файла драйвера и проверьте его версию. В большинстве случаев проблема с драйверами решается их обнвовлением.

WinDBG – прекрасный отладчик. Возможно, у него не очень дружественный интерфейс и нет по умолчанию черного фона, но это один из самых мощных и стабильных отладчиков в ОС Windows в настоящее время. В этой статье я познакомлю вас с основами WinDBG, чтобы вы могли начать с ним работу.

Автор: Брэд Антониевич (Brad Antoniewicz)

WinDBG – прекрасный отладчик. Возможно, у него не очень дружественный интерфейс и нет по умолчанию черного фона, но это один из самых мощных и стабильных отладчиков в ОС Windows в настоящее время. В этой статье я познакомлю вас с основами WinDBG, чтобы вы могли начать с ним работу.

Эта первая статья из цикла, посвященного WinDBG. Перечень всех статей, входящих в этот цикл:
- Часть 1 – установка, интерфейс, символы, удаленная/локальная отладка, система помощи, модули, регистры.
- Часть 2 – точки останова.
- Часть 3 – инспектирование памяти, пошаговая отладка программ, советы и трюки.
В этой статье мы рассмотрим установку и подсоединение к процессу, а в следующих - точки останова, пошаговую отладку и инспектирование памяти.

Установка WinDBG

По сравнению с Windows 7 процесс установки WinDBG в Windows 8 претерпел небольшие изменения. В этом разделе мы рассмотрим установку отладчика для обеих операционных систем.

Установка WinDBG в Windows 8

В Windows 8 WinDBG включается в пакет Windows Driver Kit (WDK). Вы можете установить Visual Studio и WDK или установить отдельно пакет «Debugging Tools for Windows 8.1», который включает WinDBG.

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

Рисунок 1: Выбор типа установки

В следующем окне вам необходимо снять флажки со всех пунктов кроме «Debugging Tools for Windows» и нажать на кнопку «Download».

Как только установщик закончит свою работу, зайдите в директорию, куда загрузился пакет (по умолчанию это c:\Users\Username\Downloads\Windows Kits\8.1\StandaloneSDK) и пройдите процедуру установки.

Установка WinDBG в Windows 7 и более ранних версиях

Во время установки я выбираю опцию «Debugging Tools» в разделе «Redistributable Packages», чтобы создать автономный инсталлятор для облегчения последующих установок.

Рисунок 2: Выбор опций установки для создания автономного инсталлятора

По завершению установки, у вас должны появиться инсталляторы WinDBG для различных платформ (в директории c:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools for Windows\ ).

Рисунок 3: Папка с инсталляторами WinDBG для различных платформ

Далее процесс установки довольно прост. Вам нужно лишь скопировать соответствующий файл на ту машину, где вы собираетесь проводить отладку, и пройти процедуру установки.

Интерфейс WinDBG

Рисунок 4: Внешний вид WinDBG

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

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

Рисунок 5: Командное окно WinDBG

В большинстве случаев WinDBG не требует особых настроек и корректно работает прямо «из коробки». Но одну важную вещь, которую необходимо настроить, - это символы. Символы – это файлы, которые генерируются вместе с исполняемым файлом во время компиляции программы и содержат отладочную информацию (функции и имена переменных). Отладочная информация позволяет исследовать функциональность приложения во время отладки или дизассемблирования. Многие компоненты Microsoft компилируются вместе с символами, которые распространяются через Microsoft Symbol Server. С остальными исполняемыми файлами все не так радужно, - очень редко файлы с отладочной информацией идут в комплекте с приложением. В большинстве случаев компании ограничивают доступ к подобной информации.

Рисунок 6: Настройка Microsoft Symbol Server

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

Добавление символов во время отладки

Если вам нужно импортировать символы во время отладки, то можно сделать это при помощи .sympath (окно для ввода команд появится, когда вы подцепитесь к процессу). К примеру, чтобы добавить папку c:\SomeOtherSymbolFolder, введите следующую команду:

Будет не лишним выполнить перезагрузку символов после добавления или изменения путей:

0:025> .reload
Reloading current modules
.
.

Проверка загруженных символов

Чтобы увидеть, для каких модулей загружены символы, вы можете воспользоваться командой x*!. Хотя WinDBG загружает символы только по мере надобности, команда x*! покажет символы, которые могут быть загружены. Можно принудительно загрузить символы при помощи команды ld * (на это может уйти некоторое время, и вы можете остановить этот процесс, зайдя в Debug:Break).

Рисунок 7: Принудительная загрузка символов

Теперь мы можем увидеть символы для каждого модуля.

Рисунок 8: Перечень символов

Отладка локального процесса

При отладке локального процесса у вас есть два пути:
1. Подцепиться к уже запущенному процессу.
2. Запустить процесс через WinDBG.
У каждого способа есть свои преимущества и недостатки. Если, допустим, вы запустили программу через WinDBG, то вам доступны некоторые специальные отладочные опции (например, отладка кучи), которые могут привести к краху приложения. С другой стороны, существуют также и программы, которые аварийно заканчиваются свою работу, когда вы цепляете к ним отладчик. Некоторые приложения (в особенности, вредоносы) во время запуска проверяют присутствие отладчика в системе и, соответственно, в этом случае имеет смысл цепляться к уже запущенному процессу. Иногда происходит отладка службы под управлением ОС Windows, которая устанавливает некоторые параметры во время запуска, так что для упрощения процесса отладки, также лучше подцепляться к запущенному процессу, а не запускать службу через отладчик. Некоторые люди утверждают, что запуск процесса через отладчик серьезно сказывается на производительности. Короче говоря, попробуйте и то и другое и выберите то, что подходит вам лучше всего. Если вы по каким-то причинам предпочитаете какой-то конкретный способ, поделитесь своими соображениями в комментариях!

Запуск процесса

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

Запустить процесс не составляет труда. Зайдите в «File:Open Executable» и выберите тот исполняемый файл, который хотите отладить. Вы также можете указать аргументы или установить стартовую директорию:

Рисунок 9: Выбор исполняемого файла для отладки

Подключение к процессу

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

Чтобы подцепиться к уже запущенному процессу зайдите в «File:Attach to a Process», а затем выберите PID или имя процесса. Помните о том, что вам необходимо иметь соответствующие права, чтобы подцепиться к процессу.

Рисунок 10: Выбор процесса, к которому нужно подцепиться

Если после подключения, приложения приостановило свою работу, вы можете использовать режим «Noninvaise», поставив соответствующий флажок.

Отладка удаленного процесса

Возможно, иногда вам будет требоваться отладка процесса на удаленной системе. Было бы намного более удобно решать эту задачу при помощи локального отладчика, вместо использования виртуальной машины или RDP. Или, быть может, вы отлаживаете процесс LoginUI.exe, который доступен только в случае, когда система заблокирована. В подобных ситуациях вы можете использовать локальную версию WinDBG и удаленно подключаться к процессам. Для решения этих задач существует два наиболее распространенных способа.

Существующие отладочные сессии

Если вы уже начали локальную отладку программы (посредством подключения или запуска процесса через WinDBG), то можете ввести определенную команду, и WinDBG запустит «слушатель» (listener), к которому сможет подключиться удаленный отладчик. Для этого используйте команду .server:

После запуска вышеупомянутой команды вы можете увидеть такое предупреждение:

Затем WinDBG сообщит, что сервер запущен:

0:005> .server tcp:port=5005
Server started. Client can connect with any of these command lines
0: <debugger> -remote tcp:Port=5005,Server=USER-PC

Теперь вы может подключиться с удаленного хоста к уже существующей отладочной сессии, зайдя в «File:Connect to a Remote Session» и введя в текстовое поле примерно следующее: tcp:Port=5005,Server=192.168.127.138

Рисунок 12: Удаленное подключение к отладочной сессии

После подключения вы получите подтверждение на удаленном клиенте:

Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Server started. Client can connect with any of these command lines
0: <debugger> -remote tcp:Port=5005,Server=USER-PC
MACHINENAME\User (tcp 192.168.127.138:13334) connected at Mon Dec 16 09:03:03 2013

MACHINENAME\User (tcp 192.168.127.138:13334) connected at Mon Dec 16 09:03:03 2013

Создание удаленного сервера

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

dbgsrv.exe -t tcp:port=5005

Рисунок 13: Запуск удаленного сервера

И опять же вы можете получить предупреждение о безопасности, которое вам следует принять:

К серверу отладки вы можете подключиться, если зайдете в файл «File: Connect to Remote Stub» и введете в текстовое поле следующую строку: tcp:Port=5005,Server=192.168.127.138

Рисунок 15: Подключение к отладочному серверу

После подключения вы не получите каких-то сигналов о том, что вы подключились, однако если вы зайдете в «File:Attach to a Process», то увидите перечень процессов отладочного сервера (там, где запущен dbgsrv.exe). Теперь вы можете подцепляться к процессу, как если бы делали это локально.

Система помощи

Система помощи в WinDBG – великолепна. Помимо изучения чего-то нового, вы должны уметь получать справочную информацию о какой-либо команде. Используйте команду .hh для доступа к справке WinDBG:

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

windbg> .hh .reload

Или просто зайдите в раздел «Help:Contents».

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

После подключения к процессу WinDBG автоматически отобразит загруженные модули. К примеру, ниже показаны модули, после того, как я подключился к calc.exe:

Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Позже в процессе отладки вы можете вновь вывести этот список при помощи команды lmf:

Также вы можете узнать адрес загрузки для конкретного модуля при помощи команды «lmf m»:

0:005> lmf m kernel32
start end module name
77550000 77624000 kernel32 C:\Windows\system32\kernel32.dll

Вы также можете получить информацию о заголовке (image header) конкретного модуля при помощи расширения !dh (восклицательный знак указывает на расширение):

0:005> !dh kernel32

File Type: DLL
FILE HEADER VALUES
14C machine (i386)
4 number of sections
4A5BDAAD time date stamp Mon Jul 13 21:09:01 2009

0 file pointer to symbol table
0 number of symbols
E0 size of optional header
2102 characteristics
Executable
32 bit word machine
DLL

Debug Directories(2)
Type Size Address Pointer
cv 25 c549c c4c9c Format: RSDS, guid, 2, kernel32.pdb
( 10) 4 c5498 c4c98

(da8.b44): Break instruction exception - code 80000003 (first chance)

После подключения к calc.exe WinDBG автоматически отображает информацию о следующих регистрах:

eax=7ffd9000 ebx=00000000 ecx=00000000 edx=776cd23d esi=00000000 edi=00000000
eip=77663540 esp=02affd9c ebp=02affdc8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246

Позже можно продублировать эту информацию еще раз при помощи команды r:

0:005> r
eax=7ffd9000 ebx=00000000 ecx=00000000 edx=776cd23d esi=00000000 edi=00000000
eip=77663540 esp=02affd9c ebp=02affdc8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!DbgBreakPoint:
77663540 cc int 3

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

0:005> r eax
eax=7ffd9000

Информацию одновременно из нескольких регистров можно получить так:

0:005> r eax,ebp
eax=7ffd9000 ebp=02affdc8

Указатель на инструкцию

Последняя команда посвящена запускаемым инструкциям. Здесь информация также выводится на экран, как и в случае с командой r, того, что содержит регистр EIP. EIP – это регистр, содержащий местонахождение следующей инструкции, которую должен выполнить процессор. То, что отображает WinDBG, – эквивалент команды u eip L1, после выполнения которой WinDBG идет по адресу, указанному в регистре EIP, преобразует этот участок в ассемблерный код и отображает его на экране.

ntdll!DbgBreakPoint:
77663540 cc int 3

Оставайтесь на связи

В следующих статьях мы рассмотрим, как использовать WinDBG в боевых условиях: точки останова, пошаговую отладку и просмотр памяти. Не переключайтесь! J.

Ошибки
Ошибка синего экрана возникает в системе Windows после сбоя системы. Синий экран неожиданно появляется, заставляя вас перезапустить систему в середине вашей работы. Ошибка является непреднамеренным признаком и весьма разочаровывает, когда вам трудно отладить проблему. К счастью, есть много удобных инструментов, таких как Средство отладки Windows ( Windbg ), которое позволяет прочитать отчет об ошибках для устранения неполадок и устранить ошибку BSOD.

Причины ошибки BSOD

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

Исправление ошибки BSOD

Ошибка «Синий экран», также называемая «Ошибка остановки», приводит к полной остановке системы Windows, и вам, возможно, придется перезагрузить систему, чтобы продолжить работу.

Когда происходит сбой системы, Windows создает файлы мини-дампов, и все данные памяти с подробными сведениями об ошибках сбрасываются на жесткий диск для последующей отладки. Есть много удобных инструментов, таких как Bluescreen View и Windbg, которые позволяют вам читать файлы мини-дампов для устранения неполадок. Вы можете использовать представление Bluescreen, чтобы быстро и легко проанализировать ошибку. Для более сложных исследований вы можете использовать Windbg для решения проблемы BSOD.

Что такое средство отладки Windows (Windbg)

WinDbg, также называемый средством отладки Windows, является многоцелевым отладчиком, который автоматически сканирует все файлы мини-дампов, которые были созданы после сбоя BSOD. Этот инструмент используется для более сложного анализа сложных ошибок и доступен для бесплатной загрузки в составе Windows 10 SDK. Для каждого случая сбоя инструмент отладки предоставляет подробные сведения о драйвере, который был загружен во время сбоя, и другую расширенную информацию о сбое, чтобы диагностировать основную причину ошибки синего экрана и в конечном итоге помогает выяснить проблемные драйверы. В этой статье мы расскажем, как использовать средство отладки Windows (WinDbg) для чтения отчета о сбое.

Как использовать Windbg

Установка Windbg

Загрузите автономный Windows 10 SDK здесь.

Запустите установщик и выберите путь установки по умолчанию.

Примите лицензию и выберите функцию Средства отладки для Windows , чтобы установить отладчик.

Использование Windbg для отладки ошибки синего экрана

Перейдите в Пуск и введите WinDbg (x86).

Щелкните правой кнопкой мыши инструмент WinDbg и выберите Запуск от имени администратора.

Перейдите в Файл и нажмите Открыть аварийный дамп в меню.

Перейдите к пути C: \ Windows \ Minidump и нажмите папку Minidump .

В папке Minidump щелкните файл dmp , который вы хотите открыть.

Теперь WinDbg проанализирует файл и подождите, пока Отладчик не подключен исчезнет в нижней части окна.

Нажмите на ! Analyse -v в командной строке и дождитесь завершения анализа.

Чтобы получить больше информации о драйвере, найдите MODULE_NAME из результатов анализа и нажмите на ссылку драйвера.

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

Надеюсь, это поможет!

В этой статье рассмотри где скачать, как установить и настроить WinDBG.

Загрузка и установка WinDBG

2.Откройте скачанный файл sdksetup.exe;

3.Здесь вы можете выбрать место для установки или оставить его по умолчанию, нажмите Next;

4.Примите лицензионное соглашение, нажав на Accept;

6.После завершения установки нужно нажать на Close.

Ассоциированние .dmp файлов с WinDBG

3.Теперь в командной строке нужно написать команду windbg.exe -IA и нажать Enter.

Настроить путь к символам.

WinDBG ищет символы каждый раз , когда он читает двоичный файл в файле .dmp BSOD, и нам нужно указать где ему их искать.

2.В открывшемся окне зайдите в File => Symbol File Path.

Что данная строка означает: создается папка с именем C: \ SymCache и в нее загружаются новые символы с сайта MSDL.

4. Открой File => Save Workspace. Закройте WinDBG.

Читайте также: