Alter.Org.UA
 << Back Home EN en   Donate Donate

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

Оглавление

Поехали...

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

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

Настройка

Общие настройки, Жертва (Target)
  1. установите последнюю версию DbgPrintLog с помощью следующих команд: 
    update.bat
DbgPrintLog.exe --drv:inst B --drv:opt DoNotPassMessagesDown 1 --drv:opt BufferSize 16384
    Это позволит извлекать предсмертные отладочные сообщения из дампа памяти и минимизирует нагрузку на канал связи между компьютерами если используется отладка с 2мя машинами. Если требуется отлаживать boot-драйвер (например, драйвер контроллера дисков), используйте в командной строке ключ
    --drv:inst 1
  2. Настраиваем создание дампа памяти:
    • Убедитесь, что размер файла подкачки pagefile.sys больше, чем размер физической памяти и что этот файл расположен на загрузочном разделе (там же, где установлена винда с ее каталогом Windows).
    • Убедитесь, что на разделе с виндой достаточно свободного места. Дамп содержит полную копию физ. памяти и еще немного доп. информации.
    • Мой Компьютер -> Свойства -> Дополнительно -> Загрузка и восстановление
      My Computer -> Properties -> Advanced -> Startup and recovery
    • включите создание дампа памяти (memory dump)
    • установите тип дампа в Дамп памяти ядра (Kernel Dump) или Полный дамп памяти (Full Memory Dump).
      Внимание: не устанавливайте Малый дамп (Minidump/Small dump) - это абсолютно бесполезно с точки зрения сбора логов.
  3. Настраиваем 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, не перезагружаться
  4. перезагрузите машину, чтобы все настройки гарантировано сохранились до установки подопытного драйвера и/или приложения.

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

Жертва (Target), для 2х машинной (удаленной) отладки
NT3.51/NT4/2000/XP/2003
  1. соедините машины IEEE1394 (FireWire) или NULL-modem кабелем. Рекомендуется кабель с полной или частичной синхронизацией.
    Note: IEEE1394 поддерживается начиная с Windows XP. Windows 95/98/ME, Windows NT4 and Windows 2000 не могут отлаживаться по IEEE1394.
  2. и не забудьте об общих настройках
  3. откройте на редактирование BOOT.INI в корневом каталоге загрузочного раздела.
  4. найдите запись, соответствующую вашей ОС, что-то наподобие этого: 
       multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional"
  5. сделайте копию этой строки, к примеру следующей строкой
  6. добавьте в конец скопированой строки вот что:
    • если вы используете 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
  7. убедитесь что TIMEOUT в BOOT.INI не равен нулю
  8. теперь 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 DBG" /noexecute=optin /fastdetect /debug
    /debugport=1394 /CHANNEL=3
  9. отключите FireWire (IEEE1394) контроллер в Диспетчере устройств (Device Manager):
    Мой компьютер -> Управление -> Диспетчер устройств
    My Computer -> Manage -> Device Manager
Жертва (Target), для 2х машинной (удаленной) отладки
Vista
  1. соедините машины IEEE1394 (FireWire) или NULL-modem кабелем.
    Note: IEEE1394 поддерживается начиная с Windows XP. Windows 95/98/ME, Windows NT4 и Windows 2000 не могут отлаживаться по IEEE1394.
  2. и не забудьте об общих настройках
  3. запустите cmd.exe с правами администратора.
    Note: Это не тоже самое, что запустить из под учетной записи администратора. Это специальное действие, доступное из контекстного меню.
  4. введите следующие команды:
  5. если вы используете IEEE-1394: 
       bcdedit /dbgsettings 1394 CHANNEL:3
  6. если вы используете NULL-modem, подключенный к COM2: 
       bcdedit /dbgsettings serial debugport:2 baudrate:115200
  7. если вы используете USB-link и имя сессии 'debugging': 
       bcdedit /dbgsettings USB targetname:debugging
  8. включите отладочный режим: 
       bcdedit /debug on
Жертва (Target), для 2х машинной (удаленной) отладки
на стадии установки системы или в среде
Windows PE
  1. соедините машины IEEE1394 (FireWire) или NULL-modem кабелем.
    Note: IEEE1394 поддерживается начиная с Windows XP.
  2. находим и открываем на редактирование txtsetup.sif
  3. находим строчку: 
    OsLoadOptions ="/fastdetect /minint"
  4. и меняем на: 
    OsLoadOptions ="/fastdetect /minint /debug /debugport=COM2 /baudrate=115200"
    или 
    OsLoadOptions ="/fastdetect /minint /debug  /debugport=1394 /CHANNEL=3"
Машина для удаленной отладки (Host)
  1. не забудьте соединить машины кабелем!
  2. установите WinDbg
  3. скопируйте dbgprn.dll из свежего дистрибутива DbgPrintLog в подкаталог 'dbgext' каталога, в который установлен WinDbg. (например C:\Program Files\WinDbg\dbgext)
  4. Объявите переменную окружения _NT_SYMBOL_PATH, указывающую на локальный путь к символьным файлам (обычно это подкаталог 'sym' каталога, в который установлен WinDbg. (например C:\Program Files\WinDbg\sym) и адрес интернет-сервера символьных файлов (как правило, это http://msdl.microsoft.com/download/symbols). Рекомендуется использовать короткие (DOS, 8.3) имена каталогов. 
    _NT_SYMBOL_PATH=srv*C:\Progra~1\WinDbg\sym*http://msdl.microsoft.com/download/symbols
  5. Скачайте с сайта Microsoft набор символьных файлов для отладки (debug symbols). и разместите их в каталоге, на который ссылается _NT_SYMBOL_PATH (см. выше). Есть смысл установить атрибут NTFS Compressed на этот каталог. Для загрузки отдельных символьных файлов к имеющимся исполнииым файлам и библиотекам можно использовать утилиту symchk.exe из комплекта WinDbg.
  6. запустите WinDbg
  7. заходим в меню: 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.

Отладка

Отладка на одной машине
  1. запустите DbgPrintLog для сбора отладочных сообщений: 
    DbgPrintLog.exe --full --cpu -l 10
    Должно открыться консольное окно с подсказкой по горячим клавишам. Там же отображается имя текущего log-файла. Не закрывайте это окно. Логи складываются в файл DbgPrintXXX.log в том же каталоге. XXX в имени файла - это номер лог-файла. Номера выдаются последовательно, начиная с первого незанятого. Самый первый файл называется DbgPrint.log. Ранее созданные файлы не перетираются новыми. Ключ -l 10 говорит о том, что храниться будут только 10 последних лог-файлов, а более ранние следует автоматически удалять.
  2. сохраните в отдельное место .PDB файлы с отладочной информацией от той сборки, которая будет отлаживаться. Если проблемы возникают только с Release'ной сборкой, настройте проект так, чтобы создавалась отладочная информация. В случае успешной генерации отладочной информации радом с .EXE, .SYS, .DLL должен появиться с расширением .PDB (или несколько). При настройке параметров отладочной информации не устанавливайте тип 'Separate Types'.
  3. пометьте сохраненные .PDB'шки так, чтобы потом можно было легко определить, к какой сборке они относятся. Если система упадет, для анализа дампа памяти потребуются .PDB-файлы, созданые вместе с отлаживаемыми бинарниками.
  4. запустите dsync.exe из комплекта freboot для того, чтобы синхронизировать системный кеш с дисковыми структурами. Это повышает устойчивость файловой системы к последствиям падения в синий экран. Утилитку можно скачать отсюда:
    http://alter.org.ua/soft/win/fastreboot
  5. теперь ставим экспериментальные драйвера и приложения.
  6. а теперь зппускайте тесты, пока не произойдет какая-нибудь бяка:
    • Неправильное (неожиданное) поведение
      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 пронаблюдать и снять дамп памяти. Настраивайте :)
  7. отправьте архив(ы) с отладочными сообщениями разработчикам и обязательно расскажите, при каких обстоятельствах возникла проблема.
Удаленная отладка (две машины)
  1. не забудьте соединить машины кабелем!
  2. запустите WinDbg
  3. заходим в меню: File -> Kernel Debug ->
    • 1394 выбираем channel 3, OK, Отвечаем 'Save' если спросят о сохранении workspace'а.
    • COM укажите, в какой из COM-портов на машине с отладчиком включен NULL-modem кабель и установите скорость 115200.
  4. перезагрузите 2ю машину и выберите в меню загрузки OS, отмеченую [Debug] или [Debugger Enabled] (или что-то в этом роде)
  5. WinDbg должен выдать сообщение об установке соединения и информацию об операционной системе отлаживаемой машины.
  6. когда в системе-жертве закончится загрузка ОС, запустите там DbgPrintLog.exe для сбора логов: 
    start DbgPrintLog.exe --full --cpu -l 10
    Должно открыться консольное окно с подсказкой по горячим клавишам. Там же отображается имя текущего log-файла. Не закрывайте это окно. Логи складываются в файл DbgPrintXXX.log в том же каталоге. XXX в имени файла - это номер лог-файла. Номера выдаются последовательно, начиная с первого незанятого. Самый первый файл называется DbgPrint.log. Ранее созданные файлы не перетираются новыми. Ключ -l 10 говорит о том, что храниться будут только 10 последних лог-файлов, а более ранние следует автоматически удалять.
  7. сохраните в отдельное место .PDB файлы с отладочной информацией от той сборки, которая будет отлаживаться. Если проблемы возникают только с Release'ной сборкой, настройте проект так, чтобы создавалась отладочная информация. В случае успешной генерации отладочной информации радом с .EXE, .SYS, .DLL должен появиться с расширением .PDB (или несколько). При настройке параметров отладочной информации не устанавливайте тип 'Separate Types'.
  8. пометьте сохраненные .PDB'шки так, чтобы потом можно было легко определить, к какой сборке они относятся. Если система упадет, для анализа дампа памяти потребуются .PDB-файлы, созданые вместе с отлаживаемыми бинарниками.
  9. запустите dsync.exe из комплекта freboot для того, чтобы синхронизировать системный кеш с дисковыми структурами. Это повышает устойчивость файловой системы к последствиям падения в синий экран. Утилитку можно скачать отсюда:
    http://alter.org.ua/soft/win/fastreboot
  10. теперь ставим экспериментальные драйвера и приложения.
  11. а теперь зппускайте тесты, пока не произойдет какая-нибудь бяка:
    • Неправильное (неожиданное) поведение
      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
  12. отправьте архив(ы) с отладочными сообщениями разработчикам и обязательно расскажите, при каких обстоятельствах возникла проблема.

См. также

FB or mail alterX@alter.org.ua (remove X)   Share
<< Back Автор: Alter (Александр А. Телятников) Сервер: Apache+PHP под FBSD © 2002-2024