!dumpheap –stat explained… (debugging .net leaks)

re: !dumpheap –stat explained… (debugging .net leaks)

Leonardo Machado — Mon, 30 Jan 2006 19:44:30 GMT

Cool !!

I can now understand how the things goes inside my programs with this tips ! I don't like GC "programming way" but if I need to use now this type of kind, at least I can understand it now !

Thanks !!!

re: !dumpheap –stat explained… (debugging .net leaks)

Chakravarthy — Sun, 05 Feb 2006 21:32:38 GMT

This must be a naive question - how and where does one run GC.Collect (as mentioned in the article) ? In the code ? Then how do i run sos after running GC.collect ?

re: !dumpheap –stat explained… (debugging .net leaks)

Tess — Mon, 06 Feb 2006 01:31:13 GMT

Hi Charkravarthy,

If it is an asp.net application you can have a dummy page that just calls GC.Collect, if it's a winforms app, perhaps a button or similar. Then break in with windbg and load sos.dll in there.

.NET Memory Leak Case Study: The Event Handlers That Made The Memory Baloon

If broken it is, fix it you should — Tue, 07 Feb 2006 11:22:58 GMT

It always feels like issues come in clusters. One week we get tones of cache related cases, next week...

re: !dumpheap –stat explained… (debugging .net leaks)

Howard — Thu, 09 Feb 2006 19:10:53 GMT

This is all good stuff, thanks, but....

is it even possible to get the values of the items in collection? Take below as an example;

0:024> !do 0x06358508
Name: System.Collections.ArrayList
MethodTable 0x79ba2ee4
EEClass 0x79ba3020
Size 24(0x18) bytes
GC Generation: 1
mdToken: 0x02000100 (c:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll)
FieldDesc*: 0x79ba3084
MT Field Offset Type Attr Value Name
0x79ba2ee4 0x4000362 0x4 CLASS instance 0x06358520 _items
0x79ba2ee4 0x4000363 0xc System.Int32 instance 7 _size
0x79ba2ee4 0x4000364 0x10 System.Int32 instance 8 _version
0x79ba2ee4 0x4000365 0x8 CLASS instance 0x00000000 _syncRoot

Now try and dump the items..

0:024> !do 0x06358520
Name: System.Object[]
MethodTable 0x01b4209c
EEClass 0x01b42018
Size 80(0x50) bytes
GC Generation: 1
Array: Rank 1, Type CLASS
Element Type: System.Object
Content: 16 items

ok 16 items, but how can you get their values?

re: !dumpheap –stat explained… (debugging .net leaks)

Tess — Thu, 09 Feb 2006 21:56:59 GMT

Hi Howard,

you get them with !do -v, or by running dd (dump dword) on the address of the object array and then !do on the individual dwords...

re: !dumpheap –stat explained… (debugging .net leaks)

Stuart McConnell — Tue, 28 Mar 2006 13:08:03 GMT

Off topic ;-), how do you get windbg to format decimals with ','

Thanks...

re: !dumpheap –stat explained… (debugging .net leaks)

Tess — Thu, 30 Mar 2006 08:58:28 GMT

ahhh, by having regional settings for numbers set to Swedish:) We use ,'s instead of .'s here by the north pole:) You'll probably see .'s instead...

.NET Memory Leak Case Study: The Event Handlers That Made The Memory Baloon

If broken it is, fix it you should — Mon, 04 Jun 2007 10:44:35 GMT

It always feels like issues come in clusters. One week we get tones of cache related cases, next week

If broken it is, fix it you should : Blog Post Index

If broken it is, fix it you should : Blog Post Index — Mon, 11 Jun 2007 13:12:49 GMT

PingBack from http://blogs.msdn.com/tess/pages/blog-post-index.aspx

Diagnostyka wycieków pamięci

No comments... — Wed, 24 Sep 2008 22:56:51 GMT

W poniższym artykule wykorzystano materiały znajdujące się w następujących artykułach Tess: http://blogs.msdn.com/tess/archive/2005/11/25/i-have-a-memory-leak-what-do-i-do-defining-the-where.aspx

re: !dumpheap –stat explained… (debugging .net leaks)

Ben — Fri, 05 Dec 2008 15:24:44 GMT

Does windbg cache the results of !dumpheap?

I ran it 3 times and got the same results which is definately wrong because when i detached and re attached the debugger the results were massively different.

re: !dumpheap –stat explained… (debugging .net leaks)

Tess — Fri, 05 Dec 2008 15:49:41 GMT

windbg doesnt cache the results but sos does. however if you are live attaching and hit go in between and then run !dumpheap -stat again you should get new results.