Любые рекомендуемые настройки VC ++ для лучшего анализа PDB в сборках выпуска

Question

Существуют ли какие-либо настройки VC ++, о которых я должен знать, чтобы генерировать лучшие файлы PDB, которые содержат больше информации?

У меня есть система анализа аварийных дампов, основанная на проекте crashrpt .

Кроме того, на моем сервере производственной сборки установлен исходный код на D: \, но на моей машине разработки есть исходный код на C: \. Я ввел исходный путь в настройках VC ++, но при просмотре стека вызовов при сбое он не переходит автоматически к моему исходному коду. Я считаю, что если бы у меня был исходный код моей машины на D: \, он бы работал.

Answer 1

"Есть ли какие-либо настройки VC ++, о которых я должен знать"

Убедитесь, что вы отключили опускание указателя кадра. Блог Ларри Остермана содержит исторические подробности о fpo и проблемах, которые он вызывает при отладке.

Символы загружены успешно. Он показывает стек вызовов, но двойной щелчок по записи не приводит меня к исходному коду.

Какую версию VS вы используете? (Или вы используете Windbg?) ... в VS он должен определенно запрашивать источник в первый раз, если не находит местоположение. Тем не менее, он также хранит список источников, которые были «не найдены», поэтому он не просит вас об этом каждый раз. Иногда список «не смотреть» - это боль ... чтобы восстановить приглашение, вам нужно перейти в обозреватель решений / узел решения / свойства / отладочные свойства и отредактировать список файлов в нижней панели.

Наконец, вы можете использовать «раздетые символы». Это файлы pdb, сгенерированные для предоставления отладочной информации для обхода стека вызовов за FPO, но с удалением местоположений источника (вместе с другими данными). Общедоступные символы для компонентов ОС Windows - это очищенные pdbs. Для вашего собственного кода это просто причиняет боль и не стоит того, если вы не предоставляете свои pdbs для внешних целей. Как бы вы получили один из этих ужасных раздетых pdbs? Они могут быть у вас, если вы используете «binplace» с командой -a.

Удачи! Подходящая история мини-дампов - находка для отладки продукции.

Answer 2

Если ваша сборка напрямую из вашей системы управления исходным кодом, вы должны аннотировать ваши файлы pdb происхождением файла. Это позволяет автоматически извлекать точные исходные файлы во время отладки. (Это тот же процесс, который используется для получения исходного кода платформы .Net).

См. http://msdn.microsoft.com/en-us/magazine/cc163563.aspx для получения дополнительной информации. Если вы используете Subversion в качестве SCM, вы можете проверить проект SourceServerSharp.

Answer 3

Это процедура, которую я использовал после некоторых неприятностей, похожих на вашу:

a) Скопировал на рабочий сервер все созданные файлы EXE и DLL, каждый со своей соответствующей PDB в том же каталоге, запустил систему и дождался сбоя.

b) Скопировал все файлы EXE, DLL и PDB на компьютер разработчика (во временную папку) вместе с мини-дампом (в той же папке). Использовал Visual Studio для загрузки минидампа из этой папки.

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

Еще два совета:

• Одна вещь, которую я часто делал, состояла в том, чтобы скопировать восстановленный EXE / DLL и забыть скопировать новую PDB. Это разрушило цикл отладки, VS не смог бы показать мне стек вызовов.

• Иногда я получаю стек вызовов, который не имеет смысла в VS. После некоторой головной боли я обнаружил, что windbg всегда будет показывать мне правильный стек, но VS часто этого не делает. Не знаю почему.

Answer 4

Вы можете попытаться использовать команду MS-DOS subst , чтобы назначить каталог с исходным кодом для диска D:

Answer 5

Visual Studio запрашивает у вас путь к исходному файлу?

номер

Если это не так, он не думает, что у него есть символы для стека вызовов. Установка источника путь должен работать без карты точное исходное местоположение.

Символы загружены успешно. Он показывает стек вызовов, но двойной щелчок по записи не приводит меня к исходному коду. Конечно, я могу искать в файлах нужную строку, но это тяжелая работа:)

Answer 6

Visual Studio запрашивает у вас путь к исходному файлу? Если это не так, он не думает, что у него есть символы для стека вызовов. Установка исходного пути должна работать без точного сопоставления исходного местоположения.

Вы можете узнать, загружены ли символы, посмотрев в окно «модулей» в Visual Studio.

Предполагая, что вы создаете PDB, я не думаю, что есть какие-либо параметры, которые напрямую контролируют объем информации в PDB. Вы можете изменить тип оптимизаций, выполняемых компилятором, чтобы улучшить отладочную работу, но это будет стоить производительности - как указывает ваш коллега, отключение inline поможет сделать вещи более очевидными в файле сбоев, но будет стоить во время выполнения. 1005 *

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

Answer 7

В случае, если кто-то заинтересован, сотрудник ответил на этот вопрос мне по электронной почте:

Артем написал:

Есть флаг для MiniDumpWriteDump () что может сделать лучше аварийные дампы, которые позволит увидеть полное состояние программы, со всеми глобальными переменными и т. д. Что касается стеки вызовов, я сомневаюсь, что они могут быть лучше из-за оптимизаций ... если вы не включите (может быть, некоторые) оптимизации отключены.

Кроме того, я думаю, что отключение inline функции и вся программа оптимизация очень поможет.

На самом деле, существует много типов дампа, может быть, вы могли бы выбрать один маленький достаточно, но все еще есть больше информации http://msdn.microsoft.com/en-us/library/ms680519(VS.85).aspx

Эти типы не помогут со стеком вызовов. тем не менее, они влияют только на количество переменные, которые вы сможете увидеть.

Я заметил некоторые из этих типов дампа не поддерживаются в dbghelp.dll Версия 5.1, которую мы используем. Мы могли бы обновить до последней версии 6.9 хотя, я только что проверил EULA на MS Debugging Tools - самые новые dbghelp.dll все еще в порядке перераспределить.