Tools to analyzing the memory footprint of native DLLs and assemblies loaded in a process?

Question

I have a process holding 130MB of memory according to task manager, with only 11MB of live .NET objects according to dotTrace so I am wondering what's happening with the other 120MB??

I'd need a tool to list assemblies and native DLLs loaded in a process, gets the size of the images in process, and, for each assembly, measure the memory footprint of the methods JITed.

ListDlls from SysInternal does partly that job. But it doesn't measure JITed code size and it just provides raw data. Ideally I'd like a UI to analyze and sum-up these data.

Recently, the Visual Studio team reported having done such analysis with the tool PerfView. This is stated in the blog post Visual Studio 11 Beta Performance Part #1, section: The Biggest VM Consumer - DLLs. Does someone has experience and feedback analyzing native Dlls and assemblies footprint with PerfView?

Except ListDlls and PerfView, would you recommend any other tool?

---

Ok, VMMAP advised by Simon Mourier seems to be the more suited tool for this task. VMMAP shows that the bulk of working set memory goes into the Managed Stack (113MB in green below), so the problem is more related to .NET objects than unmanaged memory. The green saw tooth curve, is just a timeline of loading/unloading sessions. For some reasons, my first measures were quite wrong:

• dotTrace tells me I have 41MB of .NET objects allocated,
• WMMAP shows a working set of 180MB (task manager shows a similar number)
• WMMAP shows 113MB of managed heap allocated by the GC. 90MB of this managed heap memory is in the working set:

So my plan is:

1. Identify why the GC allocates 113MB of managed heap for 41MB of .NET objects? (are such numbers normal? is it due to high fragmentation?)
2. Work on shrinking this 41MB set of .NET objects allocated!

Square

Answer 1

Since you mention sysinternals' ListDlls, there is another tool called Process Explorer that has tons of information, and is much much better than ListDlls (you want to make sure you have the latest versions that also has a lot of .NET information, supports 64-bit and 32-bit processes, etc.).

For each process, you can have a simultaneous views of unmanaged memory (private bytes et al.) and managed memory (GC collections, large object heap, etc.) displayed in columns or per process.

Another cool tool from sysinternals is VMMAP. It's a process memory analysis utility and shows a breakdown of different types of virtual and physical memory types.

As for you 120Mb question, you really want to check all unmanaged DLLs that are injected in your process and are not part of standard Windows installation or standard DLL set of processes. For such big size allocations, I would first track graphical components of course as they are notably known for allocation big chunks of memory (especially if you speak about a tool such as NDepend which is graphical). Process Explorer can also tracks the number of GDI and USER objects.

On the GDI topic, there is a free tool named GDIView available here that gives a details of GDI objects allocated per process.

Dekeles

Hi my friend Simon, I'll try VMMAP since indeed in the VS11 blog post they mention it, but they mention as well they did a tool above VMMAP to harness its results. I'll try as well GDIView that I didn't know about! Thanks – Square

Thanks Simon, VMMAP is of great help to have the big picture. My findings this morning seems to advocate that it is more a GC/managed memory issue than unmanaged issue. See precisions above. Any idea why the GC holds 113MB of managed memory for 41MB of .NET objects? – Square

@PatrickfromNDependteam - If it's managed, then you should dive into SOS (msdn.microsoft.com/en-us/library/bb190764.aspx) using Windbg or Visual Studio (blogs.msdn.com/b/vancem/archive/2006/03/07/545596.aspx) and use the famous objsize command. It will dump the list of .NET objects, among others. Process Explorer (newest versions) is also capable of displaying GC stats. You probably want to take also a look at the Large Object Heap, or LOH (msdn.microsoft.com/en-us/magazine/cc534993.aspx) which is very special heap (it cannot be compacted) – Dekeles

Thanks Simon, I have been trying SOS a long time ago and will deep dive in it for this session! – Square

Could you identify the reason why GC allocates (store) more memory than all live .net objects? – Skied

Answer 2

I recommend SciTech .NET Memory Profiler. The tool is primary aimed at profiling .NET memory usages, such as finding .NET memory leaks or identifying zones of heavy memory pressure. While not its main usage, it also has a simpler display of native memory, including JIT code size per loaded library. I'm sure you'll be able to find where those 120 MB come from with this kind of information.

Trophoblast

I've just tried out the v4 version of SciTech .NET Memory Profiler, but unfortunately with this tool the bulk of unmanaged memory falls in: Physical Memory > Private > Code (13.3MB) > <Unidentified> (13MB) and Physical Memory > Private > Unidentified unmanaged heaps (130MB) > data (121MB) – Square

Btw, I put the profiling level to high to get these results, but I guess profiling level is more related to managed objects than to unmanaged ones. – Square

Answer 3

I use RedGate ANTS .NET Developer Bundle for these issues. Memory Profiler allows to identify memory leaks (like zombies objects) and to make snapshots of memory usage. You'll then be able to compare classes and instances between two snapshots. You can track down instance reference in a tree and easily view the top object who maintain the reference.

Besides, Performance Profiler provides code profiling to identify bottlenecks and CPU usage.

For years now, it helped us alot to find application problems within minutes.

Hesperidium

I love RedGate ANTS .NET Memory Profiler, but the current version doesn't have any option to analyze the unmanaged 120MB of my process. – Square

6.0: red-gate.com/supportcenter/content/ANTS_Memory_Profiler/help/…. 7.0: red-gate.com/supportcenter/…. I don't have the 7.0 here but should help a bit even if I don't know which informations are available for unmanaged memory. – Hesperidium

6.0 correct link : red-gate.com/supportcenter/content/ANTS_Memory_Profiler/help/… . Indeed, the provided informations seems vague for the 7.0. – Hesperidium