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

Question

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

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

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

Answer 1

«Существуют ли какие-либо настройки VC++ я должен знать о»

Убедитесь, что вы выключите указатель фрейма ommision. В блоге Larry osterman есть the historical details о fpo и проблемах, которые он вызывает при отладке.

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

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

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

Удачи вам! Правильная история мини-дампов - это находка для отладки производства.

Answer 2

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

Answer 3

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

Артем писал:

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

No.

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

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

Answer 6

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

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

Answer 7

Это процедура я после некоторых проблем, подобных вашему:

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

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

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

Два советы:

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

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