Да, это то, что каждая программа должна иметь и использовать как можно чаще.
Я полагаю, что вы не используете сторонние библиотеки. Вместо этого создайте свои собственные дампы. Это очень просто и прямо. Вам в основном нужно сделать следующее:
Ваша программа должна получить доступ к dbghelp.dll . Это Windows DLL, которая позволяет создавать читаемые стеки вызовов и т. Д. Отладчик использует эту DLL для отображения данных в вашем процессе. Он также обрабатывает отладку после вскрытия, т.е. Эта DLL может безопасно распространяться с вашим программным обеспечением. Я предлагаю вам загрузить и установить Средства отладки для Windows . Это даст вам доступ ко всем видам инструментов и лучшему инструменту WinDbg.exe , а последняя версия dbghelp.dll также находится в этом дистрибутиве.
В dbghelp.dll вы называете e.g. MiniDumpWriteDump () , который создаст файл дампа, и это более или менее так. Вы сделали Как только у вас есть этот файл в ваших руках, вы можете начать использовать его. Либо в отладчике Visual Studio, который, вероятно, даже может быть связан с расширением файла .dmp, либо в WinDbg.
Теперь есть несколько вещей, о которых нужно подумать, пока вы на нем. При проверке подобных файлов дампа вам нужно создавать файлы .pdb при компиляции и компоновке исполняемого файла. В противном случае нет никакой возможности отобразить данные дампа в удобочитаемые данные, например, чтобы получить хорошие стеки вызовов и значения переменных и т. д. Это также означает, что вы должны сохранить эти файлы .pdb. Вы должны быть в состоянии сопоставить их именно с этим выпуском. Так как файлы дампа помечены датой с меткой даты исполняемого файла, отладчику нужны точные файлы pdb. Неважно, если ваш код не изменился ни на один бит, если файлы .pdb принадлежат другому сеансу компиляции, вы тост.
Я призываю всех разработчиков windows win32 зайти на сайт Олега Стародумова DebugInfo.com . Он содержит множество примеров и учебных пособий, а также способы настройки и настройки генерации файла дампа. Есть, конечно, множество способов исключить определенные данные, создать свое собственное отладочное сообщение, присоединить его к дампу и т. Д.
Имейте в виду, что мини-дампы будут содержать очень ограниченную информацию о состоянии приложения во время исключения. Компромисс - это небольшой файл (около 50-100 кБ в зависимости от ваших настроек). Но если вы хотите, вы можете создать full dump, который будет содержать состояние всего приложения, то есть глобальных переменных и даже объектов ядра. Эти файлы могут быть ОГРОМНЫМИ и должны использоваться только в крайних случаях.
Если есть юридические аспекты, просто убедитесь, что ваши клиенты знают о том, что вы делаете. Бьюсь об заклад, у вас уже есть контракт, по которому вы не должны раскрывать бизнес-секреты или другие юридические аспекты. Если клиенты жалуются, убедите их, насколько важно находить ошибки и что это резко улучшит качество программного обеспечения. Более-менее высокое качество за счет ничего. Если это им ничего не стоит, это тоже хороший аргумент:)
Наконец, вот еще один замечательный сайт, если вы хотите узнать больше об анализе аварийных дампов: dumpanalysis.org
Надеюсь, это поможет. Пожалуйста, прокомментируйте, если вы хотите, чтобы я объяснил больше.
Ура!
Edit:
Просто хотел добавить, что MiniDumpWriteDump () требует наличия указателя на структуру MINIDUMP-EXCEPTION-INFORMATION (с подчеркиванием). Но макрос GetExceptionInformation () обеспечивает это для вас во время исключения в вашем обработчике исключений (структурированная обработка исключений или SEH):
__try {
}
__except (YourHandlerFunction(GetExceptionInformation())) {
}
YourHandlerFunction () будет заниматься созданием минидампа (или какой-либо другой функции в цепочке вызовов). Кроме того, если у вас есть пользовательские ошибки в вашей программе, например, происходит что-то, что не должно происходить, но технически не является исключением, вы можете использовать RaiseException () для создания своего собственного.
GetExceptionInformation () может использоваться только в этом контексте и больше нигде во время выполнения программы.