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

  • Question

  • 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
    Tuesday, September 22, 2009 5:40 PM

Answers

  • The best approach to this is to not use the Visual Studio Immeadiate Window but WinDebug. It can display text much (!) faster. It really doesn't matter if the the list is very long.
    http://bitbonk.spaces.live.com
    • Marked as answer by bitbonk Monday, October 5, 2009 5:32 AM
    Monday, October 5, 2009 5:31 AM

All replies

  • 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
    Tuesday, September 22, 2009 5:59 PM
    Moderator
  • !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.
    Tuesday, September 22, 2009 7:30 PM
  • 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
    Tuesday, September 22, 2009 8:02 PM
  • 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.......
    Tuesday, September 22, 2009 8:06 PM
  • 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
    Tuesday, September 22, 2009 8:15 PM
    Moderator
  • 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
    Tuesday, September 22, 2009 8:16 PM
  • Unknown option: -l

    :(
    http://bitbonk.spaces.live.com
    Tuesday, September 22, 2009 8:32 PM
  • 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 ...

    Tuesday, September 22, 2009 8:46 PM
  • Unfortunately the bytearrays all have the same size.
    http://bitbonk.spaces.live.com
    Tuesday, September 22, 2009 8:47 PM
  • 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 0x029F0000 that should significantly reduce the number or results.
    • Marked as answer by eryang Monday, October 5, 2009 2:44 AM
    • Unmarked as answer by bitbonk Monday, October 5, 2009 5:30 AM
    Tuesday, September 22, 2009 8:50 PM
  • The best approach to this is to not use the Visual Studio Immeadiate Window but WinDebug. It can display text much (!) faster. It really doesn't matter if the the list is very long.
    http://bitbonk.spaces.live.com
    • Marked as answer by bitbonk Monday, October 5, 2009 5:32 AM
    Monday, October 5, 2009 5:31 AM