index > Common Language Runtime > How do I use !gcroot of the SOS debugging extensions?

How do I use !gcroot of the SOS debugging extensions?

From within visual studio immediate window with SOS debugging extension loaded I can do

!dumpheap -stat

Then I get something like this:

total 108,014 objects
Statistics:
MT Count TotalSize Class Name
...
0x00be209c 135 714108 System.Object[]
0x79b925c8 218 2659728 System.String
0x00be2c3c 78986 10,705,064 System.Byte[]
Total 208,014 objects, Total size: 36,259,364

How can I call !gcroot on some of the System.Byte[] instances now? I would first have to find the adress of them. But using !dumpheap -type System.Byte[] is surely a bad idea because that will give me an endless list and since the immediate window seems to be slow it takes more than 20 minutes to list them - duirng that time visual studio is not usable. Is there a sceret trick how I could call !gcroot on some of the byte arrays?

http://bitbonk.spaces.live.com

bitbonk

Unfortunately, if you don't know what object is containing the byte[], using !dumpheap -type System.Byte[] is probably still your best bet. It'll take a long time (since you have nearly 80k byte[] arrays!).

If you know what, specifically, is creating the bytes, then you can use !dumpobj on an object containing the byte array, and use that to get the address of the specific byte array. This can be useful at times, if you're trying to track down what all is referencing a specific object - you just need to know one specific object that you can inspect that's using that byte[] array, then you can use it to track down the address of the byte[] array, and !gcroot it.

Michael Stanton posted a good blog article on some of the possibilities with SoS functions . It's a good place to look for inspiration on other ways to approach this.

Reed Copsey, Jr. - http://reedcopsey.com

Reed Copsey, Jr.

!dumpheap as a couple of parameters that allows you to filter out minimal sizes try -min 1024 to get all arrays bigger then 1kb check here for more parameters.

Ray M_

It seems that all byte arrays have exactly the same size. This would also make sense when I think about the code. I just don't have a clue who is holding a reference to those arrays. That's why I really would love to look at some GCRoots? Can I use SOS with something else than the visual studio immediate debugger? Goolge told me there must be some tool where I can do this:

.foreach (obj {!dumpheap -short -mt 0x000123ab}) {!gcroot obj}

This is obviously not the immediate window...

http://bitbonk.spaces.live.com

bitbonk

Or just follow the link i gave you and check out the other parameters to !dumpheap there's one there to limit the number of results as well.......

Ray M_

It seems that all byte arrays have exactly the same size. This would also make sense when I think about the code. I just don't have a clue who is holding a reference to those arrays. That's why I really would love to look at some GCRoots? Can I use SOS with something else than the visual studio immediate debugger? Goolge told me there must be some tool where I can do this:

.foreach (obj {!dumpheap -short -mt 0x000123ab}) {!gcroot obj}

This is obviously not the immediate window...
http://bitbonk.spaces.live.com

This can be done in the immediate window. If the arrays have the same size, you can do:

!dumpheap -type System.Byte[] -l 10

This will list out the first 10 items. If you analyze the gc roots of those, it might help in your debugging.

Reed Copsey, Jr. - http://reedcopsey.com

Reed Copsey, Jr.

It seems that all byte arrays have exactly the same size. This would also make sense when I think about the code. I just don't have a clue who is holding a reference to those arrays. That's why I really would love to look at some GCRoots? Can I use SOS with something else than the visual studio immediate debugger? Goolge told me there must be some tool where I can do this:

.foreach (obj {!dumpheap -short -mt 0x000123ab}) {!gcroot obj}

This is obviously not the immediate window...
http://bitbonk.spaces.live.com

This can be done in the immediate window. If the arrays have the same size, you can do:

!dumpheap -type System.Byte[] -l 10

This will list out the first 10 items. If you analyze the gc roots of those, it might help in your debugging.

Reed Copsey, Jr. - http://reedcopsey.com

I will try it. But google seems to hin that this parameter might be gone: http://stackoverflow.com/questions/498448/limit-dumpheap-windbg-output-to-n-objects
Also the docs do not list such a parameter: http://msdn.microsoft.com/en-us/library/bb190764.aspx

http://bitbonk.spaces.live.com

bitbonk

Unknown option: -l

:(

http://bitbonk.spaces.live.com

bitbonk

can't you play with the min / max parameters to limit the number of results? or just bite the bullet and wait that 20 mins ...

Ray M_

Unfortunately the bytearrays all have the same size.

http://bitbonk.spaces.live.com

bitbonk

There's a limit on the address on the hap as well if you notice the heap usually starts around 0x029a0000 dump the heap between 0x029a0000 and 0x029F0000that should significantly reduce the number or results.

Ray M_

You can use google to search for other answers

Custom Search

More Threads

• Environment.UserName bug

• Marshal.PtrToStructure (System.AccessViolationException was unhandled)

• How to make a COM object strongly named.

• Windows app error when running on network - something I can fix?

• How to break binary compatibility for a COM-visible type?

• Creating a class library from a 3rd party dll

• WebBrowser.ShowPrintPreviewDialog() + Asynchronous pluggable protocols + DisconnectedContext MDA

• How to catch exception across AppDomain ?

• Shared configuration file between 2 apps

• Encrypting Data