Is there a heap_stat equivalent for dump analysis of C# applications?

Question

For a previous employer, while performing dump analysis, I have regularly used heap_stat.py, based on PYKD library for Windbg.

I believe heap_stat.py script only works for C/C++ development. Is there an equivalent for C# applications?

Thanks in advance

I've tried to start up !Dumpheap -stat, but loading the SOS extension seems to be a challenge:

Windbg 32-bit:

0:000> .loadby sos clr
0:000> !dumpheap -stat
SOS does not support the current target architecture.

Windbg 64-bit:

0:000> .loadby sos clr
The call to 
LoadLibrary(C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll) 
failed, Win32 error 0n193
    "%1 is not a valid Win32 application."
Please check your debugger configuration and/or network access.
0:000> .load sos
0:000> !Dumpheap -stat
No export Dumpheap found

Windbg preview:

0:000> .loadby sos clr
The call to 
LoadLibrary(C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll) 
failed, Win32 error 0n193
    "%1 is not a valid Win32 application."
Please check your debugger configuration and/or network access.
0:000> .load sos
0:000> !Dumpheap -stat
No export Dumpheap found

How can I load the SOS extension and launch that !Dumpheap -stat command?

Answer 1

The problem

Your crash dump has the wrong bitness. Most likely nowadays that's because you have used Task Manager on a 64 bit system and created a crash dump of a 32 bit application.

Windows comes with two versions of Task Manager: a 64 bit version (C:\Windows\System32\Taskmgr.exe) and a 32 bit version (C:\Windows\SysWOW64\Taskmgr.exe). The path names are somewhat confusing. System32 refers to the native bitness of the OS, which is 64 bit. And WoW64 means Windows 32 bit on Windows 64 bit, which is 32 bit.

Preventing the problem in the future

Have a look at How do I take a good crash dump for .NET? for tools that automatically detect the bitness and create a nice crash dump for you.

Microsoft does still not provide MSCORDAC DLLs (the Microsoft Common Object Runtime Data Access Component) cross-bitness. Therefore your best choice is totake 32 bit crash dumps of 32 bit .NET applications and 64 bit crash dumps of 64 bit .NET applications.

Fixing the problem if you have no other choice

However, there's a fix:

1. Use a 32 bit version of the normal WinDbg (10.0.x.x). WinDbg preview will probably not work, because it creates a child process with the bitness of the dump. You can't load the 32 bit DLL into a 64 bit process.
2. Switch the dump to x86 using .effmach x86
3. Get a copy of soswow64.
4. Load soswow64 using .load and the full path
5. Now load SOS using .loadby sos clr as usual

0:000> .effmach x86
Effective machine: x86 compatible (x86)

0:000:x86> .loadby sos clr
0:000:x86> !dumpheap -stat
SOS does not support the current target architecture.

0:000:x86> .unload sos
Unloading C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos extension DLL

0:000:x86> .load C:\Users\T\Downloads\soswow64\soswow64
Successfully hooked IDebugControl::GetExecutingProcessorType.
Successfully patched DbgEng!X86MachineInfo::ConvertCanonContextToTarget.

0:000:x86> .loadby sos clr

0:000:x86> !dumpheap -stat
*** WARNING: Unable to verify checksum for System.Windows.Forms.ni.dll
Automatically loaded SOS Extension
CLRDLL: Loaded DLL C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscordacwks.dll
c0000005 Exception in C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dumpheap debugger extension.
      PC: 07261643  VA: 00000000  R/W: 0  Parameter: 00000000


0:000:x86> !dumpheap -stat
Statistics:
      MT    Count    TotalSize Class Name
[...]

Note that the access violation exception for the first SOS command is usual. Just repeat the command.