Анализ файла CLR .dmp в WinDbg - PullRequest
       13

Анализ файла CLR .dmp в WinDbg

4 голосов
/ 26 февраля 2011

У меня есть приложение C # .NET 3.5, созданное в Visual Studio 2008, которое падает на ПК с Windows XP SP3 (x86) без среды разработки.

Мне удалось получить файл .dmp изПК и верните его на мой 64-разрядный компьютер под управлением Windows 7 и загрузите его в WinDbg 6.12.

Но я не вижу кода в стеке вызовов из моего приложения на C #.Похоже, что это полностью собственный стек вызовов.

Результат от !analyze -v ниже.

У меня есть соответствующие файлы EXE, DLL и PDB в том же каталоге, что и .DMP,Сбой исполняемого файла был скомпилирован в режиме отладки.

У меня также есть Visual Studio 2008, если это проще в использовании.Но открытие файла дампа там также показывает только собственный стек вызовов, ничего из моего кода.

Как я могу просмотреть стек вызовов CLR?

0:004> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


FAULTING_IP:
kernel32!RaiseException+53
7c812afb 5e              pop     esi

EXCEPTION_RECORD:  0392f018 -- (.exr 0x392f018)
ExceptionAddress: 7c812afb (kernel32!RaiseException+0x00000053)
   ExceptionCode: e0434f4d (CLR exception)
  ExceptionFlags: 00000001
NumberParameters: 1
   Parameter[0]: 80070057

PROCESS_NAME:  foo.exe

ERROR_CODE: (NTSTATUS) 0xe0434f4d - <Unable to get error code text>

EXCEPTION_CODE: (NTSTATUS) 0xe0434f4d - <Unable to get error code text>

EXCEPTION_PARAMETER1:  80070057

MOD_LIST: <ANALYSIS/>

MANAGED_STACK: !dumpstack -EE
No export dumpstack found

MANAGED_BITNESS_MISMATCH:
Managed code needs matching platform of sos.dll for proper analysis. Use 'x86' debugger.

ADDITIONAL_DEBUG_TEXT:  Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[PSEUDO_THREAD]

LAST_CONTROL_TRANSFER:  from 79ef2bfc to 7c812afb

FAULTING_THREAD:  ffffffff

DEFAULT_BUCKET_ID:  STACKIMMUNE

PRIMARY_PROBLEM_CLASS:  STACKIMMUNE

BUGCHECK_STR:  APPLICATION_FAULT_STACKIMMUNE_NOSOS_CLR_EXCEPTION

STACK_TEXT:
00000000 00000000 foo.exe+0x0


SYMBOL_NAME:  foo.exe

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: foo

IMAGE_NAME:  foo.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4d5da0cd

STACK_COMMAND:  ** Pseudo Context ** ; kb

FAILURE_BUCKET_ID:  STACKIMMUNE_e0434f4d_foo.exe!Unknown

BUCKET_ID:  APPLICATION_FAULT_STACKIMMUNE_NOSOS_CLR_EXCEPTION_foo.exe

Followup: MachineOwner
---------

Ответы [ 3 ]

6 голосов
/ 27 февраля 2011

Управляемому коду требуется соответствующая платформа sos.dll для правильного анализа.Используйте отладчик x86.

Для отладки дампа памяти x86 потребуется отладчик x86 / WinDbg .Используйте .loadby sos mscorwks для загрузки соответствующего sos.Вы также можете проверить, правильно ли загружено расширение, используя команду .chain.

У Тесс есть несколько хороших учебников по отладке.

3 голосов
/ 26 февраля 2011

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

.sympath SRV*d:\localsymbols*http://msdl.microsoft.com/download/symbols
!reload
.loadby sos mscorwks
K
1 голос
/ 26 февраля 2011

Для отладки управляемых аварийных дампов в WinDbg требуются дополнительные модули (в первую очередь SOS.dll) и команды.

Некоторые хорошие стартовые ссылки здесь .

...