http://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspxAs you all know, in CLR memory management is done by Garbage collector (GC). When GC can't find memory in preallocated memory chunk (GC heap) for new objects and can't book enough memory from the OS to expand GC heap, it throws OutOfMemoryException (OOM).en-USCommunityServer 2.1 SP1 (Build: 61025.2)http://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspx#63661Wed, 28 Jan 2004 06:02:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:63661Julien EllieSomething to note about OutOfMemoryException when doing painting is that GDI+ tend to use the outofmemory return code as the &quot;default&quot; error when you cause an internal error in GDI+. This happens for example when you try to load certain kind of 24 bpp icons with GDI+, or even on certain acces violation on shared files. Sadly, not everything is always what it seems :(http://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspx#70711Tue, 10 Feb 2004 17:19:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:70711Rick ByersThanks for the excellent information! Can you tell us anything about the work that is done in Everett and Whidbey to alleviate the problem? If free-space before pinned objects is never used for new allocations, how can you do anything to prevent serious fragmentation in the case of applications like the socket server you mentioned (repeatedly allocating pinned buufers)? <br>http://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspx#71672Thu, 12 Feb 2004 06:12:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:71672Yun JinUnfortunately most of the works you asked about are really confidential and I'm not supposed to talk about them. <br>But the basic idea is when GC detects such fragmentation caused by pinning, it tries to control it by more frequent GCs. So we detect as soon as possible when a pin would be freed and the gap between two pinned objects would be smaller (because more objects are moved before a new pinned object is created). At the same time, we have various refinements to avoid falling into a pattern where we GC all the time but the pins don’t get freed so we waste GC cycles. Eventully it is a tradeoff between space and CPU.http://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspx#91064Wed, 17 Mar 2004 12:03:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:91064Extreme RAD from a Trading Deskhttp://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspx#108024Tue, 06 Apr 2004 01:58:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:108024mvstanton's WebLoghttp://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspx#331256Thu, 23 Dec 2004 18:11:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:331256Jackie Goldstein's Webloghttp://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspx#4926143Sat, 15 Sep 2007 12:57:58 GMT91d46819-8472-40ad-a661-2c78acb4018c:4926143free high school diploma online<p>free high school diploma online</p> http://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspx#6524930Mon, 26 Nov 2007 06:05:30 GMT91d46819-8472-40ad-a661-2c78acb4018c:6524930OutOfMemoryException and Pinning<p>PingBack from <a rel="nofollow" target="_new" href="http://feeds.maxblog.eu/item_1082415.html">http://feeds.maxblog.eu/item_1082415.html</a></p> http://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspx#8964978Thu, 25 Sep 2008 15:52:35 GMT91d46819-8472-40ad-a661-2c78acb4018c:8964978ASP.NET Debugging<p>There are only a few things that can make a .NET process crash.&amp;#160; The most common one is an Unhandled</p> http://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspx#9754632Mon, 15 Jun 2009 22:36:10 GMT91d46819-8472-40ad-a661-2c78acb4018c:9754632 Yun Jin s WebLog OutOfMemoryException and Pinning | debt consolidator<p>PingBack from <a rel="nofollow" target="_new" href="http://mydebtconsolidator.info/story.php?id=954">http://mydebtconsolidator.info/story.php?id=954</a></p>