Все это приходится отлаживать, причем зачастую не на рабочем месте, а в конфигурации клиента и на чужой машине.
При этом поиск ошибок превращается при отсутствии соответствующего инструментария и подготовки в настоящую проблему.
Традиционных подходов к отладке несколько:
- использовать протоколирование (на самом деле замечательный способ и во многом просто незаменимый, особенно при грамотном подходе)
- подключить свой любимый отладчик удаленно (для многих Windows-программистов это, естественно, та или иная версия MSVC)
- использовать "самопальную" систему отладки (сюда же я отнесу и различного рода crash-handler'ы, производящие раскрутку стека сбойного потока на основе отладочной информации собственного формата)
- установить на систему клиента "легкий" отладчик (возможно, в качестве post-mortem debugger'a вместо Dr.Watson) и использовать для работы его
При отсутствии доступа к клиентской системе (а в моем случае это бывает частенько - корабли на месте не стоят, они созданы для того чтобы плавать) особенно не разгуляться, и варианты с протоколированием сбоев программы + какой-то crash handler остаются единственными способами понять хоть что-то.
Очевидно, что эффективность обоих методов оставляет желать лучшего, как бы апологеты протоколирования не стремились доказать обратное.
В ситуации же, когда имеется доступ в клиентскую систему, пусть и удаленный, и даже не сильно широкополосный, сделать можно намного больше.
Инсталляция "легкого" отладчика и наличие определенного набора данных позволяет довольно часто получить почти исчерпывающую картину проблемы.
Замечание: по умолчанию в Windows, начиная с NT, уже входит консольный отладчик, который называется ntsd.exe. К сожалению, "из коробки" он настолько отстал от жизни, что полезность его крайне ограничена (особенно с учетом столь же устаревшей версии dbghelp.dll).
Взамен него можно использовать один из замечательных отладчиков от Microsoft же, которые входят в состав свободно распространяемого пакета Debugging Tools for Windows, легко устанавливаются в систему и обладают мощью на самом большей, чем, например, штатный отладчик от Microsoft Visual Studio (только не нужно кидаться в меня тяжелыми предметами ;-) ).
Честно сразу отмечу - интерфейс оконного отладчика WinDbg, а тем более его сводных братьей ntsd.exe (да-да, того самого, но более новой версии) и cdb.exe, далеки от идеала, но позволяют работать не чуть не хуже, чем в привычной среде.
Кстати, последние два отладчика отличаются друг от друга только отношением к консоли - один из них подключается к существующей консоли, а другой создает новую.
Никто не запрещает пользоваться сторонними отладчиками типа OllyDbg (как рабочий инструмент кул хацкеры часто предпочитают именно его) или заслуженным SoftIce, но мы не "ломаем" программу, мы ее "чиним".
Поэтому нам требуется:
- отладчик уровня исходного кода (ломать ничего не надо - вот они, исходные тексты, отладочная информация)
- легкая установка (в идеале - пресловутый "xcopy install")
- многооконность
- наличие консоли и мощного языка сценариев
- наличие возможности писать свои двоичные расширения
WinDbg всем этим критериям удовлетворяет, а с некоторыми его недостатками, типа неудобного графического интерфейса и сильно уступающей Visual Studio способности интерактивно показывать сложные структуры данных, можно смириться.
Собственно, этим постом я хотел предварить рассказ о некоторых очень полезных возможностях WinDbg, которые почти ежедневно используются в работе.
Отладка с помощью WinDbg
Установка WinDbg в качестве postmortem debugger
"Анатомия" стека, или Зачем нужны отладочные символы... \
Symchk
cmdresc
UserDump
Не забывайте подключать символы
Как правильно заполнять _NT_SYMBOL_PATH
"Волшебный" CAB для WinDBG
Комментариев нет:
Отправить комментарий