Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Just because your application uses a lot of memory doesn't necessary mean that you have a memory leak. From the information in your question it is difficult to assert what may be wrong. </p> <p>When troubleshooting managed memory leaks with WinDbg I do the following:</p> <ul> <li><p>Get an overview of the heap usage with <code>!eeheap</code> (this reports the heap usage and not the stack as you mention - each stack has a default size of 1 MB, so unless you have changed this there's no way you can use 100 MB on the stack)</p></li> <li><p>Do a <code>!dumpheap -stat</code> to find out what is on the heap. Chances are that if you have a memory leak the guilty type(s) will be among the top consumers. To get an idea of how heap usage develops you can resume your application, break it a little later and then repeat the <code>!dumpheap -stat</code> command.</p></li> <li><p>If you find any types with more instances than you would except, list those using <code>!dumpheap -mt &lt;MT of type&gt;</code>. This will list all the instances of the particular type. Pick random instances and check roots using the <code>!gcroot</code> command. This will tell you what keeps the instances in question alive. If there are no root these instances will be collected at some point.</p></li> </ul> <p>UPDATE to reply to your comments:</p> <p>The managed heap is only a part of a managed application's memory footprint. Remember, that a .NET application is really an application inside another application - the host process, which loads the CLR, which in turn loads your application. So before your application starts to use any memory the CLR has already taken a fair share. On top of that .NET applications store both MSIL code and JIT compiled code as part of the foot print. The CLR takes up space for various bookkeeping stuff as well (e.g. the CLR creates two additional AddDomains for internal use). </p> <p>The numbers you give do not strike me as over the top, but since I don't know your application it is hard to say if the are excessive. </p> <p>100 MB on the managed heap could be okay, depending on what your application is doing. Did you check the heap? And if so what did you find?</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