Вот несколько общих шагов, которые помогут вам на вашем пути:
Во-первых, вы должны изменить настройки вашего компилятора, чтобы он создавал файлы PDB даже для выпусков сборки. Более поздние версии компилятора Visual C ++ делают это по умолчанию, но во многих версиях Visual C ++ вы должны делать это самостоятельно. Создайте файлы базы данных программы, а затем сохраните архив этих файлов вместе с каждой сборкой приложения. Очень важно, чтобы каждая сборка ваших приложений имела свой собственный набор PDB. Вы не можете просто использовать те же самые, которые вы сделали со сборкой 10, например, для проверки дампов, созданных сборкой 15. За время существования вашего проекта вы получите тонну PDB, так что будьте к этому готовы.
Далее вам необходимо определить точную версию вашего приложения, сгенерировавшего файл дампа. Если вы создаете собственные MiniDump (например, вызывая MiniDumpWriteDump () ), возможно, самый простой способ сделать это - просто сделать часть имени файла MiniDump полным номером версии вашего приложения. Вам нужно будет иметь разумную схему нумерации версий, чтобы это работало. В моем магазине число сборок во всех ветвях увеличивается на единицу каждый раз, когда сборщик автоматически создает сборку.
Теперь, когда вы получили файл дампа от клиента, вы знаете точную версию приложения, создавшего дамп, и нашли файлы PDB для этой сборки.
Теперь вам нужно просмотреть историю вашего контроля версий и найти исходный код для этой точной версии программного обеспечения. Лучший способ сделать это - применять метки к вашим веткам каждый раз, когда вы делаете сборку. Установите значение метки на точный номер версии, и его легко найти в истории.
Вы почти готовы запустить WinDbg / Visual C ++:
- Получите полное дерево исходников для этой версии вашего приложения. Поместите его в отдельное место на жестком диске, скажем
c:\app_build_1.0.100 для версии приложения 1.0 build # 100.
- Получите двоичные файлы для этой конкретной версии вашего приложения и поместите их где-нибудь на жесткий диск. Возможно, проще всего установить эту версию вашего приложения, чтобы получить двоичные файлы.
- Поместите файлы PDB в то же место, что и двоичные файлы на шаге 2.
Теперь у вас есть два варианта просмотра файла дампа. Вы можете использовать Visual Studio или WinDbg. Использовать Visual Studio проще, но WinDbg гораздо мощнее. В большинстве случаев функциональности в Visual Studio будет достаточно.
Чтобы использовать Visual Studio, все, что вам нужно сделать, это открыть файл дампа, как будто это проект. После открытия «запустите» файл дампа ( F5 по умолчанию) и, если все пути заданы правильно, вы попадете прямо к коду, который вылетел, даст вам стек вызовов и т. Д.
Чтобы использовать WinDbg, вам нужно прыгнуть через пару обручей:
- Запустить WinDbg
- Откройте файл дампа. ( Ctrl + D по умолчанию)
- Скажите WinDbg, чтобы он получил правильные файлы символов MicroSoft. Тип
.symfix. Это может занять несколько минут, так как из Интернета выйдет куча вещей.
- Сообщите WinDbg, где находятся символы (файлы PDB). Введите
.sympath+ c:\pdblocation, подставляя вместо пути куда-нибудь файлы PDB. Убедитесь, что вы получили знак «плюс» без пробелов между .sympath и +, иначе вы испортите шаг 3.
- Сообщите WinDbg, где находится исходный код. Введите
.srcpath c:\app_build_1.0.100, подставив путь, по которому вы получили код из системы контроля версий для этой версии программного обеспечения.
- Скажите WinDbg проанализировать файл дампа. Тип
!analyze -v
Через несколько секунд, если все настроено правильно, WinDbg доставит вас прямо к месту вашего сбоя. На данный момент у вас есть миллион опций для глубокого изучения пространства памяти вашего приложения, состояния критических разделов, окон и т. Д. Но это способ вне рамок этого поста.
Удачи!