WinDbg basics

Alter.Org.UA

<< Back

Home

www/www1/www2

Отладка в WinDbg
пособие для тестировщика

Поехали...

Есть такой отладчик - WinDbg, создан фирмой Microsoft, берется отсюда:
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx.

Глобально есть 2 варианта отладки: с одной машиной и с 2мя машинами. В случае одной машины мы можем собирать отладочные сообщения в файл и при появления синего экрана (BSOD) анализировать автоматически созданый дамп памяти (crashdump). После перезагрузки, естественно. В случае 2х машин на одной (target) происходит все самое интересное, а со второй (host) мы можем за этим наблюдать. Плюсом 2го способа является то, что дамп памяти и последние логи можно получить всегда, мало того, иногда можно даже продолжить выполнение, но это уже выходит за рамки этой статьи.

Настройка

Общие настройки, Жертва (Target)

установите последнюю версию DbgPrintLog с помощью следующих команд:
```
update.bat
DbgPrintLog.exe --drv:inst B --drv:opt DoNotPassMessagesDown 1 --drv:opt BufferSize 16384
```
Это позволит извлекать предсмертные отладочные сообщения из дампа памяти и минимизирует нагрузку на канал связи между компьютерами если используется отладка с 2мя машинами. Если требуется отлаживать boot-драйвер (например, драйвер контроллера дисков), используйте в командной строке ключ
--drv:inst 1
Настраиваем создание дампа памяти:
- Убедитесь, что размер файла подкачки pagefile.sys больше, чем размер физической памяти и что этот файл расположен на загрузочном разделе (там же, где установлена винда с ее каталогом Windows).
- Убедитесь, что на разделе с виндой достаточно свободного места. Дамп содержит полную копию физ. памяти и еще немного доп. информации.
- Мой Компьютер -> Свойства -> Дополнительно -> Загрузка и восстановление
  My Computer -> Properties -> Advanced -> Startup and recovery
- включите создание дампа памяти (memory dump)
- установите тип дампа в Дамп памяти ядра (Kernel Dump) или Полный дамп памяти (Full Memory Dump).
  Внимание: не устанавливайте Малый дамп (Minidump/Small dump) - это абсолютно бесполезно с точки зрения сбора логов.
Настраиваем Driver verifier. Это встроеное в Windows средство для проверки надежности и правильности поведения драйверов. Часто помогает отлавливать проблемы, в обычных условиях проявляющиеся намного позже возникновения первопричины.
- запустите verifier.exe. Начиная с WinXP он встроен в систему, в 2000 его нужно взять из DDK.
- выберите "Создать нестандартные параметры (для кода программ)" - 2й пункт. Далее
- выберите "Выбрать из списка" - нижний radio-button. Далее
- отметьте все пункты, возможно, за исключением "Эмуляция нехватки ресурсов" ("Low Resources Simulation"). Далее
  Attention: "Эмуляция нехватки ресурсов" - это только для проверки драйвера на живучесть в стрессовых ситуациях. Он просто не должен падать в таких условиях. Ожидать же нормальной работы не следует. Ни в коем случае не применяйте эту опцию для отладки в рабочем режиме.
- "Выбрать драйвер из списка" ("Select Driver from list") - последний пункт. Далее
- отметьте нужные драйвера. Если проверяемый драйвер в данный момент не загружен, нажмите кнопку "Добавить в список незагруженые драйвера" ("Add not loaded drivers to list") под списком. Драйвера обычно находятся в каталоге WINDOWS\System32\drivers\.
- OK, не перезагружаться
перезагрузите машину, чтобы все настройки гарантировано сохранились до установки подопытного драйвера и/или приложения.

При отладке на одной машине подготовка на этом заканчивается.

Жертва (Target), для 2х машинной (удаленной) отладки

соедините машины IEEE1394 (FireWire) или NULL-modem кабелем.
Note: IEEE1394 поддерживается начиная с Windows XP. Windows 95/98/ME, Windows NT4 and Windows 2000 не могут отлаживаться по IEEE1394.
и не забудьте об общих настройках
откройте на редактирование BOOT.INI в корневом каталоге загрузочного раздела.
найдите запись, соответствующую вашей ОС, что-то наподобие этого:
```
   multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional"
```
сделайте копию этой строки, к примеру следующей строкой
добавьте в конец скопированой строки вот что:
- если вы используете IEEE-1394:
```
       /debug /debugport=1394 /CHANNEL=3
    
```
- если вы используете NULL-modem, подключенный к COM2:
```
       /debug /debugport=COM2 /baudrate=115200
    
```
в конечном итоге должно получиться вот что (одной строкой):
```
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP Pro" /noexecute=optin /fastdetect /debug
    /debugport=1394 /CHANNEL=3
```
убедитесь что TIMEOUT в BOOT.INI не равен нулю

теперь BOOT.INI должен выглядеть так:

[Boot Loader]
Timeout=5
Default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[Operating Systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP Pro" 
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP Pro" /noexecute=optin /fastdetect /debug
    /debugport=1394 /CHANNEL=3

отключите FireWire (IEEE1394) контроллер в Диспетчере устройств (Device Manager):
Мой компьютер -> Управление -> Диспетчер устройств
My Computer -> Manage -> Device Manager

Жертва (Target), для 2х машинной (удаленной) отладки
на стадии установки системы или в среде Windows PE

соедините машины IEEE1394 (FireWire) или NULL-modem кабелем.
Note: IEEE1394 поддерживается начиная с Windows XP.
находим и открываем на редактирование txtsetup.sif
находим строчку:
```
OsLoadOptions ="/fastdetect /minint"
```

и меняем на:

OsLoadOptions ="/fastdetect /minint /debug /debugport=COM2 /baudrate=115200"

или

OsLoadOptions ="/fastdetect /minint /debug  /debugport=1394 /CHANNEL=3"

Машина для удаленной отладки (Host)

не забудьте соединить машины кабелем!
установите WinDbg
скопируйте dbgprn.dll из свежего дистрибутива DbgPrintLog в подкаталог 'dbgext' каталога, в который установлен WinDbg. (например C:\Program Files\WinDbg\dbgext)
запустите WinDbg
заходим в меню: File -> Kernel Debug ->
- 1394, выбираем channel 3, OK, Отвечаем 'Save' если спросят о сохранении workspace'а. При первом запуске WinDbg может возникнуть сообщение об ошибке "Unable to open file". Это означает, что система еще не обнаружила удаленный FireWire'ный порт на машине-жертве. В таком случае сделайте вот что:
  - оставьте запущеный WinDbg
  - перезагрузите 2ю машину и выберите в меню загрузки OS, отмеченую [Debug] или [Debugger Enabled] (или что-то в этом роде)
  - на машинке с запущеным WinDbg должно появиться окошко с сообщением об обнаружении нового оборудования (New Hardware Found). И должны установиться драйвера для Debug Port. Вас могут попросить установочный диск Windows.
  - В некоторых случаях приходится перезагружать обе машины и повторять процедуру.
  - Если машины правильно соединены, правильным кабелем, контроллеры работоспособны, но отладчик все равно не может установить соединение, я не знаю как лечить. Разве что попробовать заменить PCI FireWire карточки на другие. Мне попадались экземпляры, которые делали вид, что работают, но поглюкивали при передаче данных в процессе работы.
- COM, укажите, в какой из COM-портов на машине с отладчиком включен NULL-modem кабель и установите скорость 115200.

Отладка

Отладка на одной машине

запустите DbgPrintLog для сбора отладочных сообщений:
```
DbgPrintLog.exe --full --cpu -l 10
```
Должно открыться консольное окно с подсказкой по горячим клавишам. Там же отображается имя текущего log-файла. Не закрывайте это окно. Логи складываются в файл DbgPrintXXX.log в том же каталоге. XXX в имени файла - это номер лог-файла. Номера выдаются последовательно, начиная с первого незанятого. Самый первый файл называется DbgPrint.log. Ранее созданные файлы не перетираются новыми. Ключ -l 10 говорит о том, что храниться будут только 10 последних лог-файлов, а более ранние следует автоматически удалять.
сохраните в отдельное место .PDB файлы с отладочной информацией от той сборки, которая будет отлаживаться. Если проблемы возникают только с Release'ной сборкой, настройте проект так, чтобы создавалась отладочная информация. В случае успешной генерации отладочной информации радом с .EXE, .SYS, .DLL должен появиться с расширением .PDB (или несколько). При настройке параметров отладочной информации не устанавливайте тип 'Separate Types'.
пометьте сохраненные .PDB'шки так, чтобы потом можно было легко определить, к какой сборке они относятся. Если система упадет, для анализа дампа памяти потребуются .PDB-файлы, созданые вместе с отлаживаемыми бинарниками.
запустите dsync.exe из комплекта freboot для того, чтобы синхронизировать системный кеш с дисковыми структурами. Это повышает устойчивость файловой системы к последствиям падения в синий экран. Утилитку можно скачать отсюда:
http://www2.alter.org.ua/soft/win/fastreboot
теперь ставим экспериментальные драйвера и приложения.
а теперь зппускайте тесты, пока не произойдет какая-нибудь бяка:
- Неправильное (неожиданное) поведение
  1. переключитесь в консоль DbgPrintLog'а и нажмите 'Esc' чтобы остановить сбор сообщений
  2. запакуйте в архив *.LOG-файлы из каталога, где был запущен DbgPrintLog.exe.
  3. кроме того, очень полезно сложить этот архив рядом с исполнимыми файлами, которые вы тестировали (или их копиями) и соответствующими им .PDB-файлами.
- Падение системы, синий экран (BSOD)
  1. в каталоге, указаном во время подготовки должен создаться дамп памяти. Обычно он создается в каталоге WINDOWS и называется MEMORY.DMP.
  2. после перезагрузки сложите MEMORY.DMP рядом с с исполнимыми файлами, которые вы тестировали (или их копиями) и соответствующими им .PDB-файлами. Это пригодится при дальнем анализе дампа.
    Note: проверьте время создания файла. Может статься, что это дамп от предыдущего падения, а новый просто не создался. В этом случае дальнейшие шаги теряют смысл.
  3. запустите WinDbg
  4. откройте MEMORY.DMP:
    File -> Open Crash Dump
  5. в командной строке WinDbg запустите следующие команды:
```
!analyze -v
!dbgprn.save -a -e --full --cpu -T R --file <full path to file>
```
    если !dbgprn.save говорит "Cannot find DbgPrnHk!DbgPrnHk_State export", попробуйте:
```
!dbgprn.lsig
!dbgprn.save -a -e --full --cpu -T R --file <full path to file>
```
  6. отладочные сообщения будут сохранены в файл <full path to file>. Запакуйте полученый файл в архив.
  7. кроме того, очень полезно сложить этот архив рядом с исполнимыми файлами, которые вы тестировали (или их копиями) и соответствующими им .PDB-файлами.
  8. выделите весь текст в окне WinDbg и сохраните его в файл. Заархивируйте этот файл и сложите рядом с копией дампа памяти, заархивированими отладочными сообщениями, и копиями исполнимых файлов и .PDB-файлов.
- Полное повисание системы
  1. В большинстве случаев это на самом деле означает, что система хочет выпасть в синий экран, но у нее что-то не получилось. И как правило при использовании 2й машины в таком случае удается этот самый BSOD пронаблюдать и снять дамп памяти. Настраивайте :)
отправьте архив(ы) с отладочными сообщениями разработчикам и обязательно расскажите, при каких обстоятельствах возникла проблема.

Удаленная отладка (две машины)

не забудьте соединить машины кабелем!
запустите WinDbg
заходим в меню: File -> Kernel Debug ->
- 1394 выбираем channel 3, OK, Отвечаем 'Save' если спросят о сохранении workspace'а.
- COM укажите, в какой из COM-портов на машине с отладчиком включен NULL-modem кабель и установите скорость 115200.
перезагрузите 2ю машину и выберите в меню загрузки OS, отмеченую [Debug] или [Debugger Enabled] (или что-то в этом роде)
WinDbg должен выдать сообщение об установке соединения и информацию об операционной системе отлаживаемой машины.
когда в системе-жертве закончится загрузка ОС, запустите там DbgPrintLog.exe для сбора логов:
```
start DbgPrintLog.exe --full --cpu -l 10
```
Должно открыться консольное окно с подсказкой по горячим клавишам. Там же отображается имя текущего log-файла. Не закрывайте это окно. Логи складываются в файл DbgPrintXXX.log в том же каталоге. XXX в имени файла - это номер лог-файла. Номера выдаются последовательно, начиная с первого незанятого. Самый первый файл называется DbgPrint.log. Ранее созданные файлы не перетираются новыми. Ключ -l 10 говорит о том, что храниться будут только 10 последних лог-файлов, а более ранние следует автоматически удалять.
сохраните в отдельное место .PDB файлы с отладочной информацией от той сборки, которая будет отлаживаться. Если проблемы возникают только с Release'ной сборкой, настройте проект так, чтобы создавалась отладочная информация. В случае успешной генерации отладочной информации радом с .EXE, .SYS, .DLL должен появиться с расширением .PDB (или несколько). При настройке параметров отладочной информации не устанавливайте тип 'Separate Types'.
пометьте сохраненные .PDB'шки так, чтобы потом можно было легко определить, к какой сборке они относятся. Если система упадет, для анализа дампа памяти потребуются .PDB-файлы, созданые вместе с отлаживаемыми бинарниками.
запустите dsync.exe из комплекта freboot для того, чтобы синхронизировать системный кеш с дисковыми структурами. Это повышает устойчивость файловой системы к последствиям падения в синий экран. Утилитку можно скачать отсюда:
http://www2.alter.org.ua/soft/win/fastreboot
теперь ставим экспериментальные драйвера и приложения.
а теперь зппускайте тесты, пока не произойдет какая-нибудь бяка:
- Неправильное (неожиданное) поведение
  1. переключитесь в консоль DbgPrintLog'а и нажмите 'Esc' чтобы остановить сбор сообщений
  2. запакуйте в архив *.LOG-файлы из каталога, где был запущен DbgPrintLog.exe.
  3. кроме того, очень полезно сложить этот архив рядом с исполнимыми файлами, которые вы тестировали (или их копиями) и соответствующими им .PDB-файлами.
- Падение системы, синий экран (BSOD)
  1. в окне WinDbg появися сообщение об аварийной остановке системы. Машина-жертва в это время выглядит повисшей.
  2. в командной строке WinDbg выполните следующие команды:
```
.dump /f <DumpFileName>
!analyze -v
!dbgprn.save -a --full --cpu -T R --file <full path to file>
```
    если !dbgprn.save говорит "Cannot find DbgPrnHk!DbgPrnHk_State export", попробуйте:
```
!dbgprn.lsig
!dbgprn.save -a --full --cpu -T R --file <full path to file>
```
  3. отладочные сообщения будут сохранены в файл <full path to file>. А дамп памяти попадет в файл <DumpFileName>. Запакуйте полученые файлы в архив.
  4. кроме того, очень полезно сложить этот архив рядом с исполнимыми файлами, которые вы тестировали (или их копиями) и соответствующими им .PDB-файлами.
  5. выделите весь текст в окне WinDbg и сохраните его в файл. Заархивируйте этот файл и сложите рядом с копией дампа памяти, заархивированими отладочными сообщениями, и копиями исполнимых файлов и .PDB-файлов.
  6. если вы выдите волшебное слово "KeBugCheckEx" среди сообщений WinDbg - смело пеезагружайте отлаживаемую машину power'ом или reset'ом. Если же там было "first chance exception" - можете попробовать продолжить работу с помощью команды
```
g
```
отправьте архив(ы) с отладочными сообщениями разработчикам и обязательно расскажите, при каких обстоятельствах возникла проблема.

<< Back

Автор: Alter (Александр А. Телятников)

Сервер: Apache+PHP под FBSD

Отладка в WinDbgпособие для тестировщика

Оглавление