Как извлечь отладочную информацию из аварии

Если мое приложение С++ сбой в Windows, я хочу отправить полезную информацию отладки на наш сервер.

В Linux я бы использовал функцию GNU backtrace() - есть ли эквивалент для Windows?

Есть ли способ извлечь полезную информацию об отладке после сбоя программы? Или только изнутри процесса?

(Совет по строкам "тестовое приложение, чтобы оно не разбилось" не полезно! - все нетривиальные программы будут иметь ошибки)

Ответ 1

Функция Stackwalk64 может использоваться для привязки трассировки стека в Windows.

Если вы намереваетесь использовать эту функцию, вы должны обязательно скомпилировать свой код с отключенным FPO - без символов, StackWalk64 не сможет правильно перемещать кадры FPO'd.

Вы можете получить код, запущенный во время сбоя через верхний уровень __try/__except, вызвав SetUnhandledExceptionFilter. Это немного ненадежно, так как для этого требуется, чтобы код выполнялся внутри разбитого процесса. Кроме того, вы можете просто встроенную отчетность об ошибках Windows собирать данные о сбоях. Это более надежно, так как это не требует, чтобы вы добавляли код, запущенный внутри взломанного, разбившегося процесса. Единственная стоимость - получить сертификат подписи кода, поскольку вы должны отправить подписанную бинарную услугу. https://sysdev.microsoft.com/en-US/Hardware/signup/ содержит более подробную информацию.

Ответ 2

Вы можете использовать вызов Windows API MiniDumpWriteDump, если вы хотите перевернуть свой собственный код. Как Windows XP, так и Vist автоматизируют этот процесс, и вы можете подписаться на https://winqual.microsoft.com, чтобы получить доступ к отчетам об ошибках.

Также проверьте http://kb.mozillazine.org/Breakpad и http://www.codeproject.com/KB/debug/crash_report.aspx для других решений.

Ответ 3

На этом веб-сайте представлен подробный обзор поиска стека на Win32 после исключения С++:

http://www.eptacom.net/pubblicazioni/pub_eng/except.html

Конечно, это будет работать только внутри процесса, поэтому, если процесс завершится или сработает до того момента, когда он завершится до запуска этого кода, он не будет работать.

Ответ 4

Создайте файл minidump. Затем вы можете загрузить его в windbg или Visual Studio и проверить весь стек, где произошел сбой.

Вот хорошее место для начала чтения.

Ответ 5

Его довольно просто сбросить текущие адреса стека в файл журнала. Все, что вам нужно сделать, это получить такую ​​функцию, называемую программными ошибками (т.е. Обработчик прерываний в Windows) или утверждает. Это можно сделать и в выпущенных версиях. Затем файл журнала можно сопоставить с картографическим файлом, в результате чего стек вызовов с именами функций.

Я опубликовал статью об этом несколько лет назад.

См. http://www.ddj.com/architect/185300443

Ответ 6

Позвольте мне описать, как я обрабатываю аварийные ситуации в своем приложении С++/WTL.

Во-первых, в основной функции я вызываю _ set_se_translator и передаю функцию, которая будет вызывать исключение С++ вместо использования структурированных окон исключения. Эта функция получает код ошибки, для которого вы можете получить сообщение об ошибке Windows через FormatMessage и аргумент PEXCEPTION_POINTERS, который вы можете использовать для записи minidump (код здесь). Вы также можете проверить код исключения для определенных ошибок "meltdown", из-за которых вам нужно просто заручиться, например EXCEPTION_NONCONTINUABLE_EXCEPTION или EXCEPTION_STACK_OVERFLOW:) (Если он восстанавливается, я предлагаю пользователю отправить мне этот файл minidump.)

Сам файл minidump можно открыть в Visual Studio, как обычный проект, и при условии, что вы создали файл .pdb для своего исполняемого файла, вы можете запустить проект и перейти к точному местоположению сбоя, вместе со стеком вызовов и регистрами, которые можно проверить из отладчика.

Ответ 7

Если вы хотите захватить стоп-колл (плюс другую полезную информацию) для сбоя во время выполнения, при выпуске сборки даже на сайте, вам нужно настроить Dr Watson (запустите DrWtsn32.exe). Если вы установите флажок "сгенерировать аварийные дампы", когда приложение сработает, он напишет файл мини-дампа указанному пути (так называемый user.dmp).

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

Получите windbg, откройте его и используйте опцию меню, чтобы "загрузить сбой". Как только он загрузит все, что вы можете набрать "~ # kp", чтобы получить стоп-колл для каждого потока (или нажмите кнопку вверху для текущего потока).

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

Ответ 8

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

Затем вы можете загрузить файл дампа на сервер для дальнейшего анализа с помощью анализаторов дампов, таких как windbg.

Ответ 9

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

Вы можете загрузить и установить инструменты отладки для Windows.

Использование adplus упоминается здесь: Использование Adplus

Это создает полный сбой или зависание. Когда у вас есть свалка, Windbg приходит на помощь. Сопоставьте правильные pdbs и символы, и вы все настроены на анализ дампа. Для начала используйте команду "! Anal -v"