Как открыть аварийный дамп C# (минидамп)

Наше приложение C# вызывает MinidumpWriteDump при возникновении необработанного исключения.

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

Мы используем тип дампа MiniDumpWithPrivateReadWriteMemory.

У меня _NT_SYMBOL_PATH настроен на использование общедоступного сервера символов MS, и при отладке этого аварийного дампа в WinDBG он автоматически загружает необходимые библиотеки DLL (поскольку этот дамп был взят на машине с другой версией .NET 2, а именно той, которая заканчивается с .3053)

При запуске !Threads я получаю этот вывод:

Не удалось запросить ThreadStore

Я просмотрел ВСЕ ВОЗМОЖНЫЕ сайты, которые объясняют методы работы с различными версиями CLR, кроме той, что была взята на машине дампа, ни один из них не работал у меня.

Что я могу сделать, чтобы отладить эти сбои?

Мы делаем что-то не так (берем неправильный дамп из процесса .NET и т. д.)

РЕДАКТИРОВАТЬ:

Вот результат ~*:

0:000> ~* . 0 Id: 1338.258 Suspend: 0 Teb: 7ffdf000 Unfrozen Priority: 0 1 Id: 1338.2a0 Suspend: 0 Teb: 7ffde000 Unfrozen Priority: 0 2 Id: 1338.1fd4 Suspend: 0 Teb: 7ffdd000 Unfrozen Priority: 0 3 Suspends Priority: 0 3 Suspends1 Id: 13e81 : 0 Teb: 7ffda000 Unfrozen Priority: 0 4 Id: 1338.1148 Suspend: 0 Teb: 7ffd9000 Unfrozen Priority: 0 5 Id: 1338.b1c Suspend: 0 Teb: 7ffd7000 Unfrozen Priority: 0 6 Id: 1338.f94 Suspend: 0 Teb: 7ffd4000 Unfrozen Priority: 0 7 Id: 1338.11b4 Suspend: 0 Teb: 7ff4f000 Unfrozen Priority: 0 8 Id: 1338.1814 Supend: 0 Teb: 7ff4e000 Unfrozen Priority: 0 9 Id: 1338.1cc4 Suspend: 10 Teb: Unfrozen 0 0 7ffdrob Id: 1338.1e48 Suspend: 0 Teb: 7ffd5000 Unfrozen Priority: 0 11 Id: 1338.1a5c Suspend: 0 Teb: 7ff4c000 Unfrozen Priority: 0 12 Id: 1338.1874 Suspend: 0 Teb: 7ff4b000 Unfrozen Priority: 0 13 Unfrozen Suspend: 13 13 Unfrozen Suspend 1d. : 0 Теб: 7ff4a000 Разморозить Приоритет: 0

Вот результат !analyze -v:

анализ


debugging c# crash-dumps windbg minidump
person lysergic-acid    schedule 09.08.2011    source источник
comment
Что произойдет, если вы откроете файл аварийного дампа в Visual Studio?   -  person Philipp Schmid    schedule 09.08.2011
comment
Наше приложение использует .NET 3.5 и VS2008, поэтому его нельзя открыть таким образом (насколько мне известно, только запуск .NET 4 и VS2010).   -  person lysergic-acid    schedule 09.08.2011
comment
Не знаю, является ли это вашей проблемой, но обычно создание мини-дампа из самого аварийно работающего приложения ненадежный (см. раздел "Примечания").   -  person Christian.K    schedule 09.08.2011
comment
Это работает нормально, только эти конкретные сбои, которые были сделаны в другой версии OS/.NET, похоже, доставляют трудности. Каковы альтернативы для получения его из того же процесса?   -  person lysergic-acid    schedule 10.08.2011
comment
@Christian Получение дампа процесса из того же процесса может привести к взаимоблокировке, но, вообще говоря, если вам удалось создать дамп, вы должны предположить, что все в порядке.   -  person Justin    schedule 10.08.2011
comment
@liortal Альтернативой является создание отдельного процесса-наблюдателя (по мере запуска процесса - задолго до возникновения исключения) для наблюдения за процессом и создания дампа процесса. Это довольно много усилий, и если нет требований к высокой доступности, я, вероятно, просто соглашусь с тем, что ваш процесс может зайти в тупик из-за необработанного исключения.   -  person Justin    schedule 10.08.2011
comment
@Kragen Да, это то, что написано на странице msdn, и я не могу сказать, что у меня здесь слишком много опыта. Что я знаю из UNIX, так это то, что, скажем, когда ваша куча повреждена, все ставки сняты. Больше не так уж много можно надежно сделать. Но похоже, проблема не в нативной проблеме, так что все может быть в порядке.   -  person Christian.K    schedule 10.08.2011
comment
Я не уверен, вызывает ли сбой процесса повреждение кучи (если, конечно, сбой не произошел из-за поврежденной кучи, сценарий, который обычно должен быть обойден самой CLR). Событие UnhandledException существует для того, чтобы выполнить некоторый код перед сбоем. Мне трудно поверить, что они позволили бы вашему коду выполняться, когда куча повреждена или какая-то другая проблема, которая может помешать созданию файла дампа.   -  person lysergic-acid    schedule 10.08.2011

Ответы (2)


arrow_upward
2
arrow_downward

WinDbg, вероятно, загружает неправильную версию DLL mscorwks. Попробуйте использовать .cordll -lp, чтобы явно указать WinDbg, какие модули отладки CLR он должен загружать, см. также эту запись в блоге: Проблемы с отладкой управляемого кода в WinDbg с помощью SOS и PSSCOR2 (например, "Не удалось запросить ThreadStore")

person floyd73    schedule 10.08.2011
comment
Пробовал, не помогло. Я начинаю думать, что причиной может быть тип минидампа. - person lysergic-acid; 10.08.2011
comment
Я думаю, вы правы, только MiniDumpWithPrivateReadWriteMemory может быть недостаточно для получения нужной вам информации. - person floyd73; 10.08.2011
comment
Информация, которую я хочу, - это управляемое исключение и, возможно, стеки вызовов во время сбоя. - person lysergic-acid; 10.08.2011
comment
Вы пробовали !analyze -v ? Это должно дать вам подробную информацию об исключении. И просто любопытно, что вам дает ~*? В нем должны быть перечислены все ваши (собственные) потоки, затем вы можете проверить, есть ли информация о потоке или нет. - person floyd73; 11.08.2011
comment
хорошо, поэтому я думаю, что хорошая новость заключается в том, что у вас есть информация о запущенных потоках, но я все еще думаю, что загруженные символы для .net неверны (см. IP-адрес кадра не в каком-либо известном модуле. Следующие кадры могут быть неправильными в стек вызовов из вывода команды анализа). - person floyd73; 11.08.2011
comment
(продолжение, нажали ввод по ошибке): так что кажется, что исключение исходит из потока с идентификатором 258, который является потоком 0, и это уже активный поток, поэтому !clrstack теперь должен показать вам стек вызовов управляемого кода и, надеюсь, место кода, где исключение был брошен (то есть при условии, что загруженные символы верны) - person floyd73; 11.08.2011
comment
я бы хотел, чтобы !clrstack работал :( если бы это было так, я бы не поднимал здесь этот вопрос. - person lysergic-acid; 11.08.2011
comment
тоже не работает? (вы упомянули только !Threads в своем посте). Ну тогда опять думаю, что у вас все-таки неправильные символы. У вас есть доступ к машине с целевой платформой версии .net или к другой машине с установленной точно такой же версией? Затем вы можете скопировать оттуда mscorwks и связанные файлы и явно загрузить эту версию в windbg. Тот факт, что у вас есть IP-адрес фрейма, которого нет ни в одном известном модуле в вашем стеке вызовов, убедительно свидетельствует о несоответствии или несуществующих символах. Вы проверили загруженные символы с помощью lm? - person floyd73; 11.08.2011
comment
У меня был определен общедоступный сервер символов MS, он автоматически загружает pdb и необходимые dll. Я не уверен, нужно ли мне также настраивать Windbg для их загрузки или он делает это автоматически. но ничего не сработало, и я все еще не могу запускать потоки clrstack или любые другие команды, связанные с SOS. - person lysergic-acid; 11.08.2011
comment
Я думаю, что сервера символов недостаточно, windbg также должен найти точно такие же версии библиотеки mscorwks и sos, что и на целевой машине. Как вы загружаете расширение SOS? Вы пытались использовать mscorwks .loadby sos.dll? А расширение PSSCOR2 пробовали? Обычно я использую его вместо SOS, поскольку в нем обычно есть все, что мне нужно (и даже больше), и я обнаружил, что он не так педантичен в отношении версии mscorwks, а также включает такие команды, как !clrstack. - person floyd73; 11.08.2011
comment
Я думаю, что psscor2 использует SOS за кулисами? (в этом я могу ошибаться). Я пытался загрузить sos как с помощью .loadby, так и с помощью загрузки SOS.dll. я взял версию, которая соответствует mscorwks, и загрузил ее, но ничего хорошего. - person lysergic-acid; 11.08.2011

arrow_upward
1
arrow_downward

Вам нужно изменить параметры, которые вы передаете «MiniDumpWriteDump», убедитесь, что они содержат параметры, упомянутые здесь: dump-native-c-process-that-hosts-net-com">Какой минимальный параметр MINIDUMP_TYPE установлен для создания дампа собственного процесса C++, на котором размещен компонент .net, чтобы можно было использовать !clrstack в WindBG

person Stanislav Berkov    schedule 25.11.2011