.NET Debugging Demos Lab 3: Memory - Review

Link Listing - February 20, 2008

Christopher Steen — Thu, 21 Feb 2008 16:18:52 GMT

Announcements CI Factory Version 1.0 [Via: jflowers ] ASP.NET Digg.com like Login Control [Via: mikedopp...

Link Listing - February 20, 2008

Christopher Steen — Thu, 21 Feb 2008 16:19:28 GMT

Link Listing - February 20, 2008

re: .NET Debugging Demos Lab 3: Memory - Review

charju — Sun, 24 Feb 2008 10:54:42 GMT

Great and cool!!!

Especially the demo code in deconstructor great simlulated memory issues by a long time finalize action.

re: .NET Debugging Demos Lab 3: Memory - Review

baal — Mon, 25 Feb 2008 11:01:48 GMT

after " 2. Run !dumpheap -stat....." how do you feel link object has problem? if to me ,i will find the strings.

re: .NET Debugging Demos Lab 3: Memory - Review

Tess — Mon, 25 Feb 2008 11:34:55 GMT

The reason I would look as Link objects as a problem is because there are 36000 of them which seems like a pretty high number. Whether it's a high number or not of course depends on what you think the app should use. In this case I would have assumed that it would have about 100 or so active link objects at an y given time.

re: .NET Debugging Demos Lab 3: Memory - Review

KB — Wed, 19 Mar 2008 06:16:11 GMT

Hey Tess,

Hmm, followed right along until I got to !eeheap -gc and !dumpheap -stat. Get back "No export dumpheap found" on both. Dump file is like 854 MB. Any ideas?

Thanks,

re: .NET Debugging Demos Lab 3: Memory - Review

Tess — Wed, 19 Mar 2008 09:46:00 GMT

Hi KB,

that means that you didnt load sos, run .loadby sos mscorwks and try the !eeheap and !dumpheap commands again

re: .NET Debugging Demos Lab 3: Memory - Review

baal — Sat, 05 Apr 2008 16:57:18 GMT

Run "tinyget -srv:localhost -uri:/BuggyBits/Links.aspx -loop:4000" --> I run this, but the mem does not go high.

I have run the reg file.

re: .NET Debugging Demos Lab 3: Memory - Review

baal — Mon, 07 Apr 2008 12:41:32 GMT

Dear Tess

tinyGet seem like not work very well.

re: .NET Debugging Demos Lab 3: Memory - Review

vk — Thu, 03 Jul 2008 15:04:20 GMT

curious to know if you have you seen any blocked finalizers in the real world? any examples of those? in my little time debugging asp.net applications, i havent seen one blocked finalizer issue..

re: .NET Debugging Demos Lab 3: Memory - Review

Tess — Mon, 04 Aug 2008 22:30:10 GMT

I have seen plenty of real world cases with blocked finalizers. The most common ones are ones where the finalizer is blocked by an orphaned critical section i.e. a critical section where the thread that owned the critical section got an exception and quit before leaving the critical section. Some other common ones are issues where the finalizer is waiting for an STA thread... if you look in the post index, under memory issues there are a few posts of real-life examples there...

re: .NET Debugging Demos Lab 3: Memory - Review

Petter — Thu, 23 Apr 2009 10:56:32 GMT

Hi Tess,

If someone is new to windbg (like me) it may not be clear how you got get the address of a link object at the end of step 2. I used !dumpheap -type Link , and picked one. Is this how it is intended?

re: .NET Debugging Demos Lab 3: Memory - Review

Tess — Thu, 23 Apr 2009 11:56:18 GMT

Petter, agreed, thanks for pointing it out...

and yes that is a good way to get to it... (alternatively you can do !dumpheap -mt <Links MT from !dumpheap>)

re: .NET Debugging Demos Lab 3: Memory - Review

nipam — Fri, 29 May 2009 01:06:00 GMT

Hi Tess,

We are seeing more than 25% of time is going in GC and sometime it reacht to 35%. I was going through your labs to find out what could be possible root cause of same. Below is what "!finalizequeue" returning me. Can you please tell me too many objects in Generation 2 is possible root cause of same? How can I find out those objects and whats holding its references?

0:000> !finalizequeue

SyncBlocks to be cleaned up: 0

MTA Interfaces to be released: 0

STA Interfaces to be released: 0

----------------------------------

------------------------------

Heap 0

generation 0 has 632 finalizable objects (2c87c168->2c87cb48)

generation 1 has 5 finalizable objects (2c87c154->2c87c168)

generation 2 has 8275 finalizable objects (2c874008->2c87c154)

Ready for finalization 0 objects (2c87cb48->2c87cb48)

------------------------------

Heap 1

generation 0 has 486 finalizable objects (2c89709c->2c897834)

generation 1 has 58 finalizable objects (2c896fb4->2c89709c)

generation 2 has 10219 finalizable objects (2c88d008->2c896fb4)

Ready for finalization 0 objects (2c897834->2c897834)

------------------------------

Heap 2

generation 0 has 723 finalizable objects (2c6e2d00->2c6e384c)

generation 1 has 50 finalizable objects (2c6e2c38->2c6e2d00)

generation 2 has 9996 finalizable objects (2c6d9008->2c6e2c38)

Ready for finalization 0 objects (2c6e384c->2c6e384c)

------------------------------

Heap 3

generation 0 has 812 finalizable objects (2c8419d4->2c842684)

generation 1 has 21 finalizable objects (2c841980->2c8419d4)

generation 2 has 10750 finalizable objects (2c837188->2c841980)

Ready for finalization 0 objects (2c842684->2c842684)

------------------------------

Heap 4

generation 0 has 860 finalizable objects (2c8d6f88->2c8d7cf8)

generation 1 has 10 finalizable objects (2c8d6f60->2c8d6f88)

generation 2 has 10198 finalizable objects (2c8cd008->2c8d6f60)

Ready for finalization 0 objects (2c8d7cf8->2c8d7cf8)

------------------------------

Heap 5

generation 0 has 532 finalizable objects (2c830030->2c830880)

generation 1 has 24 finalizable objects (2c82ffd0->2c830030)

generation 2 has 9200 finalizable objects (2c827010->2c82ffd0)

Ready for finalization 0 objects (2c830880->2c830880)

------------------------------

Heap 6

generation 0 has 562 finalizable objects (2c81dd84->2c81e64c)

generation 1 has 34 finalizable objects (2c81dcfc->2c81dd84)

generation 2 has 9021 finalizable objects (2c815008->2c81dcfc)

Ready for finalization 0 objects (2c81e64c->2c81e64c)

------------------------------

Heap 7

generation 0 has 735 finalizable objects (2c8552c8->2c855e44)

generation 1 has 45 finalizable objects (2c855214->2c8552c8)

generation 2 has 10371 finalizable objects (2c84b008->2c855214)

Ready for finalization 0 objects (2c855e44->2c855e44)

Regards,

Nipam Patel

re: .NET Debugging Demos Lab 3: Memory - Review

Tess — Fri, 29 May 2009 10:03:29 GMT

Hi Nipam,

In general, the budget for gen 0 and gen 1 is relatively small, which means that if your process uses a lot of .net memory then most of it will be in gen 2. That is not really indicative of anything other than that you are using a bit of memory.

As far as high cpu in gc, 25-35% is not extreme by any means for a process that allocates a lot of memory, but things that will drive the cpu in gc up are 1. classes with unneccessary destructors or where you dont call dispose properly and 2. high allocation rates on the large object heap

There might be other reasons but the two above are the most common ones.

re: .NET Debugging Demos Lab 3: Memory - Review

Nipam — Sun, 31 May 2009 11:14:55 GMT

Hi Tess,

Thanks for quick reply on my previous comment !! I was doing further analysis on what things can go wrong on production. One thin I found is on production "Pipleline Instance Count" (HttpApplication) is constantly rising and it never comes down. We handle almost 60-200 request/sec on production and we see "Pipeline Instance Count" to go till 20,000+ and keep rising. When we reset IIS we see things moving smooth as soon as we see "Pipleline Instance Count" rising lot of time getting spent on GC. We have almost 1:2 ratio for Gen1:Gen0 collection counter. Also we see Gen2 heap size very high almost 700MB when problem starts mounting. If you can point in direction to this issue will be really helpful to us.

Regards,

Nipam Patel

re: .NET Debugging Demos Lab 3: Memory - Review

Sarkar2009 — Sun, 01 Nov 2009 20:56:45 GMT

Hi Tess,

I am experiencing a memory leak on the application I am working on. The committed Bytes reaches 2GB after couple of hours of running the application. Application consistes of both managed and unmamaged code. Can I equate the total committed bytes equal to sum of Virtual bytes of all the processes running on my desktop. Is this a valid comparison to determine which processes are causing the leak?

re: .NET Debugging Demos Lab 3: Memory - Review

Tess — Mon, 02 Nov 2009 10:31:02 GMT

Hi Sarkar,

Not sure which values you are looking at but virtual bytes and committed bytes are completely different. Virtual bytes for a given process is the memory the process reserves, committed bytes is how much of that memory it has commited (simplified, how much it actually used).