Отладка двоичных файлов/дампов режима выпуска в Windbg

Мне еще предстоит найти хороший ресурс для отладки двоичных файлов режима RELEASE или дампов в windbg.

Я понимаю, что отладка становится более ограниченной при включенной оптимизации компилятора. Но иногда у меня нет выбора — например, анализ аварийного дампа по невоспроизводимой проблеме.

Было бы очень хорошо, если бы была какая-то статья, описывающая, что ВОЗМОЖНО (или чего следует остерегаться) при выпуске двоичных файлов. Кто-нибудь знает такой ресурс?

Я ищу что-то вроде этого, но с большим Подробнее. Я надеялся, что в Расширенная отладка Windows что-то будет но не тут то было.


windows debugging dump windbg
person pepsi    schedule 21.06.2011    source источник
comment
Я не знаю конкретного ресурса, но если у вас есть конкретные вопросы, я могу немного помочь. Вы используете WER?   -  person i_am_jorf    schedule 21.06.2011
comment
возможный дубликат Хорошего учебника по WinDBG?   -  person Steve Townsend    schedule 21.06.2011
comment
@jeffamaphone - У меня нет конкретного вопроса. Мне просто кажется, что это довольно распространенная проблема, и многим людям было бы полезно иметь место, где можно получить больше информации.   -  person pepsi    schedule 21.06.2011
comment
@Steve - есть много хороших руководств по Windbg, но я еще не видел ни одного, освещающего проблему двоичных файлов без отладки. Этот вопрос специально для двоичных файлов, скомпилированных с включенной оптимизацией, что намного сложнее, чем обычная отладка.   -  person pepsi    schedule 21.06.2011

Ответы (2)


arrow_upward
3
arrow_downward

Если у вас есть PDB, большинство вещей возможны (в течение многих лет я отлаживал библиотеки DLL ОС Windows исключительно в режиме выпуска!).

Следует понимать, что теперь WinDbg будет лгать гораздо чаще, т. е. отображать то, что видит, а это не всегда соответствует фактическому значению. Например, если вы попытаетесь запустить dv в кадре 15 на amd64, нет способа отображать точные значения, поскольку компилятор сохранил информацию в регистре.

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

person Ana Betts    schedule 21.06.2011

arrow_upward
4
arrow_downward

Первое правило: сохраняйте все pdb из каждой сборки, которую вы выпускаете: как из exe, так и из любых других создаваемых вами dll.

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

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

Одна вещь, которую нужно проверить, это то, что в ваших оптимизированных сборках релиза для параметра «Пропустить указатели кадров» установлено значение «Нет». Уже одно это значительно облегчит отладку, так как в 99% случаев вы получите неясный стек.

Имейте в виду, что в большинстве случаев указатель this будет отображаться как NULL в сборке выпуска, но иногда вы можете перемещаться вверх и вниз по стеку, чтобы найти, где он передается в качестве параметра. В общем, не полагайтесь на отображение переменных в отладчике. Если значения выглядят разумными, то они, вероятно, верны. Если они выглядят совершенно неправильно, то либо это ваша ошибка, либо это просто фиктивное отображение переменной, которая была оптимизирована.

О, и посмотрите на легендарного Джона Роббинса (Bugslayer) для некоторых отличные ресурсы для анализа аварийных дампов.

person the_mandrill    schedule 21.06.2011