Skip to content

Myth busting Memory Dumps

Nikolay Mitikov edited this page Aug 2, 2017 · 1 revision

What is that ?

User-mode memory dump is a snapshot of a single process. It contains selected data records:

  • Full or partial (filtered) process memory;

  • List of the threads with their call stacks and state (such as registers or TEB);

  • Information about handles to the kernel objects; list of loaded and unloaded libraries.

What does it mean in human-friendly manner?

Form a single memory dump we can see:

  • Threads call stacks -> what does each thread do
  • Time taken by thread in user/kernel modes -> how much time did thread consume in total since created
  • Thread stack objects -> variables that were not optimized
  • Objects count by types
  • Exact object fields -> like sting values, pointers to other objects and so on
  • Who is waiting or owns Monitors ( C# locks ) -> threads waiting to lock(some_object)
  • Why exact object is not picked by Garbage Collector -> who references an object and acts as a GC root
  • Current exception ( if any )

To get all that useful information a translator that will transform binary data into human-understandable entities is needed.

.NET Framework "clr.dll" and "sos.dll" assemblies of same version as on machine that produced memory snapshot are needed.

Luckily can be collected by SSPG .NET Framework assemblies, or manually from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ folder.


Q: Can I find out why my solution is slow from a single snapshot ?

ANSWER: NO. At least 2 memory snapshots collected in near interval can give a clue.


Having 2 snapshots would allow to find a thread that had taken most of all CPU time, and start investigating its call stack.

However it still could be not enough:

  • There is no suspicious thread that have consumed far more time than others
  • A most time consuming thread does nothing in both snapshots

Q: Can I check cache statistics ?

ANSWER If a cache is based on an Object, than YES.


Typically caches are based on Hashtables, or Concurrent collections, thus finding a correct collection object instance and examine its state can bring needed information.


You can also try to get actual cache object size via ObjSize SOS command, but it is so sloooww on large snapshots =/

Q: I can open memory dump file manually, is that true ?


ANSWER YES, more details can be found here.

Q: What commands should I execute?

Cheat sheet, and MSDN should you use wisely. Tons of commands there are.

Practice and patience will help you to become a Jedi :)

You can’t perform that action at this time.