sos2.dll version 1.2 released

Version 1.2 supports a command to dump GC Handles by type. Actually,  support for this command was suggested by Ilya Ryzhenkov (ReSharper Product Manager at JetBrains) .

Download it from here

To Do List is to dump all the handles for a type along with stats with an option to specify the # of handles. For example, if there are 100 strong gchandles, you may want to print just 10 of them or so

GCHandlesByType(gcht)

————————————————
Get GC Handles Stat by Type
————————————————
!GCHandlesByType provides statistics about GCHandles by type.
Supported Types are
1. Pinned(p)
2. AsyncPinned(ap)
3. Strong(s)
4. WeakLong(wl)
5. WeakShort(ws)
6. RefCount(r)
Example Syntax
!gcht [-perdomain] -t <type>
-perdomain option, will display the stat broken down by AppDomain.
type specified is not case sensitive, for example command syntax to print the
stat for Strong handle type is
0:003> !gcht -t strong
||
0:003> !gcht -t s
||
0:003> !gcht -t Strong
Strong GC Handle Statistics:
Strong Handles: 15
Statistics:
MT    Count    TotalSize Class Name
793040bc        1           16 System.Object[]
79330fb8        1           28 System.SharedStatics
79331e38        2           48 System.Reflection.Assembly
79330ec0        1           56 System.Threading.Thread
79330c30        1           72 System.ExecutionEngineException
79330ba0        1           72 System.StackOverflowException
79330b10        1           72 System.OutOfMemoryException
793310cc        1          100 System.AppDomain
793325b0        4          144 System.Security.PermissionSet
79330cc0        2          144 System.Threading.ThreadAbortException
Total 15 objects
——————————

Download it from here

  • Ilya Ryzhenkov says:

    Thanks a lot! Firing WinDbg to try it out immediately!

    [Reply]

    November 18, 2008 at 2:15 pm
  • Ilya Ryzhenkov says:

    Unfortunately, it just hangs in the middle of that command :( Looks like it hangs when trying to output some type name, as it displays some data and when it is time to show type name – *BUSY* forever…

    [Reply]

    November 18, 2008 at 9:36 pm
  • Ilya Ryzhenkov says:

    Stacktraces when hung:
    0:000> ~* e kb
    ChildEBP RetAddr Args to Child
    0006ddc8 7c90df3c 7c91b22b 000007e0 00000000 ntdll!KiFastSystemCallRet
    0006ddcc 7c91b22b 000007e0 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
    0006de54 7c901046 002f3d40 020c97c6 022f3d40 ntdll!RtlpWaitForCriticalSection+0×132
    0006de5c 020c97c6 022f3d40 0006dea8 0006de7c ntdll!RtlEnterCriticalSection+0×46
    0006de84 020cd65c 2d6b3c43 0000000f 007894b8 dbgeng!ClientListCapture::Fill+0×16
    0006ded0 0102af20 007871f4 007894bc 0006deec dbgeng!DebugClient::ExitDispatch+0x5c
    0006dee0 01044856 0078e8f8 0006def8 0101f961 windbg!UpdateEngine+0×30
    0006deec 0101f961 0078e8f8 0006df18 01022f08 windbg!StateBuffer::UiRequestRead+0×16
    0006def8 01022f08 7c90120e 00000000 0006ef64 windbg!WinDisassembly::SetCurInstr+0×41
    0006df18 01052a53 7c90120e 00000000 00000000 windbg!UpdateCodeDisplay+0×58
    0006ff7c 010560e6 00000001 00784748 007859a8 windbg!wmain+0×333
    0006ffc0 7c817067 00300035 00310033 7ffdf000 windbg!_initterm_e+0×163
    0006fff0 00000000 01056217 00000000 78746341 kernel32!BaseProcessStart+0×23
    ChildEBP RetAddr Args to Child
    00fcff14 7c90df3c 7c8025db 000000c4 00000001 ntdll!KiFastSystemCallRet
    00fcff18 7c8025db 000000c4 00000001 00000000 ntdll!NtWaitForSingleObject+0xc
    00fcff7c 020cd59a 000000c4 ffffffff 00000001 kernel32!WaitForSingleObjectEx+0xa8
    00fcff9c 0102acad 007894bc ffffffff 806e6ef2 dbgeng!DebugClient::DispatchCallbacks+0x4a
    00fcffb4 7c80b713 00000000 7c90e900 7c910040 windbg!EngineLoop+0x30d
    00fcffec 00000000 0102a9a0 00000000 00000000 kernel32!BaseThreadStart+0×37
    ChildEBP RetAddr Args to Child
    01fdffc8 7c950010 00000005 00000004 00000001 ntdll!DbgBreakPoint
    01fdfff4 00000000 00000000 00000000 00000000 ntdll!DbgUiRemoteBreakin+0x2d

    [Reply]

    November 18, 2008 at 9:44 pm
  • prashant says:

    My Apology, I may have messed it up somewhere. Could you please let me know the type which you tried to dump or the command syntax you used? also did you run it on a memory dump or just live debugging?

    [Reply]

    November 18, 2008 at 9:47 pm
  • Nesin says:

    Yes, thank you

    Run the following command to get pinned gchandles and it works for me

    !gcht -t p

    I have not gone through each of the options but pinned and strong gchandles worked for me. Lucky Me :-)

    [Reply]

    November 19, 2008 at 7:41 am
  • Ilya Ryzhenkov says:

    For me, !gcht -t p hangs with the same callstacks :(

    [Reply]

    November 19, 2008 at 8:03 am
  • prashant says:

    I have not been able to recreate the same issue what Ilya is having but I did find a bug which is fixed. I will continue to use sos2 over next few days in production debugging and hopefully recreate the same issue.

    Please do report a bug to me if you find any.

    [Reply]

    November 19, 2008 at 11:41 am
  • Narayan says:

    Very useful to analyze dumps for memory leaks. All I can say works for me so far, however a missing column compare to sos!gchandles

    [Reply]

    November 20, 2008 at 12:14 am
  • prashant says:

    Naryan, there has to be some issue thats why this command causes hangs for ilya’s app. Ilya has provided the callstack so i will look into it more once i get to it.

    Debugging rules says it aint fixed until you fix it, so i do have to fix it

    [Reply]

    November 20, 2008 at 4:30 am
  • Elcorin says:

    Hello,
    Not sure that this is true) but thanks

    Thank you
    Elcorin

    [Reply]

    February 5, 2009 at 4:28 am
  • Nadine says:

    Hello,
    debuggingblog.com – da best. Keep it going!

    Thank you
    Nadine

    [Reply]

    April 12, 2009 at 12:59 am
  • Sane says:

    Is it possible to obtain x64 version?

    [Reply]

    September 2, 2010 at 12:15 pm

Your email address will not be published. Required fields are marked *

*