Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Since you mention sysinternals' ListDlls, there is another tool called <a href="http://technet.microsoft.com/en-us/sysinternals/bb896653" rel="nofollow">Process Explorer</a> 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.).</p> <p>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.</p> <p>Another cool tool from sysinternals is <a href="http://technet.microsoft.com/en-us/sysinternals/dd535533" rel="nofollow">VMMAP</a>. It's a process memory analysis utility and shows a breakdown of different types of virtual and physical memory types.</p> <p>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 <em>is</em> graphical). Process Explorer can also tracks the number of GDI and USER objects.</p> <p>On the GDI topic, there is a free tool named <a href="http://www.nirsoft.net/utils/gdi_handles.html" rel="nofollow">GDIView</a> available here that gives a details of GDI objects allocated per process.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload