Я пытаюсь использовать windbg для исследования файла дампа зависания, созданного на машине x64 для нашего процесса x86. Это приложение 4.0 x86, поэтому для получения неуправляемого стека мне нужно было сделать следующее:
.loadby sos clr
.load wow64exts
!sw
kL
Однако каждый раз, когда я пытаюсь получить управляемый стек через !clrstack, я получаю ошибку в заголовке. Что мне не хватает?
Я считаю, что вам нужно будет использовать 32-разрядный диспетчер задач, расположенный в C:\Windows\SysWOW64\taskmgr.exe, чтобы получить 32-разрядный дамп.
Дополнительная информация здесь: http://blogs.msdn.com/b/tess/archive/2010/09/29/capturing-memory-dumps-for-32-bit-processes-on-an-x64-machine.aspx
Как уже говорили другие, это может быть вызвано 64-разрядным приложением (например, Диспетчер задач по умолчанию), создающим файл дампа 32-разрядного процесса.
Мне удалось решить проблему, используя расширение soswow64 WinDbg от poizan42 на GitHub. Я нашел его через эту запись в блоге, в которой также содержится более подробная информация о проблеме.
Я всегда следил за рекомендацией соответствия битту, но не знал точно, почему, пока я не наткнулся на эту статью: http://blogs.msdn.com/b/dotnet/archive/2013/05/01/net-crash-dump-and-live-process-inspection.aspx, который гласит:
"ЦАП имеет стандартизованный интерфейс и используется отладчиком для получить информацию о состоянии этих абстракций, например, управляемая куча. Крайне важно использовать ЦАП, который соответствует CLR версии и архитектуры процесса или дампа сбоя, который вы хотите инспектировать".
и
"Обратите внимание, что ЦАП является родной DLL и должен быть загружен в программу который использует ClrMD. Если дамп или живой процесс 32-бит, вы должны используйте 32-разрядную версию ЦАП, что, в свою очередь, означает, что ваш инспекционная программа также должна быть 32-битной. То же самое верно для 64-битные процессы. Убедитесь, что ваша программная платформа соответствует тому, что вы отлаживаете".
Есть еще один вариант, который работал у меня: - У меня был аварийный сброс 64-битного процесса. - Итак, во-первых, мне потребовались файлы SOS.dll и mscordacwks.dll с компьютера (C:\Windows\Microsoft.NET\Framework64\v4.0.30319), где была сделана свалка. - На основе двух статей msdn (http://msdn.microsoft.com/en-gb/library/windows/hardware/ff562263%28v=vs.85%29.aspx, http://msdn.microsoft.com/en-gb/library/windows/hardware/ff540665%28v=vs.85%29.aspx), я загрузил CLR следующим образом:
.cordll -u -ve -I clr -lp <path to SOS.dll & mscordacwks.dll>
После этого работали нити. Я думаю, что то же самое должно применяться для 32-разрядных аварийных дампов.