MiniDumpWriteDump и писать несколько дампов для одного и того же сбоя?

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

Следует ли писать большой дамп перед маленьким? Я не считаю, что порядок важен для сбоев, зависаний и т. д. типичных проблем. место аварии там, тупик на свалке, первый или после захвата.

Стоит ли нам писать два дампа? Я бы посоветовал написать хотя бы 1 полный дамп, небольшой дамп очень удобен для вас, чтобы получить первоначальное представление о проблеме, но он очень ограничен, особенно. когда ваше приложение вылетает. поэтому вы можете предложить клиенту отправить вам по электронной почте небольшой дамп для выполнения первой проверки, если это не поможет вам найти основную причину, затем запросите полный дамп. технически вы можете вырезать небольшой дамп из полного дампа, однако вы можете не захотеть, чтобы ваш клиент выполнял такую ​​работу за вас. так что это зависит от того, как вы взаимодействуете со своим клиентом.

Можно ли каким-то образом заставить систему сначала приостановить потоки процесса, а затем записать два полностью "синхронных" дампа?

технически это выполнимо. например относительно легко выполнить out-proc, простой NtSuspendProcess () приостанавливает все целевые потоки, но его нужно вызывать из другого процесса. если вы предпочитаете внутрипроцесс, вам нужно перечислить все потоки и вызвать SuspendThread (), вот как работает MiniDumpWriteDump (). Однако я думаю, что sync / asyn не влияет на точность дампа.

Записывать два дампа одновременно не рекомендуется, потому что MiniDumpWriteDump не является потокобезопасным.

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

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

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

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

Лучше сначала написать минидамп, а потом большой дамп. Таким образом, у вас больше шансов получить данные быстро, а не ждать полного дампа. Полный дамп может занять некоторое время, когда пользователи часто нетерпеливы. Они могут решить остановить процесс, чтобы вернуться к работе. Кроме того, если диск заполняется (что может быть причиной сбоя), вероятность того, что у вас есть место для мини-дампа, несколько выше, чем для полного дампа.

DbgHelp.dll импортирует SuspendThread и ResumeThread. Вы можете сделать то же самое. Вызовите SuspendThread для всех потоков (за исключением текущего, конечно), вызовите MiniDumpWriteDump столько раз, сколько вам нужно, а затем вызовите ResumeThread для каждого приостановленного потока. Это должно дать вам стабильно точные дампы.