<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx</link><description>If you think you've got memory leaks, or if you're just wondering what kind of stuff is on your heap you can follow the very same steps that I do and get fabulous results your friends will envy. OK, well maybe not, but they're handy anyway. These steps</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#279643</link><pubDate>Fri, 10 Dec 2004 19:39:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:279643</guid><dc:creator>J. Marsch</dc:creator><description>Great post, Rico.  I would  love to know more about doing this type of low-level debugging.  My current experience is limited to source code level debuggers.&lt;br&gt;&lt;br&gt;Also, I'm a little bit curious about that last dump in your post -- the output of the gcroot command.  &lt;br&gt;&lt;br&gt;Does this imply that there will be events/delegates in .Net 2.0 that use weak refs? </description></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#279664</link><pubDate>Fri, 10 Dec 2004 20:06:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:279664</guid><dc:creator>Rico Mariani</dc:creator><description>You know I'm often surprised by what I see when I dump the heap.  This guy System.ComponentModel.WeakEventHandlerList seems like he could be quite interesting and I don't know thing one about him.  It might be generally useful but it might also be a private type with an unfortunate name.  Even internal types appear in the low level dumps like this.&lt;br&gt;&lt;br&gt;I'll see if I can't find out something for my own curiosity if nothing else.&lt;br&gt;&lt;br&gt;</description></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#279676</link><pubDate>Fri, 10 Dec 2004 20:26:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:279676</guid><dc:creator>Raymond Lewallen</dc:creator><description>Excellent post Rico.  What I would like to see someone work on is dumping this information into a file directly from CLRProfiler.  That way you can view the dump and the heap and object allocations knowing they all are generated under the same circumstances.</description></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#279679</link><pubDate>Fri, 10 Dec 2004 20:31:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:279679</guid><dc:creator>Pavel Lebedinsky</dc:creator><description>For 1.1 it's probably better to use sos.dll that comes with the latest debuggers. It's loaded automatically when you attach to a process that has CLR dlls loaded, and it has some fixes and new commands/shortcuts that the original Everett version of sos doesn't.</description></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#279686</link><pubDate>Fri, 10 Dec 2004 20:45:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:279686</guid><dc:creator>Rico Mariani</dc:creator><description>&amp;gt;That way you can view the dump and the heap and object allocations knowing they all are generated under the same circumstances.&lt;br&gt;&lt;br&gt;It is often very useful to start the process under CLRProfiler and then also attach with the debugger so you can do both on the same process.  This works just fine.  In fact it's extra handy because CLR Profiler's &amp;quot;Dump Heap Now&amp;quot; forces a garbage collection so you can use it to see what dead things are going away in the debugger dump and visually in CLRProfiler.  &lt;br&gt;&lt;br&gt;&amp;gt;&amp;gt;For 1.1 it's probably better to use sos.dll that comes with the latest debuggers. It's loaded automatically when you attach to a process that has CLR dlls loaded, and it has some fixes and new commands/shortcuts that the original Everett version of sos doesn't.&lt;br&gt;&lt;br&gt;Nothing is ever easy :)&lt;br&gt;&lt;br&gt;It turns out there is this *other* thing that is also called SOS which isn't quite the same thing as the SOS that we build along with the runtime even though it has many of the same commands and common heritage.  That one seems to be auto-loaded (you can find it in a subdirectory under wherever you install windbg) and I think it works on v1.0 and v1.1 of the runtime.  I think it has a few features not present in the original SOS we deployed so it can be useful.&lt;br&gt;&lt;br&gt;It may be that there will be an enhanced SOS for version 2.0 of the runtime some time after it ships.  So basically you can try the commands without loading an SOS explicitly and just get whatever is there or you can go with the &amp;quot;golden&amp;quot; version and take what was originally shipped.&lt;br&gt;&lt;br&gt;For myself, I always use .loadby sos mscorwks but of course I use the runtime build of the moment so anything else would be lunacy.  For you, gentle reader, you may find that you like some of the enchanced features in the other SOS and it works fine on your runtime.  &lt;br&gt;&lt;br&gt;Either way the leak tracking instructions are the same.</description></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#279977</link><pubDate>Sat, 11 Dec 2004 18:46:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:279977</guid><dc:creator>Ivan Peev</dc:creator><description>Rico,&lt;br&gt;&lt;br&gt;Why the VS team doesn't include some functionality, which can automate or help tracing those kinds of managed memory leaks? Those steps can be automated, can't they ?</description></item><item><title>Tracking down managed memory leaks (how to find a GC leak) (from: Rico Mariani)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#280124</link><pubDate>Sun, 12 Dec 2004 07:50:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:280124</guid><dc:creator>TOURNEY LOGIC LINK BLOG</dc:creator><description /></item><item><title>Think the .Net Garbage Collector Isn't Doing It's Job?</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#280149</link><pubDate>Sun, 12 Dec 2004 12:12:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:280149</guid><dc:creator>protected virtual void jayBlog {</dc:creator><description /></item><item><title>How to track down managed memory leak.</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#280839</link><pubDate>Mon, 13 Dec 2004 02:11:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:280839</guid><dc:creator>SmartWombat Blog</dc:creator><description /></item><item><title>Blog link of the week 50</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#280841</link><pubDate>Mon, 13 Dec 2004 02:20:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:280841</guid><dc:creator>Daniel Moth</dc:creator><description>Blog link of the week 50</description></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#282369</link><pubDate>Mon, 13 Dec 2004 22:18:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:282369</guid><dc:creator>Rico Mariani</dc:creator><description>Ivan Peev asks: &amp;quot;Why the VS team doesn't include some functionality, which can automate or help tracing those kinds of managed memory leaks? Those steps can be automated, can't they?&amp;quot;&lt;br&gt;&lt;br&gt;There was very little in terms of memory analysis features in Visual Studio.NET -- I think that reflects two things:  first that there were lots of problems to solve and we couldn't solve them all in one release and second is that some problems we didn't really know how to solve anyway.  I think some of both is going on in this case.&lt;br&gt;&lt;br&gt;Which brings me to the second point:  Can this all be automated?  Well, sort of, the tricky bits are in Step 5 -- how do you automatically know which types are the ones that *should* have gone away and which types were supposed to be living (because they are in a cache or something) -- and in Step 7 -- how do you automatically know which instances of the type are the problematic ones?&lt;br&gt;&lt;br&gt;It's rather tricky.</description></item><item><title>Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#301187</link><pubDate>Tue, 14 Dec 2004 22:53:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:301187</guid><dc:creator>Eric Gunnerson's C# Compendium</dc:creator><description /></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#301241</link><pubDate>Tue, 14 Dec 2004 21:37:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:301241</guid><dc:creator>rx</dc:creator><description>this is a good post.. thanks</description></item><item><title>Tracking down managed memory leaks (how to find a GC leak) in 7 steps</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#301248</link><pubDate>Wed, 15 Dec 2004 00:50:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:301248</guid><dc:creator>.Net Adventures </dc:creator><description /></item><item><title>How to track down managed memory leaks - by Rico Mariani.</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#309918</link><pubDate>Wed, 15 Dec 2004 12:42:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:309918</guid><dc:creator>notgartner.com: Mitch Denny's Blog</dc:creator><description /></item><item><title>Tracking down managed memory leaks (how to find a GC leak) </title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#315977</link><pubDate>Wed, 15 Dec 2004 21:39:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:315977</guid><dc:creator>Anna Shchurova's Blog</dc:creator><description /></item><item><title>Managed Memory Leaks</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#316828</link><pubDate>Thu, 16 Dec 2004 13:50:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:316828</guid><dc:creator>ThoughtChain</dc:creator><description /></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#317138</link><pubDate>Thu, 16 Dec 2004 14:19:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:317138</guid><dc:creator>Tim Bond</dc:creator><description>Great blog well worth bookmarking.</description></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#318263</link><pubDate>Thu, 16 Dec 2004 18:02:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:318263</guid><dc:creator>Mark Levison</dc:creator><description>Great post - but why not use a tool do all this hardwork? During our release cycle this fall I found MemProfiler (www.scitech.se/memprofiler/ ) and blogged a bit about my experience (&lt;a target="_new" href="http://dotnetjunkies.com/WebLog/mlevison/archive/2004/09/30/27265.aspx"&gt;http://dotnetjunkies.com/WebLog/mlevison/archive/2004/09/30/27265.aspx&lt;/a&gt;).&lt;br&gt;&lt;br&gt;For $100, I'm too lazy too work as hard as you.</description></item><item><title>.net Garbage Collector Tips and Tricks</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#323174</link><pubDate>Fri, 17 Dec 2004 06:40:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323174</guid><dc:creator>Tony's Blog</dc:creator><description /></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#323290</link><pubDate>Fri, 17 Dec 2004 10:42:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323290</guid><dc:creator>Ollie Riches</dc:creator><description>Great article will make a great set of interview questions :)</description></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#323292</link><pubDate>Fri, 17 Dec 2004 10:48:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323292</guid><dc:creator>Ollie Riches</dc:creator><description>Your blog rocks....</description></item><item><title>Fixing Managed Memory Leaks</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#323819</link><pubDate>Sat, 18 Dec 2004 02:39:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323819</guid><dc:creator>Deep Thoughts...</dc:creator><description /></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#323856</link><pubDate>Sat, 18 Dec 2004 00:42:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323856</guid><dc:creator>Corbin Dunn</dc:creator><description>I've found the CLRProfiler provides the same information, but in a much easier to use interface.&lt;br&gt;&lt;br&gt;Just my 2 cents!</description></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#323861</link><pubDate>Sat, 18 Dec 2004 00:48:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323861</guid><dc:creator>Rico Mariani</dc:creator><description>You *can* get similar/related information from CLRProfiler and even better information from some 3rd party tools.&lt;br&gt;&lt;br&gt;Advantages to the approach given above:&lt;br&gt;&lt;br&gt;1) You can do this after the fact if you witness a problem, you don't have to start under the profiler as you can attach the debugger&lt;br&gt;&lt;br&gt;2) You can get per-object information about objects and their reachability (!gcroot) which is much trickier to get from say the heap dump&lt;br&gt;&lt;br&gt;3) You can get valuable summary information about the overall memory usage of the CLR (!EEHeap)&lt;br&gt;&lt;br&gt;Plus it's all free :)</description></item><item><title>.NET User interface for Tracking down managed memory leaks</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#326817</link><pubDate>Mon, 20 Dec 2004 02:05:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:326817</guid><dc:creator>Wah On Terra .NET: Martin Granell's Blog</dc:creator><description /></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#326820</link><pubDate>Sun, 19 Dec 2004 23:13:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:326820</guid><dc:creator>Martin Granell</dc:creator><description>Hi Rico,&lt;br&gt;For all those who don't like to use command line tools... &lt;br&gt;I've written a small .NET application that drives the debugger, using the techniques in this article, and displays it in a user interface. The article and source (with screenshot) is on my blog. If you can think of any enhancements that would be useful, please drop me a comment.</description></item><item><title>.::Szőkelizer 113::.</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#327366</link><pubDate>Mon, 20 Dec 2004 17:54:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:327366</guid><dc:creator>RIO - Randektív Informatikai Oldal</dc:creator><description>&amp;lt;p&amp;gt;&amp;amp;lt;ul&amp;amp;gt;&amp;amp;lt;li&amp;amp;gt;&amp;amp;lt;a href=&amp;amp;quot;http://www.hriders.com/web_page.cfm?web_pageID=38&amp;amp;quot; target=&amp;amp;quot;_blank&amp;amp;quot;&amp;amp;gt;1 Tb mail account?&amp;amp;lt;/a&amp;amp;gt;&amp;amp;lt;/li&amp;amp;gt;&amp;amp;lt;li&amp;amp;gt;&amp;amp;lt;a href=&amp;amp;quot;http://mek.oszk.hu/01900/01984/html/&amp;amp;quot; target=&amp;amp;quot;_blank&amp;amp;q</description></item><item><title>Tracking down managed memory leaks </title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#331199</link><pubDate>Thu, 23 Dec 2004 15:29:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:331199</guid><dc:creator>Jackie Goldstein's Weblog</dc:creator><description /></item><item><title>Tracking down managed memory leaks </title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#331203</link><pubDate>Thu, 23 Dec 2004 16:01:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:331203</guid><dc:creator>Jackie Goldstein's Weblog</dc:creator><description /></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#331534</link><pubDate>Fri, 24 Dec 2004 01:02:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:331534</guid><dc:creator>Rico Mariani</dc:creator><description>The tool looks really neat.  I'll give it a whirl when I'm back from vacation.&lt;br&gt;&lt;br&gt;Happy Holidays everyone!</description></item><item><title>.net Garbage Collector Tips and Tricks</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#333069</link><pubDate>Tue, 28 Dec 2004 05:18:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:333069</guid><dc:creator>Tony's Blog</dc:creator><description /></item><item><title>Tracking down managed memory leaks (ASP.NET)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#338994</link><pubDate>Tue, 28 Dec 2004 18:55:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:338994</guid><dc:creator>James Alt</dc:creator><description>Will this work on the ASP.NET worker process? (aspnet_wp.exe) I've been having some memory issues where the size of the worker process just keeps growing and growing until I have to manually kill and restart the process before I can continue on with my work.</description></item><item><title>How to use WinDBG to track leaks in the managed heap</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#339132</link><pubDate>Wed, 29 Dec 2004 02:37:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:339132</guid><dc:creator>Teucer's Quiver</dc:creator><description /></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#343587</link><pubDate>Wed, 29 Dec 2004 09:42:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:343587</guid><dc:creator>Martin</dc:creator><description>&lt;a target="_new" href="http://www.scitech.se/memprofiler/"&gt;http://www.scitech.se/memprofiler/&lt;/a&gt;</description></item><item><title>.Net Performance Management</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#343672</link><pubDate>Wed, 29 Dec 2004 18:22:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:343672</guid><dc:creator>ISkydive</dc:creator><description /></item><item><title>OdeToCode Links For Dec 30</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#344284</link><pubDate>Thu, 30 Dec 2004 18:00:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:344284</guid><dc:creator>OdeToCode Link Blog</dc:creator><description /></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#346995</link><pubDate>Wed, 05 Jan 2005 18:27:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:346995</guid><dc:creator>Seth Hodgson</dc:creator><description>Thanks for the excellent article Rico. I have one (somewhat related) question about GC memory management/leaks and the CLR. Beyond the steps you outline to identify memory leaks, is there any way to control the min and max managed heap size used by the CLR? Most JVMs allow a min and max managed heap size to be specified as start-up params, and I haven't seen any mention of something similar for the CLR. I'd ideally like to be able to tell a .NET windows service app I'm developing a maximum allowed heap size, and then let the GC do it's thing within that constraint. Any thoughts?</description></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#347015</link><pubDate>Wed, 05 Jan 2005 18:48:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:347015</guid><dc:creator>Rico Mariani</dc:creator><description>Some quick responses sort of in order:&lt;br&gt;&lt;br&gt;Q: Will this work on the ASP.NET worker process? &lt;br&gt;&lt;br&gt;A: I don't see why it wouldn't.  It's not magic or anything, and you can attach to it with the debugger same as any other.&lt;br&gt;&lt;br&gt;Re: &lt;a target="_new" href="http://www.scitech.se/memprofiler/"&gt;http://www.scitech.se/memprofiler/&lt;/a&gt; &lt;br&gt;&lt;br&gt;It looks pretty cool, I'll have to play with it some more.  I wonder if it works on the daily build :)&lt;br&gt;&lt;br&gt;Q: Is there any way to control the min and max managed heap size used by the CLR?&lt;br&gt;&lt;br&gt;I don't think there are environment variables for that but you can do this and more with the hosting api (the CLR calls you to get memory and so forth so that it can be hosted in more exotic processes like say SQL Server where you don't want us to go and get memory directly)&lt;br&gt;&lt;br&gt;&lt;a target="_new" href="http://www.gotdotnet.com/team/clr/about_clr_Hosting.aspx"&gt;http://www.gotdotnet.com/team/clr/about_clr_Hosting.aspx&lt;/a&gt;</description></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#348073</link><pubDate>Fri, 07 Jan 2005 00:56:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:348073</guid><dc:creator>Seth Hodgson</dc:creator><description>Hi Rico - thanks for the pointer to the CLR Hosting articles. From what I can tell, the hosting APIs don't provide a way to limit the amount of memory used by the CLR beyond ICorRuntimeHost's Start() and Stop() methods. That seems like a strange way to manage CLR resource use - hard stopping it which unloads it from the current process and then restarting it in a new process. Is stopping the CLR the only way to  release resources back to the system, and is the CLR team considering any enhancement to the CLR startup shim to allow the min/max managed heap size to be defined at application start?&lt;br&gt;&lt;br&gt;Thanks again for all your excellent posts over this past year.</description></item><item><title>re: Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#348085</link><pubDate>Fri, 07 Jan 2005 01:19:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:348085</guid><dc:creator>Seth Hodgson</dc:creator><description>Scratch that - I had overlooked ICorConfiguration 's SetGCHostControl method:)</description></item><item><title>Tracking down managed memory leaks</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#348385</link><pubDate>Fri, 07 Jan 2005 16:33:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:348385</guid><dc:creator>Musings about Dot Net</dc:creator><description /></item><item><title>Tracking down managed memory leaks</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#348405</link><pubDate>Fri, 07 Jan 2005 16:59:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:348405</guid><dc:creator>Musings about Dot Net</dc:creator><description /></item><item><title>Tracking down managed memory leaks (how to find a GC leak) in 7 steps</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#349357</link><pubDate>Sun, 09 Jan 2005 10:49:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:349357</guid><dc:creator>.Net Adventures </dc:creator><description /></item><item><title>Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#379852</link><pubDate>Thu, 24 Feb 2005 23:26:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:379852</guid><dc:creator>Petes Web Log</dc:creator><description>	Tracking down managed memory leaks (how to find a GC leak)&lt;br&gt;&lt;br&gt;A number of resource for locating GC leaks:&lt;br&gt;You might find this blog entry worth reading:&lt;br&gt; http://weblogs.asp.net/ricom/archive/2004/12/10/279612.aspx&lt;br&gt;&lt;br&gt;SciTek's...</description></item><item><title>How to track down managed memory leak.</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#402761</link><pubDate>Mon, 28 Mar 2005 00:38:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:402761</guid><dc:creator>Smartwombat Blog</dc:creator><description>&amp;#160; How to track managed memory leak, also how to use windbg and sos extension for managed debugging in...</description></item><item><title>It was the best of code. It was the worst of code. &amp;raquo; Garbage collection</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#536761</link><pubDate>Wed, 22 Feb 2006 13:19:35 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:536761</guid><dc:creator>It was the best of code. It was the worst of code. » Garbage collection</dc:creator><description>PingBack from &lt;a rel="nofollow" target="_new" href="http://blog.actapps.com.au/2006-02-22/garbage-collection/"&gt;http://blog.actapps.com.au/2006-02-22/garbage-collection/&lt;/a&gt;</description></item><item><title>First rate posting on mem analysis</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#567796</link><pubDate>Tue, 04 Apr 2006 04:50:37 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:567796</guid><dc:creator>Rico Mariani's Performance Tidbits</dc:creator><description>I was just going through some memory leak information and I stumbled across a newish posting from Tess:...</description></item><item><title>The undetectebility of C++/CLI gcroot&amp;amp;lt;&amp;amp;gt; template references.</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#575985</link><pubDate>Thu, 13 Apr 2006 22:48:03 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:575985</guid><dc:creator>Cum Grano Salis</dc:creator><description>In recent builds, we have been having an awful memory leak in our system. Silvio was debugging it and...</description></item><item><title>The undetectebility of C++/CLI gcroot&amp;amp;lt;&amp;amp;gt; template references.</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#575986</link><pubDate>Thu, 13 Apr 2006 22:48:31 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:575986</guid><dc:creator>Cum Grano Salis</dc:creator><description>In recent builds, we have been having an awful memory leak in our system. Silvio was debugging it and...</description></item><item><title>Automated leak detection in managed code</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#1426520</link><pubDate>Sun, 07 Jan 2007 07:44:47 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:1426520</guid><dc:creator>Dan Crevier's Blog</dc:creator><description>&lt;p&gt;Managed code makes memory management much easier, but it's still possible to have unintended memory leaks.&lt;/p&gt;
</description></item><item><title>Memory leaks 101: Objects anchored by event generators</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#1440079</link><pubDate>Tue, 09 Jan 2007 22:20:43 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:1440079</guid><dc:creator>Rico Mariani's Performance Tidbits</dc:creator><description>&lt;p&gt;This problem actually comes up pretty often so I thought I'd write a little article about it, and a couple&lt;/p&gt;
</description></item><item><title>Track down managed memory leaks</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#1647259</link><pubDate>Sun, 11 Feb 2007 04:08:56 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:1647259</guid><dc:creator>DotNetKicks.com</dc:creator><description>&lt;p&gt;You've been kicked (a good thing) - Trackback from DotNetKicks.com&lt;/p&gt;
</description></item><item><title>File Open Performance -- Beware of &amp;quot;Extensions&amp;quot;</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#5874406</link><pubDate>Sun, 04 Nov 2007 07:07:49 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:5874406</guid><dc:creator>Rico Mariani's Performance Tidbits</dc:creator><description>&lt;p&gt;Here is a little interchange I had a few days ago, &amp;quot;Nick From Chicago&amp;quot; graciously allowed me to share&lt;/p&gt;
</description></item><item><title>MSDN Blog Postings  &amp;raquo; File Open Performance -- Beware of 'Extensions'</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#5874651</link><pubDate>Sun, 04 Nov 2007 07:20:53 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:5874651</guid><dc:creator>MSDN Blog Postings  » File Open Performance -- Beware of 'Extensions'</dc:creator><description>&lt;p&gt;PingBack from &lt;a rel="nofollow" target="_new" href="http://msdnrss.thecoderblogs.com/2007/11/04/file-open-performance-beware-of-extensions/"&gt;http://msdnrss.thecoderblogs.com/2007/11/04/file-open-performance-beware-of-extensions/&lt;/a&gt;&lt;/p&gt;</description></item><item><title>MSDN Blog Postings  &amp;raquo; File Open Performance -- Beware of 'Extensions'</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#5874652</link><pubDate>Sun, 04 Nov 2007 07:20:54 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:5874652</guid><dc:creator>MSDN Blog Postings  » File Open Performance -- Beware of 'Extensions'</dc:creator><description>&lt;p&gt;PingBack from &lt;a rel="nofollow" target="_new" href="http://msdnrss.thecoderblogs.com/2007/11/04/file-open-performance-beware-of-extensions/"&gt;http://msdnrss.thecoderblogs.com/2007/11/04/file-open-performance-beware-of-extensions/&lt;/a&gt;&lt;/p&gt;</description></item><item><title>File Open Performance -- Beware of 'Extensions'</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#5875131</link><pubDate>Sun, 04 Nov 2007 07:45:33 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:5875131</guid><dc:creator>Noticias externas</dc:creator><description>&lt;p&gt;Here is a little interchange I had a few days ago; &amp;amp;quot;Nick From Chicago&amp;amp;quot; graciously allowed me&lt;/p&gt;
</description></item><item><title>Finding Memory Leaks in WPF-based applications</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#7448652</link><pubDate>Tue, 05 Feb 2008 01:23:51 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:7448652</guid><dc:creator>WPF Performance</dc:creator><description>&lt;p&gt;&amp;amp;#160; There are numbers of blogs that folks wrote about memory leaks in Microsoft .Net Framework managed&lt;/p&gt;
</description></item><item><title>Finding Memory Leaks in WPF-based applications</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#7449346</link><pubDate>Tue, 05 Feb 2008 01:57:26 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:7449346</guid><dc:creator>Noticias externas</dc:creator><description>&lt;p&gt;There are numbers of blogs that folks wrote about memory leaks in Microsoft .Net Framework managed code&lt;/p&gt;
</description></item><item><title>MSDN Blog Postings  &amp;raquo; Finding Memory Leaks in WPF-based applications</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#7452838</link><pubDate>Tue, 05 Feb 2008 04:31:17 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:7452838</guid><dc:creator>MSDN Blog Postings  » Finding Memory Leaks in WPF-based applications</dc:creator><description>&lt;p&gt;PingBack from &lt;a rel="nofollow" target="_new" href="http://msdnrss.thecoderblogs.com/2008/02/04/finding-memory-leaks-in-wpf-based-applications/"&gt;http://msdnrss.thecoderblogs.com/2008/02/04/finding-memory-leaks-in-wpf-based-applications/&lt;/a&gt;&lt;/p&gt;
</description></item><item><title>   Debugging .NET exceptions *without* VS installed using WinDbg &amp;raquo; Thursday Night</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#8548537</link><pubDate>Sat, 24 May 2008 21:46:02 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:8548537</guid><dc:creator>   Debugging .NET exceptions *without* VS installed using WinDbg &amp;raquo; Thursday Night</dc:creator><description>&lt;p&gt;PingBack from &lt;a rel="nofollow" target="_new" href="http://blog.paulbetts.org/index.php/2008/05/24/debugging-net-exceptions-without-vs-installed-using-windbg/"&gt;http://blog.paulbetts.org/index.php/2008/05/24/debugging-net-exceptions-without-vs-installed-using-windbg/&lt;/a&gt;&lt;/p&gt;
</description></item><item><title>Asp.net memory leak : case study - Asp.net fuite mémoire</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#8573156</link><pubDate>Wed, 04 Jun 2008 14:35:36 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:8573156</guid><dc:creator>Blog de Jérémie Clabaut (ak MinSou)</dc:creator><description>&lt;p&gt;Last week one of my customers called me to help him resolve a big problem on an asp.net application: a memory leak. During the application stress test, the w3wp process memory increased abnormally as a result of an application crash (application pool&lt;/p&gt;
</description></item><item><title>Tracking down managed memory leaks (how to find a GC leak) in 7 steps | devintelligence.com</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#8758488</link><pubDate>Sun, 20 Jul 2008 16:46:15 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:8758488</guid><dc:creator>Tracking down managed memory leaks (how to find a GC leak) in 7 steps | devintelligence.com</dc:creator><description>&lt;p&gt;PingBack from &lt;a rel="nofollow" target="_new" href="http://www19.a2hosting.com/~tarasn/devintelligence.com/?p=597"&gt;http://www19.a2hosting.com/~tarasn/devintelligence.com/?p=597&lt;/a&gt;&lt;/p&gt;
</description></item><item><title>Tracking down managed memory leaks (how to find a GC leak)</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#8995776</link><pubDate>Sat, 11 Oct 2008 14:48:43 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:8995776</guid><dc:creator>IWebThereforeIAm</dc:creator><description>&lt;p&gt;Tracking down managed memory leaks (how to find a GC leak)...&lt;/p&gt;
</description></item><item><title>Tracking Down Managed Memory Leaks &amp;laquo; Roman&amp;#8217;s Blog</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#9003858</link><pubDate>Sat, 18 Oct 2008 01:51:54 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:9003858</guid><dc:creator>Tracking Down Managed Memory Leaks &amp;laquo; Roman&amp;#8217;s Blog</dc:creator><description>&lt;p&gt;PingBack from &lt;a rel="nofollow" target="_new" href="http://rhnatiuk.wordpress.com/2008/10/18/tracking-down-managed-memory-leaks/"&gt;http://rhnatiuk.wordpress.com/2008/10/18/tracking-down-managed-memory-leaks/&lt;/a&gt;&lt;/p&gt;
</description></item><item><title>Memory Leak | keyongtech</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#9338362</link><pubDate>Sun, 18 Jan 2009 20:17:49 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:9338362</guid><dc:creator>Memory Leak | keyongtech</dc:creator><description>&lt;p&gt;PingBack from &lt;a rel="nofollow" target="_new" href="http://www.keyongtech.com/683612-memory-leak"&gt;http://www.keyongtech.com/683612-memory-leak&lt;/a&gt;&lt;/p&gt;
</description></item><item><title>Speicherverbrauch von NET-Anwendungen | hilpers</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#9347974</link><pubDate>Tue, 20 Jan 2009 18:31:50 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:9347974</guid><dc:creator>Speicherverbrauch von NET-Anwendungen | hilpers</dc:creator><description>&lt;p&gt;PingBack from &lt;a rel="nofollow" target="_new" href="http://www.hilpers.com/1040753-speicherverbrauch-von-net-anwendungen"&gt;http://www.hilpers.com/1040753-speicherverbrauch-von-net-anwendungen&lt;/a&gt;&lt;/p&gt;
</description></item><item><title>rusanu.com  &amp;raquo; Blog Archive   &amp;raquo; CLR Memory Leak</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#9439932</link><pubDate>Sun, 22 Feb 2009 12:49:58 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:9439932</guid><dc:creator>rusanu.com  &amp;raquo; Blog Archive   &amp;raquo; CLR Memory Leak</dc:creator><description>&lt;p&gt;PingBack from &lt;a rel="nofollow" target="_new" href="http://rusanu.com/2009/01/19/clr-memory-leak/"&gt;http://rusanu.com/2009/01/19/clr-memory-leak/&lt;/a&gt;&lt;/p&gt;
</description></item><item><title>Where's your leak at? [Using WinDbg, SOS, and GCRoot to diagnose a .NET memory leak]</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#9471349</link><pubDate>Thu, 12 Mar 2009 08:48:18 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:9471349</guid><dc:creator>Delay's Blog</dc:creator><description>&lt;p&gt;In my last post, I explained how it was possible for &amp;quot;hidden&amp;quot; event handlers to introduce memory leaks&lt;/p&gt;
</description></item><item><title>Finding Managed Memory Leaks in WPF and Silverlight applications</title><link>http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx#9496723</link><pubDate>Sun, 22 Mar 2009 02:12:08 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:9496723</guid><dc:creator>WPF, Silverlight and .NET Musings</dc:creator><description>&lt;p&gt;It's been a while since the last post was online. We have been very busy in working on one of the very&lt;/p&gt;
</description></item></channel></rss>