StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Install ADPlus on your server (it's part of the <a href="http://www.microsoft.com/whdc/devtools/debugging/default.mspx" rel="nofollow">Windows Debugging Tools</a>). When you start observing unusually high memory usage capture a memory dump using:</p> <pre><code>adplus -hang -p <PID> -quiet -o <dump file folder path> </code></pre> <p><code><PID></code> is the process ID of the worker process which you can get from <code>tasklist.exe</code>.</p> <p>If you're not always around when this issue occurs then you could automate capturing a memory dump using <a href="http://www.microsoft.com/downloads/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3" rel="nofollow">DebugDiag</a>:</p> <ol> <li><p>Use DebugDiag in leak tracking mode to trigger a process dump when either your Private or Virtual memory use reaches a certain threshold. That said, I've not always found this reliable.</p></li> <li><p>Use DebugDiag in Crash Mode to capture a dump whenever CLR exceptions are thrown. You can used the Advanced Settings to configure DebugDiag to produce a full memory dump upon encountering a CLR exception of type <code>System.OutOfMemoryException</code>. This is more reliable and will definitely trigger. Only use Advanced Settings -> Exceptions, don't touch the Unconfigured First Chance Exceptions, leave this setting at None.</p></li> </ol> <p>Once you have your memory dump fire up WinDBG, load the dump file and load up SOS and start poking about.</p> <p>Tess Ferrandez's <a href="http://blogs.msdn.com/b/tess/" rel="nofollow">blog</a> is a great .NET debugging resource and she has plenty of articles and labs about how to track down memory leaks:</p> <blockquote> <p><a href="http://blogs.msdn.com/b/tess/archive/tags/memory+issues/" rel="nofollow">If it is broken, fix it you should - memory issue articles</a></p> <p><a href="http://blogs.msdn.com/b/tess/archive/2008/03/17/net-debugging-demos-lab-6-memory-leak.aspx" rel="nofollow">.NET Debugging Demos Lab 6:_Memory Leak</a><br> <a href="http://blogs.msdn.com/b/tess/archive/2008/03/17/net-debugging-demos-lab-6-memory-leak-review.aspx" rel="nofollow">.NET Debugging Demos Lab 6:_Memory Leak - Review</a><br> <a href="http://blogs.msdn.com/b/tess/archive/2008/03/25/net-debugging-demos-lab-7-memory-leak.aspx" rel="nofollow">.NET Debugging Demos Lab 7: Memory Leak</a><br> <a href="http://blogs.msdn.com/b/tess/archive/2008/04/03/net-debugging-demos-lab-7-memory-leak-review.aspx" rel="nofollow">.NET Debugging Demos Lab 7: Memory Leak - Review</a></p> </blockquote> <p>PerfMon counters are useful and can be used to confirm that you have a memory leak, but they don't tell the whole story. WinDBG and SOS are the tools you need to use to find out where your memory is being used.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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