Поговорим об отладчиках для Microsoft Windows. Их существует довольно много, вспомнить хотя бы всеми любимый OllyDbg, некогда популярный, но в настоящее время практически умерший SoftIce, а также Sycer, Immunity Debugger, x64dbg и бесчисленное количество отладчиков, встроенных в IDE. По моим наблюдениям, WinDbg нравится далеко не всем. Думаю, в основном это связано с командным интерфейсом отладчика.
Любителям Linux и FreeBSD, бесспорно, он пришелся бы по душе. Но закоренелым пользователям Windows он кажется странным и неудобным. А тем временем, по функционалу WinDbg ничем не уступает другим отладчикам. Как минимум, он точно нечем не хуже классического GDB или там LLDB. В чем мы сегодня с вами и убедимся.
В мире Windows, все, как обычно, немного через жопу. Официальный инсталятор WinDbg можно скачать на сайте MS. Инсталятор этот помимо WinDbg также поставит вам свежую версию .NET Framework и перезагрузит систему без спроса. После установки не факт, что отладчик вообще заработает, особенно под старыми версиями Windows. Поэтому лучше скачать неофициальную сборку WinDbg здесь или здесь.
Windbg minidump basic tutorial — Extended
Настоятельно советую воспользоваться именно одной из этих версий — это самый простой и быстрый способ установить WinDbg.
Есть две версии WinDbg, x86 и x64. Чтобы не возникало никаких проблем, отлаживайте x86 приложения с помощью x86 дебагера, а x64 приложения — с помощью x64 дебагера. После первого запуска выглядеть WinDbg будет довольно убого. Но не беспокойтесь по этому поводу. Поработав буквально несколько минут с WinDbg, вы подстроите его под себя и выглядеть он будет вполне няшненько. Например, как-то так (кликабельно, 51 Кб, 1156 x 785):
На этом скриншоте изображена отладка программы из заметки Получаем список запущенных процессов на Windows API. Как видите, WinDbg подцепил исходники программы. Справа отображаются значения локальных переменных. Внизу находится окно для ввода команд, где при помощи команды kn был выведен стэк вызовов.
В верхней части отладчика находятся кнопки, при помощи которых можно выполнять простые действия вроде «шаг вперед», а также открыть дополнительные окна. При помощи этих окон можно посмотреть содержимое оперативной памяти, значения регистров, дизассемблерный листинг программы и много других интересных вещей.
Вообще, очень многое в WinDbg можно делать через GUI. Например, в окне с исходным кодом можно поставить курсор на нужном месте и нажатием на икноку с ладонью создать там точку останова. Или выполнить run to cursor. Также выполнение команды можно в любой момент остановить при помощи кнопки Break в панели вверху. На этом всем подробно останавливаться не будем.
Но учтите, что такие возможности есть и они заслуживают изучения!
Прежде, чем приступить к отладке при помощи WinDbg, нужно сделать несколько несложных телодвижений. Откройте File → Symbol File Path и введите:
Simplest Windbg minidump tutorial
SRV*C:symbols*http://msdl.microsoft.com/download/symbols
Затем нажмите Browse и укажите путь до файлов c отладочной информацией (.pdb) вашего проекта. Аналогичным образом в File → Source File Path укажите путь до каталога с исходниками. Если сомневаетесь, укажите путь, по которому находится файл проекта Visual Studio, не ошибетесь. Затем скажите File → Save Workspace, чтобы все эти пути не приходилось указывать заново при каждом запуске WinDbg.
Теперь, когда все настроено, есть несколько способов начать отладку. Можно запустить новый процесс под отладчиком, можно подключиться к уже существующему, можно открыть крэшдамп. Все это делается через меню File. Особого внимания заслуживает возможность удаленной отладки.
Например, если при помощи WinDbg вы отлаживаете драйверы, то особого выбора, кроме как использовать удаленную отладку, у вас как бы и нет. Что не удивительно, ведь малейшая ошибка в коде драйвера может привести к BSOD.
Если вы уже отлаживаете процесс, но хотели бы начать делать это удаленно, говорим:
.server tcp_port=3003
Нужно проверить, что порт открыт, что особенно актуально на Windows Server. На клиенте делаем File → Connect to a Remote Session, вводим:
tcp_Port=3003,Server=10.110.0.10
Кроме того, можно запустить сервер, позволяющий отлаживать любой процесс в системе:
dbgsrv.exe -t tcp_port=3003
На клиенте подключаемся через File → Connect to Remote Stub. После этого через интерфейс можно как обычно выбрать процесс из списка или запустить новый. Только работать процессы будут на удаленной машине.
Теперь, наконец-то, рассмотрим основные команды WinDbg.
Важно! Иногда команды могут выполняется очень долго, например, если вы решили загрузить сразу все отладочные символы. Если устанете ждать, просто нажмите Ctr+C в поле ввода команды, и WinDbg тут же перестанет делать то, что он сейчас делает.
.help
.hh команда
Очистить вывод в окне Command:
Добавить путь, по которому WinDbg будет искать отладочные символы (та же команда без знака плюс затрет все ранее прописанные пути):
Источник: eax.me
Начало работы с WinDbg (пользовательский режим)
WinDbg — это отладчик в режиме ядра и пользовательском режиме, который входит в состав средств отладки для Windows. Следующие практические упражнения помогут приступить к использованию WinDbg в качестве отладчика в пользовательском режиме.
Сведения о том, как получить средства отладки для Windows, см. в статье Скачивание и установка отладчика Windows WinDbg.
После установки средств отладки найдите каталоги установки для 64-разрядной (x64) и 32-разрядной (x86) версий средств. Пример:
- C:Program Files (x86)Windows Kits10Debuggersx64
- C:Program Files (x86)Windows Kits10Debuggersx86
Откройте Блокнот и подключите WinDbg
- Перейдите в каталог установки и откройте WinDbg.exe.
- В меню Файл выберите Открыть исполняемый файл. В диалоговом окне Открыть исполняемый файл перейдите в папку, содержащую notepad.exe. (Файл notepad.exe обычно находится в папке C:WindowsSystem32.) В поле Имя файла введите notepad.exe. Выберите Открыть.
- В командной строке в нижней части окна WinDbg введите следующую команду: .sympath srv* Выходные данные аналогичны следующему примеру:
Symbol search path is: srv* Expanded Symbol search path is: cache*;SRV
Примечание Если выходные данные не отображаются, введите .reload еще раз.
Чтобы просмотреть символы в модуле notepad.exe, которые содержат main , используйте команду проверить символы , чтобы получить список модулей, соответствующих маске: x notepad!wWin* Выходные данные аналогичны следующему примеру:
00007ff6`6e76b0a0 notepad!wWinMain (wWinMain) 00007ff6`6e783db0 notepad!wWinMainCRTStartup (wWinMainCRTStartup)
0 e Disable Clear 00007ff6`6e76b0a0 0001 (0001) 0:**** notepad!wWinMain
Breakpoint 0 hit notepad!wWinMain: 00007ff6`6e76b0a0 488bc4 mov rax,rsp
Чтобы просмотреть список модулей кода, которые в настоящее время загружены в процесс Блокнота, введите следующую команду: Lm Выходные данные аналогичны следующему примеру:
0:000> lm start end module name 00007ff6`6e760000 00007ff6`6e798000 notepad (pdb symbols) C:ProgramDataDbgsymnotepad.pdbBC04D9A431EDE299D4625AD6201C8A4A1notepad.pdb 00007ff8`066a0000 00007ff8`067ab000 gdi32full (deferred) 00007ff8`067b0000 00007ff8`068b0000 ucrtbase (deferred) 00007ff8`06a10000 00007ff8`06aad000 msvcp_win (deferred) 00007ff8`06ab0000 00007ff8`06ad2000 win32u (deferred) 00007ff8`06b40000 00007ff8`06e08000 KERNELBASE (deferred) 00007ff8`07220000 00007ff8`072dd000 KERNEL32 (deferred) 00007ff8`07420000 00007ff8`07775000 combase (deferred) 00007ff8`07820000 00007ff8`079c0000 USER32 (deferred) 00007ff8`079c0000 00007ff8`079f0000 IMM32 (deferred) 00007ff8`07c00000 00007ff8`07c2a000 GDI32 (deferred) 00007ff8`08480000 00007ff8`085ab000 RPCRT4 (deferred) 00007ff8`085b0000 00007ff8`0864e000 msvcrt (deferred) 00007ff8`08c40000 00007ff8`08cee000 shcore (deferred) 00007ff8`08db0000 00007ff8`08fa5000 ntdll (pdb symbols) C:ProgramDataDbgsymntdll.pdb53F12BFE149A2F50205C8D5D66290B481ntdll.pdb 00007fff`f8580000 00007fff`f881a000 COMCTL32 (deferred)
Чтобы просмотреть трассировку стека, введите следующую команду: k Выходные данные аналогичны следующему примеру:
0:000> k 00 000000c8`2647f708 00007ff6`6e783d36 notepad!wWinMain 01 000000c8`2647f710 00007ff8`07237034 notepad!__scrt_common_main_seh+0x106 02 000000c8`2647f750 00007ff8`08e02651 KERNEL32!BaseThreadInitThunk+0x14 03 000000c8`2647f780 00000000`00000000 ntdll!RtlUserThreadStart+0x21
0:011> ~ 0 Id: 5500.34d8 Suspend: 1 Teb: 000000c8`262c4000 Unfrozen 1 Id: 5500.3960 Suspend: 1 Teb: 000000c8`262c6000 Unfrozen 2 Id: 5500.5d68 Suspend: 1 Teb: 000000c8`262c8000 Unfrozen 3 Id: 5500.4c90 Suspend: 1 Teb: 000000c8`262ca000 Unfrozen 4 Id: 5500.4ac4 Suspend: 1 Teb: 000000c8`262cc000 Unfrozen 5 Id: 5500.293c Suspend: 1 Teb: 000000c8`262ce000 Unfrozen 6 Id: 5500.53a0 Suspend: 1 Teb: 000000c8`262d0000 Unfrozen 7 Id: 5500.3ca4 Suspend: 1 Teb: 000000c8`262d4000 Unfrozen 8 Id: 5500.808 Suspend: 1 Teb: 000000c8`262da000 Unfrozen 10 Id: 5500.3940 Suspend: 1 Teb: 000000c8`262dc000 Unfrozen . 11 Id: 5500.28b0 Suspend: 1 Teb: 000000c8`262de000 Unfrozen 12 Id: 5500.12bc Suspend: 1 Teb: 000000c8`262e0000 Unfrozen 13 Id: 5500.4c34 Suspend: 1 Teb: 000000c8`262e2000 Unfrozen
0:011> ~0s 0:011> ~0s win32u!NtUserGetProp+0x14: 00007ff8`06ab1204 c3 ret 0:000> k # Child-SP RetAddr Call Site 00 000000c8`2647bd08 00007ff8`07829fe1 win32u!NtUserGetProp+0x14 01 000000c8`2647bd10 00007fff`f86099be USER32!GetPropW+0xd1 02 000000c8`2647bd40 00007ff8`07d12f4d COMCTL32!DefSubclassProc+0x4e 03 000000c8`2647bd90 00007fff`f8609aba SHELL32!CAutoComplete::_EditWndProc+0xb1 04 000000c8`2647bde0 00007fff`f86098b7 COMCTL32!CallNextSubclassProc+0x9a 05 000000c8`2647be60 00007ff8`0782e858 COMCTL32!MasterSubclassProc+0xa7 06 000000c8`2647bf00 00007ff8`0782de1b USER32!UserCallWinProcCheckWow+0x2f8 07 000000c8`2647c090 00007ff8`0782d68a USER32!SendMessageWorker+0x70b 08 000000c8`2647c130 00007ff8`07afa4db USER32!SendMessageW+0xda
Открытие собственного приложения и присоединение WinDbg
Например, предположим, что вы написали и создали это небольшое консольное приложение:
. void MyFunction(long p1, long p2, long p3) < long x = p1 + p2 + p3; long y = 0; y = x / p2; >void main ()
В этом упражнении предполагается, что встроенное приложение (MyApp.exe) и файл символов (MyApp.pdb) находятся в папке C:MyAppx64Debug. Также предположим, что исходный код приложения находится в папке C:MyAppMyApp и что целевой компьютер скомпилирован MyApp.exe.
- Откройте WinDbg.
- В меню Файл выберите Открыть исполняемый файл. В диалоговом окне Открыть исполняемый файл перейдите в папку C:MyAppx64Debug. В поле Имя файла введите MyApp.exe. Выберите Открыть.
- Введите следующие команды: .symfix.sympath+ C:MyAppx64Debug Команды сообщают WinDbg, где найти символы и исходный код приложения. В этом случае расположение исходного кода не нужно задавать с помощью SRCPATH , так как символы имеют полные пути к исходным файлам.
- Введите следующие команды: .Перезагрузитьbu MyApp! maing Приложение переходит в отладчик, когда дело доходит до его main функции. WinDbg отображает исходный код и окно Команд.
- В меню Отладка выберите Шаг с за шагом (или F11). Продолжайте пошаговое выполнение, пока не перейдете к MyFunction . При входе в строку y = x / p2 приложение аварийно завершает работу и врывается в отладчик. Выходные данные аналогичны следующему примеру:
(1450.1424): Integer divide-by-zero — code c0000094 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. MyApp!MyFunction+0x44: 00007ff6`3be11064 f77c2428 idiv eax,dword ptr [rsp+28h] ss:00000063`2036f808=00000000
Сводка команд
- Contents команда в Help меню
- .sympath (задать путь к символу)
- .reload (Reload Module)
- x (изучение символов)
- g (Go)
- Break команда в Debug меню
- lm (список загруженных модулей)
- k (обратная трассировка стека дисплея)
- bu (установка точки останова)
- bl (список точек останова)
- ~ (состояние потока)
- ~s (задать текущий поток)
- .sympath+ (Задать путь к символу) добавляется к существующему пути символа
- .srcpath (задать исходный путь)
- Step Into команда в Debug меню (F11)
- !analyze -v
- qd (выход и отключение)
Источник: learn.microsoft.com
Анализ дампа памяти в Windows при BSOD с помощью WinDBG
12.07.2019
itpro
Windows 10, Windows Server 2016
комментариев 9
В момент критического сбоя операционная система Windows прерывает работу и показывает синий экран смерти (BSOD). Содержимое оперативной памяти и вся информация о возникшей ошибке записывается в файл подкачки. При следующей загрузке Windows создается аварийный дамп c отладочной информацией на основе сохраненных данных. В системном журнале событий создается запись о критической ошибке.