Analyzing a CLR .dmp file in WinDbg

14,642

Solution 1

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

You would have to use the x86 debugger/WinDbg to debug an x86 memory dump. Use .loadby sos mscorwks to load the appropriate sos. You could also verify if the extension is loaded properly by using the .chain command.

Tess has some good debugging tutorials.

Solution 2

This tutorial is a good start to see some of the 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

Solution 3

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

Some good starting links are here.

Share:
14,642
Sxl
Author by

Sxl

CodeProject profile: http://www.codeproject.com/script/Membership/View.aspx?mid=1407319 MSDN profile: http://social.msdn.microsoft.com/profile/paulh79/

Updated on June 04, 2022

Comments

  • Sxl
    Sxl almost 2 years

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

    I have been able to get the .dmp file from the PC and take it back to my Windows 7 64-bit development PC and load it into WinDbg 6.12.

    But, I can't see any code in the call stack from my C# application. It looks like it's entirely a native call stack.

    The result from !analyze -v is below.

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

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

    How can I view the 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
    ---------
    
  • Sxl
    Sxl about 13 years
    .load sos yields The call to LoadLibrary(sos) failed, Win32 error 0n193
  • Sxl
    Sxl about 13 years
    @Naveen - My development PC is Win 7 64-bit. Can I use the x86 debugger or do I need to create a 32-bit VM to run that in?
  • Lex Li
    Lex Li about 13 years
    Debugging tools for Windows x86 must be used (matching dump bitness). A 32 bit VM also works, but not necessary.
  • Lex Li
    Lex Li about 13 years
    Once the dump is open and SOS is loaded, !CLRStack or !pe can show you the call stack or exception.
  • Sxl
    Sxl about 13 years
    I went to the microsoft site to download the Debugging Tools For Windows 32-bit Version which lets me download the Windows SDK for Windows 7 and .NET framework 4. In that installer, I can only choose to install Debugging Tools for Windows. I don't have a choice between a 64 and 32 bit version. After installing, all I can find is WinDbg:6.12.0002.633 AMD64
  • Naveen
    Naveen about 13 years
    Here is a link for previous version of windbg for x86 msdn.microsoft.com/en-us/windows/hardware/gg463016#ERD
  • Lex Li
    Lex Li about 13 years
    It is a shame that Microsoft makes things bad. You don't need the latest version in most scenarios, and a previous version should work. Besides, if you want to try the latest, simply download the SDK ISO, and the 32 bit installer is in it.