All geek questions in one place

Analysis of the CLR.dmp file in WinDbg

I have a C # .NET 3.5 application created in Visual Studio 2008, crashing on a PC with Windows XP SP3 (x86) without a development environment.

I managed to get the .dmp file from the PC and return it to my 64-bit PC for Windows and nbsp; 7 and load it into WinDbg 6.12.

But I do not see any code in the call stack from my C # application. It looks like this is a completely native call stack.

The result from !analyze -v below.

I have the corresponding EXE, DLL and PDB files in the same directory as .DMP. The corrected executable was compiled in debug mode.

I also have Visual Studio 2008, if it's easier to use. But opening the dump file there also shows only its own call stack, nothing from my code.

How to view CLR call stack?

 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 ---------
+4
source share
3 answers

Managed code needs the appropriate sos.dll platform for proper analysis. using the "x86" debugger.

You will need to use x86 debugger / WinDbg to debug the x86 memory dump. Use .loadby sos mscorwks to download the appropriate file. You can also verify that the extension has loaded correctly using the .chain .

Tess has some good debugging tutorials.

+6
source

This tutorial is a good start to view some WinDbg commands. I think the following commands should show you the current stack trace:

 .sympath SRV*d:\localsymbols*http://msdl.microsoft.com/download/symbols !reload .loadby sos mscorwks K
+3
source

Debugging managed crash dumps in WinDbg requires additional modules (primarily SOS.dll) and commands.

Some good starting links are here .

+1
source

Source: https://habr.com/ru/post/1341383/

More articles:


All Articles