-------------------------------------------------------------------------------
NOTE: THIS FILE CONTAINS SOS DOCUMENTATION. THE FORMAT OF THE FILE IS:

<optional comments>
COMMAND: <cmd name, all lower case>
<descriptive text of the command>
\\ <these are two backslashes, immediately followed by a newline>

<repeat the sequence above>

The first command is "contents" which is the general help screen. The rest 
correspond to SOS command names. This file is embedded as a resource in the SOS 
binary. Be sure to list any new commands here.
-------------------------------------------------------------------------------



COMMAND: contents.
SOS is a debugger extension DLL designed to aid in the debugging of managed
programs. Functions are listed by category, then roughly in order of
importance. Shortcut names for popular functions are listed in parenthesis.
Type "soshelp <functionname>" for detailed info on that function. 

Object Inspection                  Examining code and stacks
-----------------------------      -----------------------------
DumpObj (dumpobj)                  Threads (clrthreads)
DumpALC (dumpalc)                  ThreadState
DumpArray                          IP2MD (ip2md)
DumpDelegate (dumpdelegate)        u (clru)
DumpStackObjects (dso)             DumpStack (dumpstack)
DumpHeap (dumpheap)                EEStack (eestack)
DumpVC                             ClrStack (clrstack)
FinalizeQueue (finalizequeue)      GCInfo
GCRoot (gcroot)                    EHInfo
ObjSize (objsize)                  bpmd (bpmd)
PrintException (pe)
TraverseHeap (traverseheap)
                                   
Examining CLR data structures      Diagnostic Utilities
-----------------------------      -----------------------------
DumpDomain (dumpdomain)            VerifyHeap
EEHeap (eeheap)                    FindAppDomain          
Name2EE (name2ee)                  DumpLog (dumplog)
SyncBlk (syncblk)                  SuppressJitOptimization
DumpMT (dumpmt)                    ThreadPool (threadpool)
DumpClass (dumpclass)              AnalyzeOOM (analyzeoom)
DumpMD (dumpmd)                    VerifyObj (verifyobj)
Token2EE                           GCHandles (gchandles)
DumpModule (dumpmodule)
DumpAssembly (dumpassembly)
DumpRuntimeTypes (dumpruntimetypes)
DumpIL (dumpil)
DumpSig
DumpSigElem

Examining the GC history           Other
-----------------------------      -----------------------------
HistInit (histinit)                SetHostRuntime (sethostruntime)
HistRoot (histroot)                SetSymbolServer (setsymbolserver, loadsymbols)
HistObj  (histobj)                 SetClrPath (setclrpath)
HistObjFind (histobjfind)          SOSFlush (sosflush)
HistClear (histclear)              SOSStatus (sosstatus)
                                   FAQ
                                   Help (soshelp)
\\

COMMAND: faq.
>> I have a chicken and egg problem. I want to use SOS commands, but the CLR
   isn't loaded yet. What can I do?

There currently isn't any way to get lldb to stop on libcoreclr.so module load, but
you can now set a breakpoint on Main with "bpmd".

        (lldb) bpmd Foo.dll Program.Main

>> I got the following error message. Now what?

    (lldb) sos DumpStackObjects
    The coreclr module is not loaded yet in the target process
    (lldb) 

This means that the clr is not loaded yet, or has been unloaded. You need to 
wait until your managed program is running in order to use these commands. If 
you have just started the program a good way to do this is to type 

    breakpoint set coreclr`EEStartup

in the debugger, and let it run. After the function EEStartup is finished, 
there will be a minimal managed environment for executing SOS commands.

\\

COMMAND: dumpobj.
DumpObj [-nofields] <object address>

This command allows you to examine the fields of an object, as well as learn 
important properties of the object such as the EEClass, the MethodTable, and 
the size.

You might find an object pointer by running DumpStackObjects and choosing
from the resultant list. Here is a simple object:

    (lldb) dumpobj a79d40
    Name: Customer
    MethodTable: 009038ec
    EEClass: 03ee1b84
    Size: 20(0x14) bytes
     (/home/user/pub/unittest)
    Fields:
          MT    Field   Offset                 Type  VT     Attr    Value Name
    009038ec  4000008        4             Customer   0 instance 00a79ce4 name
    009038ec  4000009        8                 Bank   0 instance 00a79d2c bank

Note that fields of type Customer and Bank are themselves objects, and you can 
run DumpObj on them too. You could look at the field directly in memory using
the offset given. "dd a79d40+8 l1" would allow you to look at the bank field 
directly. Be careful about using this to set memory breakpoints, since objects
can move around in the garbage collected heap.

What else can you do with an object? You might run GCRoot, to determine what 
roots are keeping it alive. Or you can find all objects of that type with 
"dumpheap -type Customer".

The column VT contains the value 1 if the field is a valuetype structure, and
0 if the field contains a pointer to another object. For valuetypes, you can 
take the MethodTable pointer in the MT column, and the Value and pass them to 
the command DumpVC.

The arguments in detail:
-nofields:     do not print fields of the object, useful for objects like String
\\

COMMAND: dumparray.
DumpArray 
    [-start <startIndex>]
    [-length <length>]
    [-details]
    [-nofields]
    <array object address>

This command allows you to examine elements of an array object.
The arguments in detail:
 -start <startIndex>: optional, only supported for single dimension array. 
                      Specify from which index the command shows the elements.
 -length <length>:    optional, only supported for single dimension array. 
                      Specify how many elements to show.
 -details:            optional. Ask the command to print out details
                      of the element using DumpObj and DumpVC format.
 -nofields:           optional, only takes effect when -details is used. Do
                      not print fields of the elements. Useful for arrays of
                      objects like String

 Example output:

    (lldb) sos DumpArray -start 2 -length 3 -details 00ad28d0 
    Name: Value[]
    MethodTable: 03e41044
    EEClass: 03e40fc0
    Size: 132(0x84) bytes
    Array: Rank 1, Number of elements 10, Type VALUETYPE
    Element Type: Value
    [2] 00ad28f0
        Name: Value
        MethodTable 03e40f4c
        EEClass: 03ef1698
        Size: 20(0x14) bytes
         (/home/user/bugs/225271/arraytest)
        Fields:
              MT    Field   Offset                 Type       Attr    Value Name
        5b9a628c  4000001        0         System.Int32   instance        2 x
        5b9a628c  4000002        4         System.Int32   instance        4 y
        5b9a628c  4000003        8         System.Int32   instance        6 z
    [3] 00ad28fc
        Name: Value
        MethodTable 03e40f4c
        EEClass: 03ef1698
        Size: 20(0x14) bytes
         (/home/user/bugs/225271/arraytest)
        Fields:
              MT    Field   Offset                 Type       Attr    Value Name
        5b9a628c  4000001        0         System.Int32   instance        3 x
        5b9a628c  4000002        4         System.Int32   instance        6 y
        5b9a628c  4000003        8         System.Int32   instance        9 z
    [4] 00ad2908
        Name: Value
        MethodTable 03e40f4c
        EEClass: 03ef1698
        Size: 20(0x14) bytes
         (/home/user/bugs/225271/arraytest.exe)
        Fields:
              MT    Field   Offset                 Type       Attr    Value Name
        5b9a628c  4000001        0         System.Int32   instance        4 x
        5b9a628c  4000002        4         System.Int32   instance        8 y
        5b9a628c  4000003        8         System.Int32   instance       12 z
\\

COMMAND: dumpalc.
DumpALC
    <object address>

This command allows you to dump the AssemblyLoadContext into which the type of the
specified object was loaded.

 Example output:
        (lldb) dumpalc 000001c2800101a0
        Name:        Host.HostAssemblyLoadContext
        MethodTable: 00007ff7c9cb1428
        EEClass:     00007ff7c9ca4b40
        Size:        88(0x58) bytes
        File:        /home/user/test/host.dll
        Fields:
                      MT    Field   Offset                 Type VT     Attr            Value Name
        00007ff7c9920eb8  4000ea3        8        System.Object  0 instance 000001c28000cff0 _unloadLock
        0000000000000000  4000ea4       10                       0 instance 0000000000000000 _resolvingUnmanagedDll
        0000000000000000  4000ea5       18                       0 instance 0000000000000000 _resolving
        00007ff7c9d36850  4000ea6       20 ...Private.CoreLib]]  0 instance 000001c2800101b8 _unloading
        00007ff7c9a74748  4000ea7       28        System.String  0 instance 0000000000000000 _name
        00007ff7c9a427f0  4000ea8       30        System.IntPtr  1 instance 000001C2FA21DD50 _nativeAssemblyLoadContext
        00007ff7c9a1c7e0  4000ea9       38         System.Int64  1 instance                0 _id
        00007ff7c9ac57b8  4000eaa       40         System.Int32  1 instance                0 _state
        00007ff7c9a107b8  4000eab       44       System.Boolean  1 instance                1 _isCollectible
        00007ff7c9cb4070  4000ea1      b08 ...Private.CoreLib]]  0   static 000001c28000d090 s_allContexts
        00007ff7c9a1c7e0  4000ea2      970         System.Int64  1   static                1 s_nextId
        0000000000000000  4000eac      b10 ...yLoadEventHandler  0   static 0000000000000000 AssemblyLoad
        0000000000000000  4000ead      b18 ...solveEventHandler  0   static 0000000000000000 TypeResolve
        0000000000000000  4000eae      b20 ...solveEventHandler  0   static 0000000000000000 ResourceResolve
        0000000000000000  4000eaf      b28 ...solveEventHandler  0   static 0000000000000000 AssemblyResolve
        0000000000000000  4000eb0      b30                       0   static 0000000000000000 s_asyncLocalCurrent
        00007ff7c9cb26d0  4000001       48 ...ependencyResolver  0 instance 000001c28000d1c0 _resolver

\\

COMMAND: dso.
COMMAND: dumpstackobjects.
DumpStackObjects [-verify] [top stack [bottom stack]]

This command will display any managed objects it finds within the bounds of 
the current stack. Combined with the stack tracing commands like K and 
ClrStack, it is a good aid to determining the values of locals and 
parameters.

If you use the -verify option, each non-static CLASS field of an object
candidate is validated. This helps to eliminate false positives. It is not
on by default because very often in a debugging scenario, you are 
interested in objects with invalid fields.

The abbreviation dso can be used for brevity.
\\

COMMAND: dumpdelegate.
DumpDelegate <delegate address>

DumpDelegate finds and outputs the one or more method descriptors associated with a delegate object.

For example:

    (lldb) dumpdelegate
    Target           Method           Name
    000001461bacb0d8 00007ffc5c894b80 ConsoleApp16.Program.InstanceMethod()
    000001461bacb098 00007ffc5c894b68 ConsoleApp16.Program.StaticMethod()
\\

COMMAND: dumpheap.
DumpHeap [-stat] 
         [-strings] 
         [-short]
         [-min <size>] 
         [-max <size>] 
         [-live]
         [-dead]
         [-thinlock] 
         [-startAtLowerBound]
         [-mt <MethodTable address>] 
         [-type <partial type name>] 
         [start [end]]

DumpHeap is a powerful command that traverses the garbage collected heap, 
collection statistics about objects. With it's various options, it can look for
particular types, restrict to a range, or look for ThinLocks (see syncblk 
documentation). Finally, it will provide a warning if it detects excessive 
fragmentation in the GC heap. 

When called without options, the output is first a list of objects in the heap,
followed by a report listing all the types found, their size and number:

    (lldb) dumpheap
     Address       MT     Size
    00a71000 0015cde8       12 Free
    00a7100c 0015cde8       12 Free
    00a71018 0015cde8       12 Free
    00a71024 5ba58328       68
    00a71068 5ba58380       68
    00a710ac 5ba58430       68
    00a710f0 5ba5dba4       68
    ...
    total 619 objects
    Statistics:
          MT    Count TotalSize Class Name
    5ba7607c        1        12 System.Security.Permissions.HostProtectionResource
    5ba75d54        1        12 System.Security.Permissions.SecurityPermissionFlag
    5ba61f18        1        12 System.Collections.CaseInsensitiveComparer
    ...
    0015cde8        6     10260      Free
    5ba57bf8      318     18136 System.String
    ...

"Free" objects are simply regions of space the garbage collector can use later.
If 30% or more of the heap contains "Free" objects, the process may suffer from
heap fragmentation. This is usually caused by pinning objects for a long time 
combined with a high rate of allocation. Here is example output where DumpHeap
provides a warning about fragmentation:

    <After the Statistics section>
    Fragmented blocks larger than 1MB:
        Addr     Size Followed by
    00a780c0    1.5MB    00bec800 System.Byte[]
    00da4e38    1.2MB    00ed2c00 System.Byte[]
    00f16df0    1.2MB    01044338 System.Byte[]

The arguments in detail:

-stat     Restrict the output to the statistical type summary
-strings  Restrict the output to a statistical string value summary
-short    Limits output to just the address of each object. This allows you
          to easily pipe output from the command to another debugger 
          command for automation.
-min      Ignore objects less than the size given in bytes (hex)
-max      Ignore objects larger than the size given in bytes (hex)
-live     Only print live objects
-dead     Only print dead objects (objects which will be collected in the
          next full GC)
-thinlock Report on any ThinLocks (an efficient locking scheme, see syncblk 
          documentation for more info)
-startAtLowerBound 
          Force heap walk to begin at lower bound of a supplied address range.
          (During plan phase, the heap is often not walkable because objects 
          are being moved. In this case, DumpHeap may report spurious errors, 
          in particular bad objects. It may be possible to traverse more of 
          the heap after the reported bad object. Even if you specify an 
          address range, DumpHeap will start its walk from the beginning of 
          the heap by default. If it finds a bad object before the specified 
          range, it will stop before displaying the part of the heap in which 
          you are interested. This switch will force DumpHeap to begin its 
          walk at the specified lower bound. You must supply the address of a 
          good object as the lower bound for this to work. Display memory at 
          the address of the bad object to manually find the next method 
          table (use DumpMT to verify). If the GC is currently in a call to 
          memcopy, You may also be able to find the next object's address by 
          adding the size to the start address given as parameters.) 
-mt       List only those objects with the MethodTable given
-type     List only those objects whose type name is a substring match of the 
          string provided. 
start     Begin listing from this address
end       Stop listing at this address

A special note about -type: Often, you'd like to find not only Strings, but
System.Object arrays that are constrained to contain Strings. ("new 
String[100]" actually creates a System.Object array, but it can only hold
System.String object pointers). You can use -type in a special way to find
these arrays. Just pass "-type System.String[]" and those Object arrays will
be returned. More generally, "-type <Substring of interesting type>[]".

The start/end parameters can be obtained from the output of eeheap -gc. For 
example, if you only want to list objects in the large heap segment:

    (lldb) eeheap -gc
    Number of GC Heaps: 1
    generation 0 starts at 0x00c32754
    generation 1 starts at 0x00c32748
    generation 2 starts at 0x00a71000
     segment    begin allocated     size
    00a70000 00a71000  010443a8 005d33a8(6108072)
    Large object heap starts at 0x01a71000
     segment    begin allocated     size
    01a70000 01a71000  01a75000 0x00004000(16384)
    Total Size  0x5d73a8(6124456)
    ------------------------------
    GC Heap Size  0x5d73a8(6124456)

    (lldb) dumpheap 1a71000 1a75000
     Address       MT     Size
    01a71000 5ba88bd8     2064
    01a71810 0019fe48     2032 Free
    01a72000 5ba88bd8     4096
    01a73000 0019fe48     4096 Free
    01a74000 5ba88bd8     4096
    total 5 objects
    Statistics:
          MT    Count TotalSize Class Name
    0019fe48        2      6128      Free
    5ba88bd8        3     10256 System.Object[]
    Total 5 objects

Finally, if GC heap corruption is present, you may see an error like this:

    (lldb) dumpheap -stat
    object 00a73d24: does not have valid MT
    curr_object : 00a73d24
    Last good object: 00a73d14
    ----------------

That indicates a serious problem. See the help for VerifyHeap for more 
information on diagnosing the cause.
\\

COMMAND: dumpvc.
DumpVC <MethodTable address> <Address>

DumpVC allows you to examine the fields of a value class. In C#, this is a 
struct, and lives on the stack or within an Object on the GC heap. You need
to know the MethodTable address to tell SOS how to interpret the fields, as
a value class is not a first-class object with it's own MethodTable as the
first field. For example:

    (lldb) sos DumpObj a79d98
    Name: Mainy
    MethodTable: 009032d8
    EEClass: 03ee1424
    Size: 28(0x1c) bytes
     (/home/user/pub/unittest)
    Fields:
          MT    Field   Offset                 Type       Attr    Value Name
    0090320c  4000010        4            VALUETYPE   instance 00a79d9c m_valuetype
    009032d8  400000f        4                CLASS     static 00a79d54 m_sExcep

m_valuetype is a value type. The value in the MT column (0090320c) is the 
MethodTable for it, and the Value column provides the start address:

    (lldb) sos DumpVC 0090320c 00a79d9c
    Name: Funny
    MethodTable 0090320c
    EEClass: 03ee14b8
    Size: 28(0x1c) bytes
     (/home/user/pub/unittest)
    Fields:
          MT    Field   Offset                 Type       Attr    Value Name
    0090320c  4000001        0                CLASS   instance 00a743d8 signature
    0090320c  4000002        8         System.Int32   instance     2345 m1
    0090320c  4000003       10       System.Boolean   instance        1 b1
    0090320c  4000004        c         System.Int32   instance     1234 m2
    0090320c  4000005        4                CLASS   instance 00a79d98 backpointer

DumpVC is quite a specialized function. Some managed programs make heavy use 
of value classes, while others do not.
\\

COMMAND: gcroot.
GCRoot [-nostacks] [-all] <Object address>

GCRoot looks for references (or roots) to an object. These can exist in four
places:

   1. On the stack
   2. Within a GC Handle
   3. In an object ready for finalization
   4. As a member of an object found in 1, 2 or 3 above.

First, all stacks will be searched for roots, then handle tables, and finally
the reachable queue of the finalizer. Some caution about the stack roots: 
GCRoot doesn't attempt to determine if a stack root it encountered is valid 
or is old (discarded) data. You would have to use ClrStack and U to 
disassemble the frame that the local or argument value belongs to in order to 
determine if it is still in use.

Because people often want to restrict the search to gc handles and reachable
objects, there is a -nostacks option.

The -all option forces all roots to be displayed instead of just the unique roots.
\\

COMMAND: objsize.
ObjSize [<Object address>]

With no parameters, ObjSize lists the size of all objects found on managed 
threads. It also enumerates all GCHandles in the process, and totals the size 
of any objects pointed to by those handles. In calculating object size, 
ObjSize includes the size of all child objects in addition to the parent.

For example, DumpObj lists a size of 20 bytes for this Customer object:

    (lldb) dumpobj a79d40
    Name: Customer
    MethodTable: 009038ec
    EEClass: 03ee1b84
    Size: 20(0x14) bytes
     (C:\pub\unittest.exe)
    Fields:
          MT    Field   Offset                 Type       Attr    Value Name
    009038ec  4000008        4                CLASS   instance 00a79ce4 name
    009038ec  4000009        8                CLASS   instance 00a79d2c bank
    009038ec  400000a        c       System.Boolean   instance        1 valid

but ObjSize lists 152 bytes:

    (lldb) ObjSize a79d40
    sizeof(00a79d40) =      152 (    0x98) bytes (Customer)

This is because a Customer points to a Bank, has a name, and the Bank points to
an Address string. You can use ObjSize to identify any particularly large 
objects, such as a managed cache in a web server.

While running ObjSize with no arguments may point to specific roots that hold 
onto large amounts of memory it does not provide information regarding the 
amount of managed memory that is still alive.  This is due to the fact that a 
number of roots can share a common subgraph, and that part will be reported in 
the size of all the roots that reference the subgraph.
\\

COMMAND: finalizequeue.
FinalizeQueue [-detail] | [-allReady] [-short]

This command lists the objects registered for finalization. Here is output from
a simple program:

    (lldb) finalizequeue
    SyncBlocks to be cleaned up: 0
    MTA Interfaces to be released: 0
    STA Interfaces to be released: 1
    generation 0 has 4 finalizable objects (0015bc90->0015bca0)
    generation 1 has 0 finalizable objects (0015bc90->0015bc90)
    generation 2 has 0 finalizable objects (0015bc90->0015bc90)
    Ready for finalization 0 objects (0015bca0->0015bca0)
    Statistics:
          MT    Count TotalSize Class Name
    5ba6cf78        1        24 Microsoft.Win32.SafeHandles.SafeFileHandle
    5ba5db04        1        68 System.Threading.Thread
    5ba73e28        2       112 System.IO.StreamWriter
    Total 4 objects

The GC heap is divided into generations, and objects are listed accordingly. We
see that only generation 0 (the youngest generation) has any objects registered
for finalization. The notation "(0015bc90->0015bca0)" means that if you look at
memory in that range, you'll see the object pointers that are registered:

0:000> dd 15bc90 15bca0-4
0015bc90  00a743f4 00a79f00 00a7b3d8 00a7b47c

You could run dumpobj on any of those pointers to learn more. In this example,
there are no objects ready for finalization, presumably because they still have
roots (You can use gcroot to find out). The statistics section provides a 
higher-level summary of the objects registered for finalization. Note that 
objects ready for finalization are also included in the statistics (if any).

Specifying -short will inhibit any display related to SyncBlocks or RCWs.

The arguments in detail:

-allReady Specifying this argument will allow for the display of all objects 
          that are ready for finalization, whether they are already marked by 
          the GC as such or not. The former means GC already put them in the 
          "Ready for finalization" list and their finalizers are ready to run
          but haven't run yet. The latter means there is nothing holding onto
          these objects but GC hasn't noticed it yet because a GC that collects
          the generation this object lives in has not happened yet. When that
          GC happens, this object will be moved to the "Ready for finalization"
          list. For example, if a finalizable object lives in gen2 and a gen2 GC
          has not happened, even if it's displayed by -allReady it's not actually
          ready for finalization. This option can be very expensive, as it 
          verifies whether all the objects in the finalizable queues are still
          rooted or not.
-short    Limits the output to just the address of each object.  If used in 
          conjunction with -allReady it enumerates all objects that have a 
          finalizer that are no longer rooted.  If used independently it lists 
          all objects in the finalizable and "ready for finalization" queues.
-detail   Will display extra information on any SyncBlocks that need to be 
          cleaned up, and on any RuntimeCallableWrappers (RCWs) that await 
          cleanup.  Both of these data structures are cached and cleaned up by 
          the finalizer thread when it gets a chance to run.
\\
COMMAND: pe.
COMMAND: printexception.
PrintException [-nested] [-lines] [-ccw] [<Exception object address>] [<CCW pointer>]

This will format fields of any object derived from System.Exception. One of the
more useful aspects is that it will format the _stackTrace field, which is a 
binary array. If _stackTraceString field is not filled in, that can be helpful 
for debugging. You can of course use DumpObj on the same exception object to 
explore more fields.

If called with no parameters, PrintException will look for the last outstanding 
exception on the current thread and print it. This will be the same exception
that shows up in a run of clrthreads.

PrintException will notify you if there are any nested exceptions on the 
current managed thread. (A nested exception occurs when you throw another
exception within a catch handler already being called for another exception).
If there are nested exceptions, you can re-run PrintException with the 
"-nested" option to get full details on the nested exception objects. The
clrthreads command will also tell you which threads have nested exceptions.

PrintException can display source information if available, by specifying the 
-lines command line argument.

PrintException prints the exception object corresponding to a given CCW pointer, 
which can be specified using the -ccw option. 

The abbreviation 'pe' can be used for brevity.
\\

COMMAND: traverseheap.
Traverseheap [-xml] [-verify] <filename>

traverseheap writes out a file in a format understood by the CLR Profiler. 
You can download the CLR Profiler from this link:

http://www.microsoft.com/downloads/details.aspx?FamilyId=86CE6052-D7F4-4AEB-
9B7A-94635BEEBDDA&displaylang=en

It creates a graphical display of the GC heap to help you analyze the state of
your application. 

If you pass the -verify option it will do more sanity checking of the heap
as it dumps it.   Use this option if heap corruption is suspected.

If you pass the "-xml" flag, the file is instead written out in an easy to 
understand xml format:

    <gcheap>
        <types>
            <type id="1" name="System.String">
            ...
        </types>
        <roots>
            <root kind="handle" address="0x00a73ff0"/>
            <root kind="stack" address="0x0069f0e0"/>
            ...
        </roots>
        <objects>
            <object address="0x00b73030" typeid="1" size="300"/>
            <object address="0x00b75054" typeid="5" size="20">
                <member address="0x00b75088" />
                ...
            </object>
            ...
        </objects>
    </gcheap>

You can break into your process, load SOS, take a snapshot of your heap with 
this function, then continue.

\\
COMMAND: threadstate.
ThreadState value

The clrthreads command outputs, among other things, the state of the thread.
This is a bit field which corresponds to various states the thread is in.
To check the state of the thread, simply pass that bit field from the
output of clrthreads into ThreadState.

Example:
    (lldb) clrthreads
    ThreadCount:      2
    UnstartedThread:  0
    BackgroundThread: 1
    PendingThread:    0
    DeadThread:       0
    Hosted Runtime:   no
                                          PreEmptive   GC Alloc           Lock
           ID OSID ThreadOBJ    State     GC       Context       Domain   Count APT Exception
       0    1  250 0019b068      a020 Disabled 02349668:02349fe8 0015def0     0 MTA
       2    2  944 001a6020      b220 Enabled  00000000:00000000 0015def0     0 MTA (Finalizer)
    0:003> sos ThreadState b220
        Legal to Join
        Background
        CLR Owns
        CoInitialized
        In Multi Threaded Apartment

Possible thread states:
    Thread Abort Requested
    GC Suspend Pending
    User Suspend Pending
    Debug Suspend Pending
    GC On Transitions
    Legal to Join
    Yield Requested
    Hijacked by the GC
    Blocking GC for Stack Overflow
    Background
    Unstarted
    Dead
    CLR Owns
    CoInitialized
    In Single Threaded Apartment
    In Multi Threaded Apartment
    Reported Dead
    Fully initialized
    Task Reset
    Sync Suspended
    Debug Will Sync
    Stack Crawl Needed
    Suspend Unstarted
    Aborted
    Thread Pool Worker Thread
    Interruptible
    Interrupted
    Completion Port Thread
    Abort Initiated
    Finalized
    Failed to Start
    Detached
\\

COMMAND: threads.
COMMAND: clrthreads.
Threads [-live] [-special] 

Threads (clrthreads) lists all the mananaged threads in the process. 

-live:     optional. Only print threads associated with a live thread.
-special:  optional. With this switch, the command will display all the special
           threads created by CLR. Those threads might not be managed threads 
           so they might not be shown in the first part of the command's 
           output. Example of special threads include: GC threads (in 
           concurrent GC and server GC), Debugger helper threads, Finalizer 
           threads, AppDomain Unload threads, and Threadpool timer threads.
-managedexception: optional. Sets the current thread to first thread with 
                   an managed exception for the "printexception" command.

Each thread has many attributes, many of which can be ignored. The important 
ones are discussed below:

There are three ID columns: 

1) The debugger shorthand ID (When the runtime is hosted this column might 
   display the special string "<<<<" when this internal thread object is not 
   associated with any physical thread - this may happen when the host reuses
   the runtime internal thread object)
2) The CLR Thread ID
3) The OS thread ID.  

If PreEmptiveGC is enabled for a thread, then a garbage collection 
can occur while that thread is running. For example, if you break in while
a managed thread is making a PInvoke call to a Win32 function, that thread 
will be in PreEmptive GC mode. 

The Domain column indicates what AppDomain the thread is currently executing
in. You can pass this value to DumpDomain to find out more. 

The APT column gives the COM apartment mode. 

Exception will list the last thrown exception (if any) for the thread. More
details can be obtained by passing the pointer value to PrintException. If
you get the notation "(nested exceptions)", you can get details on those
exceptions by switching to the thread in question, and running 
"PrintException -nested".
\\

COMMAND: clrstack.
ClrStack [-a] [-l] [-p] [-n] [-f] [-r] [-all]
ClrStack [-a] [-l] [-p] [-i] [variable name] [frame]

ClrStack attempts to provide a true stack trace for managed code only. It is
handy for clean, simple traces when debugging straightforward managed 
programs. The -p parameter will show arguments to the managed function. The 
-l parameter can be used to show information on local variables in a frame.
SOS can't retrieve local names at this time, so the output for locals is in
the format <local address> = <value>. The -a (all) parameter is a short-cut
for -l and -p combined. 

The -f option (full mode) displays the native frames intermixing them with
the managed frames and the assembly name and function offset for the managed
frames.

The -r option dumps the registers for each stack frame.

The -all option dumps all the managed threads' stacks.

If the debugger has the option SYMOPT_LOAD_LINES specified (either by the
.lines or .symopt commands), SOS will look up the symbols for every managed 
frame and if successful will display the corresponding source file name and 
line number. The -n (No line numbers) parameter can be specified to disable 
this behavior.

When you see methods with the name "[Frame:...", that indicates a transition 
between managed and unmanaged code. You could run IP2MD on the return 
addresses in the call stack to get more information on each managed method.

On x64 platforms, Transition Frames are not displayed at this time. To avoid
heavy optimization of parameters and locals one can request the JIT compiler
to not optimize functions in the managed app by creating a file myapp.ini 
(if your program is myapp.exe) in the same directory. Put the following lines
in myapp.ini and re-run:

[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0

The -i option is a new EXPERIMENTAL addition to ClrStack and will use the ICorDebug
interfaces to display the managed stack and variables. With this option you can also 
view and expand arrays and fields for managed variables. If a stack frame number is 
specified in the command line, ClrStack will show you the parameters and/or locals 
only for that frame (provided you specify -l or -p or -a of course). If a variable 
name and a stack frame number are specified in the command line, ClrStack will show 
you the parameters and/or locals for that frame, and will also show you the fields 
for that variable name you specified. Here are some examples: 
   clrstack -i -a           : This will show you all parameters and locals for all frames
   clrstack -i -a 3         : This will show you all parameters and locals, for frame 3
   clrstack -i var1 0       : This will show you the fields of 'var1' for frame 0
   clrstack -i var1.abc 2   : This will show you the fields of 'var1', and expand
                              'var1.abc' to show you the fields of the 'abc' field,
                              for frame 2.
   clrstack -i var1.[basetype] 0   : This will show you the fields of 'var1', and
                                     expand the base type of 'var1' to show you its
                                     fields.
   clrstack -i var1.[6] 0   : If 'var1' is an array, this will show you the element
                              at index 6 in the array, along with its fields
The -i options uses DML output for a better debugging experience, so typically you
should only need to execute "clrstack -i", and from there, click on the DML 
hyperlinks to inspect the different managed stack frames and managed variables.                             
\\

COMMAND: createdump.
Currently not implemented.
\\

COMMAND: ip2md.
IP2MD <Code address>

Given an address in managed JITTED code, IP2MD attempts to find the MethodDesc
associated with it. For example, this output from K:

    (lldb) bt 
        ...
        frame #9: 0x00007fffffffbf60 0x00007ffff61c6d89 libcoreclr.so`MethodDesc::DoPrestub(this=0x00007ffff041f870, pDispatchingMT=0x0000000000000000) + 3001 at prestub.cpp:1490
        frame #10: 0x00007fffffffc140 0x00007ffff61c5f17 libcoreclr.so`::PreStubWorker(pTransitionBlock=0x00007fffffffc9a8, pMD=0x00007ffff041f870) + 1399 at prestub.cpp:1037
        frame #11: 0x00007fffffffc920 0x00007ffff5f5238c libcoreclr.so`ThePreStub + 92 at theprestubamd64.S:800
        frame #12: 0x00007fffffffca10 0x00007ffff04981cc
        frame #13: 0x00007fffffffca30 0x00007ffff049773c
        frame #14: 0x00007fffffffca80 0x00007ffff04975ad
        ...
        frame #22: 0x00007fffffffcc90 0x00007ffff5f51a0f libcoreclr.so`CallDescrWorkerInternal + 124 at calldescrworkeramd64.S:863
        frame #23: 0x00007fffffffccb0 0x00007ffff5d6d6dc libcoreclr.so`CallDescrWorkerWithHandler(pCallDescrData=0x00007fffffffce80, fCriticalCall=0) + 476 at callhelpers.cpp:88
        frame #24: 0x00007fffffffcd00 0x00007ffff5d6eb38 libcoreclr.so`MethodDescCallSite::CallTargetWorker(this=0x00007fffffffd0c8, pArguments=0x00007fffffffd048) + 2504 at callhelpers.cpp:633

    (lldb) ip2md 0x00007ffff049773c
        MethodDesc:   00007ffff7f71920
        Method Name:  Microsoft.Win32.SafeHandles.SafeFileHandle.Open(System.Func`1<Int32>)
        Class:        00007ffff0494bf8
        MethodTable:  00007ffff7f71a58
        mdToken:      0000000006000008
        Module:       00007ffff7f6b938
        IsJitted:     yes
        CodeAddr:     00007ffff04976c0

We have taken a return address into Mainy.Main, and discovered information 
about that method. You could run U, DumpMT, DumpClass, DumpMD, or 
DumpModule on the fields listed to learn more.

The "Source line" output will only be present if the debugger can find the 
symbols for the managed module containing the given <code address>, and if the 
debugger is configured to load line number information.
\\

COMMAND: clru.
COMMAND: u.
U [-gcinfo] [-ehinfo] [-n] [-o] <MethodDesc address> | <Code address>

Presents an annotated disassembly of a managed method when given a MethodDesc
pointer for the method, or a code address within the method body. Unlike the
debugger "U" function, the entire method from start to finish is printed,
with annotations that convert metadata tokens to names.

    <example output>
    ...
    03ef015d b901000000       mov     ecx,0x1
    03ef0162 ff156477a25b     call   dword ptr [mscorlib_dll+0x3c7764 (5ba27764)] (System.Console.InitializeStdOutError(Boolean), mdToken: 06000713)
    03ef0168 a17c20a701       mov     eax,[01a7207c] (Object: SyncTextWriter)
    03ef016d 89442414         mov     [esp+0x14],eax

If you pass the -gcinfo flag, you'll get inline display of the GCInfo for
the method. You can also obtain this information with the GCInfo command.

If you pass the -ehinfo flag, you'll get inline display of exception info
for the method. (Beginning and end of try/finally/catch handlers, etc.).
You can also obtain this information with the EHInfo command.

If you pass the -o flag, the byte offset of each instruction from the
beginning of the method will be printed in addition to the absolute address of
the instruction.

If the debugger has the option SYMOPT_LOAD_LINES specified (either by the
.lines or .symopt commands), and if symbols are available for the managed
module containing the method being examined, the output of the command will
include the source file name and line number corresponding to the 
disassembly. The -n (No line numbers) flag can be specified to disable this
behavior.

    <example output>
    ...
    c:\Code\prj.mini\exc.cs @ 38:
    001b00b0 8b0d3020ab03    mov     ecx,dword ptr ds:[3AB2030h] ("Break in debugger. When done type <Enter> to continue: ")
    001b00b6 e8d5355951      call    mscorlib_ni+0x8b3690 (51743690) (System.Console.Write(System.String), mdToken: 0600091b)
    001b00bb 90              nop

    c:\Code\prj.mini\exc.cs @ 39:
    001b00bc e863cdc651      call    mscorlib_ni+0xf8ce24 (51e1ce24) (System.Console.ReadLine(), mdToken: 060008f6)
    >>> 001b00c1 90              nop
    ...
\\

COMMAND: dumpstack.
DumpStack [-EE] [-n] [top stack [bottom stack]]

[x86 and x64 documentation]

This command provides a verbose stack trace obtained by "scraping." Therefore
the output is very noisy and potentially confusing. The command is good for
viewing the complete call stack when "kb" gets confused. For best results,
make sure you have valid symbols.

-EE will only show managed functions.

If the debugger has the option SYMOPT_LOAD_LINES specified (either by the
.lines or .symopt commands), SOS will look up the symbols for every managed 
frame and if successful will display the corresponding source file name and 
line number. The -n (No line numbers) parameter can be specified to disable 
this behavior.

You can also pass a stack range to limit the output.
\\

COMMAND: eestack.
EEStack [-short] [-EE]

This command runs DumpStack on all threads in the process. The -EE option is 
passed directly to DumpStack. The -short option tries to narrow down the 
output to "interesting" threads only, which is defined by

1) The thread has taken a lock.
2) The thread has been "hijacked" in order to allow a garbage collection.
3) The thread is currently in managed code.

See the documentation for DumpStack for more info.
\\

COMMAND: ehinfo.
EHInfo (<MethodDesc address> | <Code address>)

EHInfo shows the exception handling blocks in a jitted method. For each 
handler, it shows the type, including code addresses and offsets for the clause
block and the handler block. For a TYPED handler, this would be the "try" and
"catch" blocks respectively.

Sample output:

    (lldb) sos EHInfo 33bbd3a
    MethodDesc: 03310f68
    Method Name: MainClass.Main()
    Class: 03571358
    MethodTable: 0331121c
    mdToken: 0600000b
    Module: 001e2fd8
    IsJitted: yes
    CodeAddr: 033bbca0

    EHHandler 0: TYPED catch(System.IO.FileNotFoundException) 
    Clause: [033bbd2b, 033bbd3c] [8b, 9c]
    Handler: [033bbd3c, 033bbd50] [9c, b0]

    EHHandler 1: FINALLY
    Clause: [033bbd83, 033bbda3] [e3, 103]
    Handler: [033bbda3, 033bbdc5] [103, 125]

    EHHandler 2: TYPED catch(System.Exception)
    Clause: [033bbd7a, 033bbdc5] [da, 125]
    Handler: [033bbdc5, 033bbdd6] [125, 136]

\\

COMMAND: gcinfo.
GCInfo (<MethodDesc address> | <Code address>)

GCInfo is especially useful for CLR Devs who are trying to determine if there 
is a bug in the JIT Compiler. It parses the GCEncoding for a method, which is a
compressed stream of data indicating when registers or stack locations contain 
managed objects. It is important to keep track of this information, because if 
a garbage collection occurs, the collector needs to know where roots are so it 
can update them with new object pointer values.

Here is sample output where you can see the change in register state. Normally 
you would print this output out and read it alongside a disassembly of the 
method. For example, the notation "reg EDI becoming live" at offset 0x11 of the
method might correspond to a "mov edi,ecx" statement.

    (lldb) sos GCInfo 5b68dbb8   (5b68dbb8 is the start of a JITTED method)
    entry point 5b68dbb8
    preJIT generated code
    GC info 5b9f2f09
    Method info block:
        method      size   = 0036
        prolog      size   =  19
        epilog      size   =   8
        epilog     count   =   1
        epilog      end    = yes
        saved reg.  mask   = 000B
        ebp frame          = yes
        fully interruptible=yes
        double align       = no
        security check     = no
        exception handlers = no
        local alloc        = no
        edit & continue    = no
        varargs            = no
        argument   count   =   4
        stack frame size   =   1
        untracked count    =   5
        var ptr tab count  =   0
        epilog        at   002E
    36 D4 8C C7 AA |
    93 F3 40 05    |

    Pointer table:
    14             |             [EBP+14H] an untracked  local
    10             |             [EBP+10H] an untracked  local
    0C             |             [EBP+0CH] an untracked  local
    08             |             [EBP+08H] an untracked  local
    44             |             [EBP-04H] an untracked  local
    F1 79          | 0011        reg EDI becoming live
    72             | 0013        reg ESI becoming live
    83             | 0016        push ptr  0
    8B             | 0019        push ptr  1
    93             | 001C        push ptr  2
    9B             | 001F        push ptr  3
    56             | 0025        reg EDX becoming live
    4A             | 0027        reg ECX becoming live
    0E             | 002D        reg ECX becoming dead
    10             | 002D        reg EDX becoming dead
    E0             | 002D        pop  4 ptrs
    F0 31          | 0036        reg ESI becoming dead
    38             | 0036        reg EDI becoming dead
    FF             |

This function is important for CLR Devs, but very difficult for anyone else to 
make sense of it. You would usually come to use it if you suspect a gc heap 
corruption bug caused by invalid GCEncoding for a particular method.
\\

COMMAND: bpmd.
bpmd [-nofuturemodule] <module name> <method name> [<il offset>]
bpmd <source file name>:<line number>
bpmd -md <MethodDesc>
bpmd -list
bpmd -clear <pending breakpoint number>
bpmd -clearall

bpmd provides managed breakpoint support. If it can resolve the method name
to a loaded, jitted or ngen'd function it will create a breakpoint with "bp".
If not then either the module that contains the method hasn't been loaded yet
or the module is loaded, but the function is not jitted yet. In these cases,
bpmd asks the Debugger to receive CLR Notifications, and waits to receive news 
of module loads and JITs, at which time it will try to resolve the function to
a breakpoint. -nofuturemodule can be used to suppress creating a breakpoint 
against a module that has not yet been loaded.

Management of the list of pending breakpoints can be done via bpmd -list,
bpmd -clear, and bpmd -clearall commands. bpmd -list generates a list of 
all of the pending breakpoints. If the pending breakpoint has a non-zero 
module id, then that pending breakpoint is specific to function in that 
particular loaded module. If the pending breakpoint has a zero module id, then
the breakpoint applies to modules that have not yet been loaded. Use 
bpmd -clear or bpmd -clearall to remove pending breakpoints from the list.

The bpmd command can now be used before the runtime is loaded. You can execute
bpmd right after the SOS plug-in is loaded. Always add the module extension for
the module name parameter.

This brings up a good question: "I want to set a breakpoint on the main
method of my application. How can I do this?"

  1) Add the breakpoint with command such as:
       bpmd myapp.dll MyApp.Main
  2) g
  3) You will stop at the start of MyApp.Main. If you type "bl" you will 
     see the breakpoint listed.

To correctly specify explicitly implemented methods make sure to retrieve the
method name from the metadata, or from the output of the "dumpmt -md" command. 
For example:

    public interface I1
    {
        void M1();
    }
    public class ExplicitItfImpl : I1
    {
        ...
        void I1.M1()        // this method's name is 'I1.M1'
        { ... }
    }

    bpmd myapp.dll ExplicitItfImpl.I1.M1


bpmd works equally well with generic types. Adding a breakpoint on a generic 
type sets breakpoints on all already JIT-ted generic methods and sets a pending 
breakpoint for any instantiation that will be JIT-ted in the future.

Example for generics:
    Given the following two classes:

    class G3<T1, T2, T3> 
    {
        ...
        public void F(T1 p1, T2 p2, T3 p3)
        { ... }
    }

    public class G1<T> {
        // static method
        static public void G<W>(W w)
        { ... }
    }

    One would issue the following commands to set breakpoints on G3.F() and 
    G1.G():

    bpmd myapp.dll G3`3.F
    bpmd myapp.dll G1`1.G

And for explicitly implemented methods on generic interfaces:
    public interface IT1<T>
    {
        void M1(T t);
    }

    public class ExplicitItfImpl<U> : IT1<U>
    {
        ...
        void IT1<U>.M1(U u)    // this method's name is 'IT1<U>.M1'
        { ... }
    }

    bpmd bpmd.dll ExplicitItfImpl`1.IT1<U>.M1

Additional examples:
    If IT1 and ExplicitItfImpl are types declared inside another class, 
    Outer, the bpmd command would become:

    bpmd bpmd.exe Outer+ExplicitItfImpl`1.Outer.IT1<U>.M1

    (note that the fully qualified type name for ExplicitItfImpl became
    Outer+ExplicitItfImpl, using the '+' separator, while the method name
    is Outer.IT1<U>.M1, using a '.' as the separator)

    Furthermore, if the Outer class resides in a namespace, NS, the bpmd 
    command to use becomes:

    bpmd bpmd.dll NS.Outer+ExplicitItfImpl`1.NS.Outer.IT1<U>.M1

bpmd does not accept offsets nor parameters in the method name. You can add
an IL offset as an optional parameter separate from the name. If there are overloaded
methods, bpmd will set a breakpoint for all of them.

In the case of hosted environments such as SQL, the module name may be 
complex, like 'price, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.
For this case, just be sure to surround the module name with single quotes,
like:

bpmd 'price, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' Price.M2

\\

COMMAND: dumpdomain.
DumpDomain [<Domain address>]

When called with no parameters, DumpDomain will list all the AppDomains in the
process. It enumerates each Assembly loaded into those AppDomains as well. 
In addition to your application domain, and any domains it might create, there
are two special domains: the Shared Domain and the System Domain.

Any Assembly pointer in the output can be passed to DumpAssembly. Any Module 
pointer in the output can be passed to DumpModule. Any AppDomain pointer can 
be passed to DumpDomain to limit output only to that AppDomain. Other 
functions provide an AppDomain pointer as well, such as clrthreads where it lists
the current AppDomain for each thread.
\\

COMMAND: eeheap.
EEHeap [-gc] [-loader]

EEHeap enumerates process memory consumed by internal CLR data structures. You
can limit the output by passing "-gc" or "-loader". All information will be 
displayed otherwise.

The information for the Garbage Collector lists the ranges of each Segment in 
the managed heap. This can be useful if you believe you have an object pointer.
If the pointer falls within a segment range given by "eeheap -gc", then you do
have an object pointer, and can attempt to run "dumpobj" on it.

Here is output for a simple program:

    (lldb) eeheap -gc
    Number of GC Heaps: 1
    generation 0 starts at 0x00a71018
    generation 1 starts at 0x00a7100c
    generation 2 starts at 0x00a71000
     segment    begin allocated     size
    00a70000 00a71000  00a7e01c 0000d01c(53276)
    Large object heap starts at 0x01a71000
     segment    begin allocated     size
    01a70000 01a71000  01a76000 0x00005000(20480)
    Total Size   0x1201c(73756)
    ------------------------------
    GC Heap Size   0x1201c(73756)

So the total size of the GC Heap is only 72K. On a large web server, with 
multiple processors, you can expect to see a GC Heap of 400MB or more. The 
Garbage Collector attempts to collect and reclaim memory only when required to
by memory pressure for better performance. You can also see the notion of 
"generations," wherein the youngest objects live in generation 0, and 
long-lived objects eventually get "promoted" to generation 2.

The loader output lists various private heaps associated with AppDomains. It 
also lists heaps associated with the JIT compiler, and heaps associated with 
Modules. For example:

    (lldb) eeheap -loader
    Loader Heap:
    --------------------------------------
    System Domain: 5e0662a0
    LowFrequencyHeap:008f0000(00002000:00001000) Size: 0x00001000 bytes.
    HighFrequencyHeap:008f2000(00008000:00001000) Size: 0x00001000 bytes.
    StubHeap:008fa000(00002000:00001000) Size: 0x00001000 bytes.
    Total size: 0x3000(12288)bytes
    --------------------------------------
    Shared Domain: 5e066970
    LowFrequencyHeap:00920000(00002000:00001000) 03e30000(00010000:00003000) Size: 0x00004000 bytes.
    Wasted: 0x00001000 bytes.
    HighFrequencyHeap:00922000(00008000:00001000) Size: 0x00001000 bytes.
    StubHeap:0092a000(00002000:00001000) Size: 0x00001000 bytes.
    Total size: 0x6000(24576)bytes
    --------------------------------------
    Domain 1: 14f000
    LowFrequencyHeap:00900000(00002000:00001000) 03ee0000(00010000:00003000) Size: 0x00004000 bytes.
    Wasted: 0x00001000 bytes.
    HighFrequencyHeap:00902000(00008000:00003000) Size: 0x00003000 bytes.
    StubHeap:0090a000(00002000:00001000) Size: 0x00001000 bytes.
    Total size: 0x8000(32768)bytes
    --------------------------------------
    Jit code heap:
    Normal JIT:03ef0000(00010000:00002000) Size: 0x00002000 bytes.
    Total size: 0x2000(8192)bytes
    --------------------------------------
    Module Thunk heaps:
    Module 5ba22410: Size: 0x00000000 bytes.
    Module 001c1320: Size: 0x00000000 bytes.
    Module 001c03f0: Size: 0x00000000 bytes.
    Module 001caa38: Size: 0x00000000 bytes.
    Total size: 0x0(0)bytes
    --------------------------------------
    Module Lookup Table heaps:
    Module 5ba22410:Size: 0x00000000 bytes.
    Module 001c1320:Size: 0x00000000 bytes.
    Module 001c03f0:Size: 0x00000000 bytes.
    Module 001caa38:03ec0000(00010000:00002000) Size: 0x00002000 bytes.
    Total size: 0x2000(8192)bytes
    --------------------------------------
    Total LoaderHeap size: 0x15000(86016)bytes
    =======================================

By using eeheap to keep track of the growth of these private heaps, we are 
able to rule out or include them as a source of a memory leak.
\\

COMMAND: name2ee.
Name2EE <module name> <type or method name>
Name2EE <module name>!<type or method name>

This function allows you to turn a class name into a MethodTable and EEClass. 
It turns a method name into a MethodDesc. Here is an example for a method:

    (lldb) name2ee unittest.exe MainClass.Main
    Module: 001caa38
    Token: 0x0600000d
    MethodDesc: 00902f40
    Name: MainClass.Main()
    JITTED Code Address: 03ef00b8

and for a class:

    (lldb) name2ee unittest!MainClass
    Module: 001caa38
    Token: 0x02000005
    MethodTable: 009032d8
    EEClass: 03ee1424
    Name: MainClass

The module you are "browsing" with Name2EE needs to be loaded in the process. 
To get a type name exactly right, first browse the module with ILDASM. You
can also pass * as the <module name> to search all loaded managed modules.
<module name> can also be the debugger's name for a module, such as
mscorlib or image00400000.

The <module>!<type> syntax is also supported. You can use an asterisk on the 
left of the !, but the type on the right side needs to be fully qualified.

If you are looking for a way to display a static field of a class (and you
don't have an instance of the class, so dumpobj won't help you), note that
once you have the EEClass, you can run DumpClass, which will display the
value of all static fields.

There is yet one more way to specify a module name. In the case of modules
loaded from an assembly store (such as a SQL db) rather than disk, the
module name will look like this:

price, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null

For this kind of module, simply use price as the module name:

    0:044> name2ee price Price
    Module: 10f028b0 (price, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null)
    Token: 0x02000002
    MethodTable: 11a47ae0
    EEClass: 11a538c8
    Name: Price

Where are we getting these module names from? Run DumpDomain to see a list of
all loaded modules in all domains. And remember that you can browse all the
types in a module with DumpModule -mt <module pointer>.
\\

COMMAND: syncblk.
SyncBlk [-all | <syncblk number>]

A SyncBlock is a holder for extra information that doesn't need to be created 
for every object. It can hold COM Interop data, HashCodes, and locking 
information for thread-safe operations.

When called without arguments, syncblk will print the list of SyncBlocks 
corresponding to objects that are owned by a thread. For example, a

    lock(MyObject)
    {
        ....
    }

statement will set MyObject to be owned by the current thread. A SyncBlock will
be created for MyObject, and the thread ownership information stored there 
(this is an oversimplification, see NOTE below). If another thread tries to 
execute the same code, they won't be able to enter the block until the first 
thread exits.

This makes syncblk useful for detecting managed deadlocks. Consider that the
following code is executed by Threads A & B:

    Resource r1 = new Resource();
    Resource r2 = new Resource();

    ...
    
    lock(r1)                             lock(r2)
    {                                    {
        lock(r2)                             lock(r1)
        {                                    {
            ...                                  ...
        }                                    }
    }                                    }

This is a deadlock situation, as Thread A could take r1, and Thread B r2, 
leaving both threads with no option but to wait forever in the second lock 
statement. syncblk will detect this with the following output:

        0:003> syncblk
        Index SyncBlock MonitorHeld Recursion Owning Thread Info   SyncBlock Owner
          238 001e40ec            3         1 001e4e60   e04   3   00a7a194 Resource
          239 001e4124            3         1 001e5980   ab8   4   00a7a1a4 Resource

It means that Thread e04 owns object 00a7a194, and Thread ab8 owns object 
00a7a1a4. Combine that information with the call stacks of the deadlock:

(threads 3 and 4 have similar output)  
        0:003> bt
        ChildEBP RetAddr
        0404ea04 77f5c524 SharedUserData!SystemCallStub+0x4
        0404ea08 77e75ee0 ntdll!NtWaitForMultipleObjects+0xc
        0404eaa4 5d9de9d6 KERNEL32!WaitForMultipleObjectsEx+0x12c
        0404eb38 5d9def80 coreclr!Thread::DoAppropriateAptStateWait+0x156
        0404ecc4 5d9dd8bb coreclr!Thread::DoAppropriateWaitWorker+0x360
        0404ed20 5da628dd coreclr!Thread::DoAppropriateWait+0xbb
        0404ede4 5da4e2e2 coreclr!CLREvent::Wait+0x29d
        0404ee70 5da4dd41 coreclr!AwareLock::EnterEpilog+0x132
        0404ef34 5da4efa3 coreclr!AwareLock::Enter+0x2c1
        0404f09c 5d767880 coreclr!AwareLock::Contention+0x483
        0404f1c4 03f00229 coreclr!JITutil_MonContention+0x2c0
        0404f1f4 5b6ef077 image00400000!Worker.Work()+0x79
        ...

By looking at the code corresponding to Worker.Work()+0x79 (run "clru 03f00229"),
you can see that thread 3 is attempting to acquire the Resource 00a7a1a4, which
is owned by thread 4.
  
NOTE:
It is not always the case that a SyncBlock will be created for every object 
that is locked by a thread. In version 2.0 of the CLR and above, a mechanism 
called a ThinLock will be used if there is not already a SyncBlock for the 
object in question. ThinLocks will not be reported by the syncblk command. 
You can use "dumpheap -thinlock" to list objects locked in this way.
\\

COMMAND: dumpmt.
DumpMT [-MD] <MethodTable address>

Examine a MethodTable. Each managed object has a MethodTable pointer at the 
start. If you pass the "-MD" flag, you'll also see a list of all the methods 
defined on the object. 
\\

COMMAND: dumpclass.
DumpClass <EEClass address>

The EEClass is a data structure associated with an object type. DumpClass 
will show attributes, as well as list the fields of the type. The output is 
similar to DumpObj. Although static field values will be displayed, 
non-static values won't because you need an instance of an object for that.

You can get an EEClass to look at from DumpMT, DumpObj, Name2EE, and 
Token2EE among others.
\\

COMMAND: dumpmd.
DumpMD <MethodDesc address>

This command lists information about a MethodDesc. You can use ip2md to turn 
a code address in a managed function into a MethodDesc:

    (lldb) dumpmd 902f40
    Method Name: Mainy.Main()
    Class: 03ee1424
    MethodTable: 009032d8
    mdToken: 0600000d
    Module: 001caa78
    IsJitted: yes
    CodeAddr: 03ef00b8

If IsJitted is "yes," you can run U on the CodeAddr pointer to see a 
disassembly of the JITTED code.  You can call also DumpClass, DumpMT, 
DumpModule on the Class, MethodTable and Module fields above.
\\

COMMAND: token2ee.
Token2EE <module name> <token>

This function allows you to turn a metadata token into a MethodTable or 
MethodDesc. Here is an example showing class tokens being resolved:

    (lldb) sos Token2EE unittest.exe 02000003
    Module: 001caa38
    Token: 0x02000003
    MethodTable: 0090375c
    EEClass: 03ee1ae0
    Name: Bank
    (lldb) sos Token2EE image00400000 02000004
    Module: 001caa38
    Token: 0x02000004
    MethodTable: 009038ec
    EEClass: 03ee1b84
    Name: Customer

The module you are "browsing" with Token2EE needs to be loaded in the process. 
This function doesn't see much use, especially since a tool like ILDASM can 
show the mapping between metadata tokens and types/methods in a friendlier way. 
But it could be handy sometimes.

You can pass "*" for <module name> to find what that token maps to in every
loaded managed module. <module name> can also be the debugger's name for a 
module, such as mscorlib or image00400000.
\\

COMMAND: dumpmodule.
DumpModule [-mt] <Module address>

You can get a Module address from DumpDomain, DumpAssembly and other 
functions. Here is sample output:

    (lldb) sos DumpModule 1caa50
    Name: /home/user/pub/unittest
    Attributes: PEFile
    Assembly: 001ca248
    LoaderHeap: 001cab3c
    TypeDefToMethodTableMap: 03ec0010
    TypeRefToMethodTableMap: 03ec0024
    MethodDefToDescMap: 03ec0064
    FieldDefToDescMap: 03ec00a4
    MemberRefToDescMap: 03ec00e8
    FileReferencesMap: 03ec0128
    AssemblyReferencesMap: 03ec012c
    MetaData start address: 00402230 (1888 bytes)

The Maps listed map metadata tokens to CLR data structures. Without going into 
too much detail, you can examine memory at those addresses to find the 
appropriate structures. For example, the TypeDefToMethodTableMap above can be 
examined:

    (lldb) dd 3ec0010
    03ec0010  00000000 00000000 0090320c 0090375c
    03ec0020  009038ec ...

This means TypeDef token 2 maps to a MethodTable with the value 0090320c. You 
can run DumpMT to verify that. The MethodDefToDescMap takes a MethodDef token 
and maps it to a MethodDesc, which can be passed to dumpmd.

There is a new option "-mt", which will display the types defined in a module,
and the types referenced by the module. For example:

    (lldb) sos DumpModule -mt 1aa580
    Name: /home/user/pub/unittest
    ...<etc>...
    MetaData start address: 0040220c (1696 bytes)

    Types defined in this module

          MT    TypeDef Name
    --------------------------------------------------------------------------
    030d115c 0x02000002 Funny
    030d1228 0x02000003 Mainy

    Types referenced in this module

          MT    TypeRef Name
    --------------------------------------------------------------------------
    030b6420 0x01000001 System.ValueType
    030b5cb0 0x01000002 System.Object
    030fceb4 0x01000003 System.Exception
    0334e374 0x0100000c System.Console
    03167a50 0x0100000e System.Runtime.InteropServices.GCHandle
    0336a048 0x0100000f System.GC
\\

COMMAND: threadpool.
ThreadPool

This command lists basic information about the ThreadPool, including the number
of work requests in the queue, number of completion port threads, and number of
timers.
\\

COMMAND: dumpassembly.
DumpAssembly <Assembly address>

Example output:

    (lldb) sos DumpAssembly 1ca248
    Parent Domain: 0014f000
    Name: /home/user/pub/unittest
    ClassLoader: 001ca060
      Module Name
    001caa50 /home/user/pub/unittest

An assembly can consist of multiple modules, and those will be listed. You can
get an Assembly address from the output of DumpDomain.
\\

COMMAND: dumpruntimetypes.
DumpRuntimeTypes 

DumpRuntimeTypes finds all System.RuntimeType objects in the gc heap and 
prints the type name and MethodTable they refer too. Sample output:

     Address   Domain       MT Type Name
    ------------------------------------------------------------------------------
      a515f4   14a740 5baf8d28 System.TypedReference
      a51608   14a740 5bb05764 System.Globalization.BaseInfoTable
      a51958   14a740 5bb05b24 System.Globalization.CultureInfo
      a51a44   14a740 5bb06298 System.Globalization.GlobalizationAssembly
      a51de0   14a740 5bb069c8 System.Globalization.TextInfo
      a56b98   14a740 5bb12d28 System.Security.Permissions.HostProtectionResource
      a56bbc   14a740 5baf7248 System.Int32
      a56bd0   14a740 5baf3fdc System.String
      a56cfc   14a740 5baf36a4 System.ValueType
    ...

This command will print a "?" in the domain column if the type is loaded into multiple
AppDomains.  For example:

    (lldb) sos DumpRuntimeTypes
     Address   Domain       MT Type Name              
    ------------------------------------------------------------------------------
     28435a0        ?   3f6a8c System.TypedReference
     28435b4        ?   214d6c System.ValueType
     28435c8        ?   216314 System.Enum
     28435dc        ?   2147cc System.Object
     284365c        ?   3cd57c System.IntPtr
     2843670        ?   3feaac System.Byte
     2843684        ?   23a544c System.IEquatable`1[[System.IntPtr, mscorlib]]
     2843784        ?   3c999c System.Int32
     2843798        ?   3caa04 System.IEquatable`1[[System.Int32, mscorlib]]
\\

COMMAND: dumpsig.
DumpSig <sigaddr> <moduleaddr>

This command dumps the signature of a method or field given by <sigaddr>.  This is
useful when you are debugging parts of the runtime which returns a raw PCCOR_SIGNATURE
structure and need to know what its contents are.

Sample output for a method:
    0:000> sos DumpSig 0x000007fe`ec20879d 0x000007fe`eabd1000
    [DEFAULT] [hasThis] Void (Boolean,String,String)

The first section of the output is the calling convention.  This includes, but is not
limited to, "[DEFAULT]", "[C]", "[STDCALL]", "[THISCALL]", and so on.  The second
portion of the output is either "[hasThis]" or "[explicit]" for whether the method
is an instance method or a static method respectively.  The third portion of the 
output is the return value (in this case a "void").  Finally, the method's arguments
are printed as the final portion of the output.

Sample output for a field:
    0:000> sos DumpSig 0x000007fe`eb7fd8cd 0x000007fe`eabd1000
    [FIELD] ValueClass System.RuntimeTypeHandle 

DumpSig will also work with generics.  Here is the output for the following
function:
    public A Test(IEnumerable<B> n)

    0:000> sos DumpSig 00000000`00bc2437 000007ff00043178 
    [DEFAULT] [hasThis] __Canon (Class System.Collections.Generic.IEnumerable`1<__Canon>)
\\

COMMAND: dumpsigelem.
DumpSigElem <sigaddr> <moduleaddr>

This command dumps a single element of a signature object.  For most circumstances,
you should use DumpSig to look at individual signature objects, but if you find a 
signature that has been corrupted in some manner you can use DumpSigElem to read out 
the valid portions of it.

If we look at a valid signature object for a method we see the following:
    0:000> dumpsig 0x000007fe`ec20879d 0x000007fe`eabd1000
    [DEFAULT] [hasThis] Void (Boolean,String,String)

We can look at the individual elements of this object by adding the offsets into the 
object which correspond to the return value and parameters:
    0:000> sos DumpSigElem 0x000007fe`ec20879d+2 0x000007fe`eabd1000
    Void
    0:000> sos DumpSigElem 0x000007fe`ec20879d+3 0x000007fe`eabd1000
    Boolean
    0:000> sos DumpSigElem 0x000007fe`ec20879d+4 0x000007fe`eabd1000
    String
    0:000> sos DumpSigElem 0x000007fe`ec20879d+5 0x000007fe`eabd1000
    String

We can do something similar for fields.  Here is the full signature of a field:
    0:000> dumpsig 0x000007fe`eb7fd8cd 0x000007fe`eabd1000
    [FIELD] ValueClass System.RuntimeTypeHandle 

Using DumpSigElem we can find the type of the field by adding the offset of it (1) to 
the address of the signature:
    0:000> sos DumpSigElem 0x000007fe`eb7fd8cd+1 0x000007fe`eabd1000
    ValueClass System.RuntimeTypeHandle

DumpSigElem will also work with generics.  Let a function be defined as follows:
    public A Test(IEnumerable<B> n)

The elements of this signature can be obtained by adding offsets into the signature
when calling DumpSigElem:

    0:000> sos DumpSigElem 00000000`00bc2437+2 000007ff00043178 
    __Canon
    0:000> sos DumpSigElem 00000000`00bc2437+4 000007ff00043178 
    Class System.Collections.Generic.IEnumerable`1<__Canon>

The actual offsets that you should add are determined by the contents of the
signature itself.  By trial and error you should be able to find various elements
of the signature.
\\

COMMAND: dumpil.
DumpIL <Managed DynamicMethod object> | 
       <DynamicMethodDesc pointer> |
       <MethodDesc pointer> |
       -i <IL pointer>

DumpIL prints the IL code associated with a managed method. We added this
function specifically to debug DynamicMethod code which was constructed on
the fly. Happily it works for non-dynamic code as well.

You can use it in four ways: 

  1) If you have a System.Reflection.Emit.DynamicMethod object, just pass
     the pointer as the first argument. 
  2) If you have a DynamicMethodDesc pointer you can use that to print the
     IL associated with the dynamic method.
  3) If you have an ordinary MethodDesc, you can see the IL for that as well,
     just pass it as the first argument.
  4) If you have a pointer directly to the IL, specify -i followed by the
     the IL address.  This is useful for writers of profilers that instrument
     IL.
     

Note that dynamic IL is constructed a bit differently. Rather than referring
to metadata tokens, the IL points to objects in a managed object array. Here
is a simple example of the output for a dynamic method:

  0:000> sos DumpIL b741dc
  This is dynamic IL. Exception info is not reported at this time.
  If a token is unresolved, run "sos DumpObj <addr>" on the addr given
  in parenthesis. You can also look at the token table yourself, by
  running "DumpArray 00b77388".

  IL_0000: ldstr 70000002 "Inside invoked method "
  IL_0005: call 6000003 System.Console.WriteLine(System.String)
  IL_000a: ldc.i4.1
  IL_000b: newarr 2000004 "System.Int32"
  IL_0010: stloc.0
  IL_0011: ldloc.0
  IL_0012: ret

\\

COMMAND: verifyheap.
VerifyHeap

VerifyHeap is a diagnostic tool that checks the garbage collected heap for 
signs of corruption. It walks objects one by one in a pattern like this:

    o = firstobject;
    while(o != endobject)
    {
        o.ValidateAllFields();
        o = (Object *) o + o.Size();
    }

If an error is found, VerifyHeap will report it. I'll take a perfectly good 
object and corrupt it:

    (lldb) dumpobj a79d40
    Name: Customer
    MethodTable: 009038ec
    EEClass: 03ee1b84
    Size: 20(0x14) bytes
     (/home/user/pub/unittest)
    Fields:
          MT    Field   Offset                 Type       Attr    Value Name
    009038ec  4000008        4                CLASS   instance 00a79ce4 name
    009038ec  4000009        8                CLASS   instance 00a79d2c bank
    009038ec  400000a        c       System.Boolean   instance        1 valid

    (lldb) ed a79d40+4 01  (change the name field to the bogus pointer value 1)
    (lldb) sos VerifyHeap
    object 01ee60dc: bad member 00000003 at 01EE6168
    Last good object: 01EE60C4.

If this gc heap corruption exists, there is a serious bug in your own code or 
in the CLR. In user code, an error in constructing PInvoke calls can cause 
this problem, and running with Managed Debugging Assistants is advised. If that
possibility is eliminated, consider contacting Microsoft Product Support for
help.

\\

COMMAND: verifyobj.
VerifyObj <object address>

VerifyObj is a diagnostic tool that checks the object that is passed as an 
argument for signs of corruption.

    0:002> verifyobj 028000ec
    object 0x28000ec does not have valid method table

    0:002> verifyobj 0680017c 
    object 0x680017c: bad member 00000001 at 06800184

\\

COMMAND: findroots.
FindRoots -gen <N> | -gen any | <object address>

The "-gen" form causes the debugger to break in the debuggee on the next 
collection of the specified generation.  The effect is reset as soon as the 
break occurs, in other words, if you need to break on the next collection you 
would need to reissue the command.

The last form of this command is meant to be used after the break caused by the 
other forms has occurred.  Now the debuggee is in the right state for 
findroots to be able to identify roots for objects from the current condemned 
generations.

FindRoots is a diagnostic command that is meant to answer the following 
question:

"I see that GCs are happening, however my objects have still not been 
collected. Why? Who is holding onto them?"

The process of answering the question would go something like this:

1. Find out the generation of the object of interest using the gcwhere 
command, say it is gen 1:
    (lldb) gcwhere <object address>

2. Instruct the runtime to stop the next time it collects that generation using 
the findroots command:
    findroots -gen 1
    g

3. When the next GC starts, and has proceeded past the mark phase a CLR 
notification will cause a break in the debugger:
    (fd0.ec4): CLR notification exception - code e0444143 (first chance)
    CLR notification: GC - end of mark phase.
        Condemned generation: 1.

4. Now we can use the findroots <object address> to find out the cross 
generational references to the object of interest.  In other words, even if the 
object is not referenced by any "proper" root it may still be referenced by an 
older object (from an older generation), from a generation that has not yet been 
scheduled for collection.  At this point findroots will search those older 
generations too, and report those roots.
    (lldb) findroots 06808094 
    older generations::Root:  068012f8(AAA.Test+a)->
      06808094(AAA.Test+b)

\\

COMMAND: analyzeoom.
analyzeoom

AnalyzeOOM displays the info of the last OOM occurred on an allocation request to
the GC heap (in Server GC it displays OOM, if any, on each GC heap). 

To see the managed exception(s) use the clrthreads command which will show you 
managed exception(s), if any, on each managed thread. If you do see an 
OutOfMemoryException exception you can use the printexception command on it.
To get the full callstack use the "kb" command in the debugger for that thread.
For example, to display thread 3's stack use ~3kb.

OOM exceptions could be because of the following reasons:

1) allocation request to GC heap 
   in which case you will see JIT_New* on the call stack because managed code called new.
2) other runtime allocation failure
   for example, failure to expand the finalize queue when GC.ReRegisterForFinalize is
   called.
3) some other code you use throws a managed OOM exception 
   for example, some .NET framework code converts a native OOM exception to managed 
   and throws it.

The analyzeoom command aims to help you with investigating 1) which is the most
difficult because it requires some internal info from GC. The only exception is
we don't support allocating objects larger than 2GB on CLR v2.0 or prior. And this
command will not display any managed OOM because we will throw OOM right away 
instead of even trying to allocate it on the GC heap.

There are 2 legitimate scenarios where GC would return OOM to allocation requests - 
one is if the process is running out of VM space to reserve a segment; the other
is if the system is running out physical memory (+ page file if you have one) so
GC can not commit memory it needs. You can look at these scenarios by using performance
counters or debugger commands. For example for the former scenario the "!address 
-summary" debugger command will show you the largest free region in the VM. For
the latter scenario you can look at the "Memory% Committed Bytes In Use" see
if you are running low on commit space. One important thing to keep in mind is
when you do this kind of memory analysis it could an aftereffect and doesn't 
completely agree with what this command tells you, in which case the command should
be respected because it truly reflects what happened during GC.

The other cases should be fairly obvious from the callstack.

Sample output:

0:011> analyzeoom
---------Heap 2 ---------
Managed OOM occurred after GC #28 (Requested to allocate 1234 bytes)
Reason: Didn't have enough memory to commit
Detail: SOH: Didn't have enough memory to grow the internal GC datastructures (800000 bytes) - 
        on GC entry available commit space was 500 MB
---------Heap 4 ---------
Managed OOM occurred after GC #12 (Requested to allocate 100000 bytes)
Reason: Didn't have enough memory to allocate an LOH segment
Detail: LOH: Failed to reserve memory (16777216 bytes)

\\

COMMAND: gcwhere.
GCWhere <object address>

GCWhere displays the location in the GC heap of the argument passed in.

    0:002> sos GCWhere 02800038  
    Address  Gen Heap segment  begin    allocated size
    02800038 2    0   02800000 02800038 0282b740  12

When the argument lies in the managed heap, but is not a valid *object* address 
the "size" is displayed as 0:

    0:002> sos GCWhere 0280003c
    Address  Gen Heap segment  begin    allocated size
    0280003c 2    0   02800000 02800038 0282b740  0
\\

COMMAND: listnearobj.
ListNearObj <object address>

ListNearObj is a diagnostic tool that displays the object preceeding and 
succeeding the address passed in:

The command looks for the address in the GC heap that looks like a valid 
beginning of a managed object (based on a valid method table) and the object 
following the argument address.

    0:002> listnearobj 028000ec
    Before: 0x28000a4           72 (0x48      ) System.StackOverflowException
    After:  0x2800134           72 (0x48      ) System.Threading.ThreadAbortException
    Heap local consistency confirmed.

    0:002> listnearobj 028000f0
    Before: 0x28000ec           72 (0x48      ) System.ExecutionEngineException
    After:  0x2800134           72 (0x48      ) System.Threading.ThreadAbortException
    Heap local consistency confirmed.

The command considers the heap as "locally consistent" if:
    prev_obj_addr + prev_obj_size = arg_addr && arg_obj + arg_size = next_obj_addr
OR
    prev_obj_addr + prev_obj_size = next_obj_addr

When the condition is not satisfied:

    0:002> listnearobj 028000ec
    Before: 0x28000a4           72 (0x48      ) System.StackOverflowException
    After:  0x2800134           72 (0x48      ) System.Threading.ThreadAbortException
    Heap local consistency not confirmed.

\\

COMMAND: dumplog.
DumpLog [-addr <addressOfStressLog>] [<Filename>]

To aid in diagnosing hard-to-reproduce stress failures, the CLR team added an 
in-memory log capability. The idea was to avoid using locks or I/O which could 
disturb a fragile repro environment. The DumpLog function allows you to write 
that log out to a file. If no Filename is specified, the file "Stresslog.txt" 
in the current directory is created.

The optional argument addr allows one to specify a stress log other then the 
default one.

    (lldb) dumplog
    Attempting to dump Stress log to file 'StressLog.txt'
    .................
    SUCCESS: Stress log dumped

To turn on the stress log, set the following environment variables before
starting the .NET Core app:

export DOTNET_StressLog = 1
export DOTNET_LogFacility = 0xffffffbf (This is a bit mask, almost all logging is on.
                                        This is also the default value if the key
                                        isn't specified)
export DOTNET_StressLogSize = 65536 (This is the default value if the key isn't
                                     specified)
export DOTNET_LogLevel = 6 (This is the default value if the key isn't
                            specified. The higher the number the more
                            detailed logs are generated. The maximum
                            value is decimal 10)

StressLogSize is the size in bytes of the in-memory log allocated for each 
thread in the process. In the case above, each thread gets a 64K log. You 
could increase this to get more logging, but more memory will be required for 
this log in the process. For example, 20 threads with 524288 bytes per thread 
has a memory demand of 10 Megabytes. The stress log is circular so new entries 
will replace older ones on threads which have reached their buffer limit.

The log facilities are defined as follows:
    GC           0x00000001
    GCINFO       0x00000002
    STUBS        0x00000004
    JIT          0x00000008
    LOADER       0x00000010
    METADATA     0x00000020
    SYNC         0x00000040
    EEMEM        0x00000080
    GCALLOC      0x00000100
    CORDB        0x00000200
    CLASSLOADER  0x00000400
    CORPROF      0x00000800
    REMOTING     0x00001000
    DBGALLOC     0x00002000
    EH           0x00004000
    ENC          0x00008000
    ASSERT       0x00010000
    VERIFIER     0x00020000
    THREADPOOL   0x00040000
    GCROOTS      0x00080000
    INTEROP      0x00100000
    MARSHALER    0x00200000
    IJW          0x00400000
    ZAP          0x00800000
    STARTUP      0x01000000
    APPDOMAIN    0x02000000
    CODESHARING  0x04000000
    STORE        0x08000000
    SECURITY     0x10000000
    LOCKS        0x20000000
    BCL          0x40000000

Here is some sample output:

    3560   9.981137099 : `SYNC`               RareEnablePremptiveGC: entering. 
    Thread state = a030

    3560   9.981135033 : `GC`GCALLOC`GCROOTS` ========== ENDGC 4194 (gen = 2, 
    collect_classes = 0) ==========={

    3560   9.981125826 : `GC`                         Segment mem 00C61000 alloc 
    = 00D071F0 used 00D09254 committed 00D17000

    3560   9.981125726 : `GC`                     Generation 0 [00CED07C, 00000000
    ] cur = 00000000

    3560   9.981125529 : `GC`                     Generation 1 [00CED070, 00000000
    ] cur = 00000000

    3560   9.981125103 : `GC`                     Generation 2 [00C61000, 00000000
    ] cur = 00000000

    3560   9.981124963 : `GC`                 GC Heap 00000000

    3560   9.980618994 : `GC`GCROOTS`         GcScanHandles (Promotion Phase = 0)

The first column is the OS thread ID for the thread appending to the log, 
the second column is the timestamp, the third is the facility category for the 
log entry, and the fourth contains the log message. The facility field is 
expressed as `facility1`facility2`facility3`.  This facilitates the creation of 
filters for displaying only specific message categories.  To make sense of this 
log, you would probably want the Shared Source CLI to find out exactly where 
the log comes from.
\\

COMMAND: findappdomain.
FindAppDomain <Object address>

FindAppDomain will attempt to resolve the AppDomain of an object. For example,
using an Object Pointer from the output of DumpStackObjects:

    (lldb) sos FindAppDomain 00a79d98
    AppDomain: 0014f000
    Name: unittest.exe
    ID: 1

You can find out more about the AppDomain with the DumpDomain command. Not 
every object has enough clues about it's origin to determine the AppDomain. 
Objects with Finalizers are the easiest case, as the CLR needs to be able to 
call those when an AppDomain shuts down.
\\

COMMAND: gchandles.
GCHandles [-type handletype] [-stat] [-perdomain]

GCHandles provides statistics about GCHandles in the process.

Paremeters:
    stat - Only display the statistics and not the list of handles and
           what they point to.
    perdomain - Break down the statistics by the app domain in which
                the handles reside.
    type - A type of handle to filter it by.  The handle types are:
           Pinned
           RefCounted
           WeakShort
           WeakLong
           Strong
           Variable
           AsyncPinned
           SizedRef

Sometimes the  source of a memory leak is a GCHandle leak. For example, code
might keep a 50 Megabyte array alive because a strong GCHandle points to it,
and the handle was discarded without freeing it.

The most common handles are "Strong Handles," which keep the object they point 
to alive until the handle is explicitly freed. "Pinned Handles" are used to 
prevent the garbage collector from moving an object during collection. These 
should be used sparingly, and for short periods of time. If you don't follow 
that precept, the gc heap can become very fragmented.

Here is sample output from a very simple program.  Note that the "RefCount"
field only applies to RefCount Handles, and this field will contain the
reference count:

    0:000> gchandles
      Handle Type          Object     Size RefCount Type
    001611c0 Strong      01d00b58       84          System.IndexOutOfRangeException
    001611c4 Strong      01d00b58       84          System.IndexOutOfRangeException
    001611c8 Strong      01d1b48c       40          System.Diagnostics.LogSwitch
    001611d0 Strong      01cfd2c0       36          System.Security.PermissionSet
    001611d4 Strong      01cf7484       56          System.Object[]
    001611d8 Strong      01cf1238       32          System.SharedStatics
    001611dc Strong      01cf11c8       84          System.Threading.ThreadAbortException
    001611e0 Strong      01cf1174       84          System.Threading.ThreadAbortException
    001611e4 Strong      01cf1120       84          System.ExecutionEngineException
    001611e8 Strong      01cf10cc       84          System.StackOverflowException
    001611ec Strong      01cf1078       84          System.OutOfMemoryException
    001611f0 Strong      01cf1024       84          System.Exception
    001611f8 Strong      01cf2068       48          System.Threading.Thread
    001611fc Strong      01cf1328      112          System.AppDomain
    001613ec Pinned      02cf3268     8176          System.Object[]
    001613f0 Pinned      02cf2258     4096          System.Object[]
    001613f4 Pinned      02cf2038      528          System.Object[]
    001613f8 Pinned      01cf121c       12          System.Object
    001613fc Pinned      02cf1010     4116          System.Object[]

    Statistics:
          MT    Count    TotalSize Class Name
    563266dc        1           12 System.Object
    56329708        1           32 System.SharedStatics
    5632bc38        1           36 System.Security.PermissionSet
    5635f934        1           40 System.Diagnostics.LogSwitch
    5632759c        1           48 System.Threading.Thread
    5632735c        1           84 System.ExecutionEngineException
    56327304        1           84 System.StackOverflowException
    563272ac        1           84 System.OutOfMemoryException
    563270c4        1           84 System.Exception
    56328914        1          112 System.AppDomain
    56335f78        2          168 System.IndexOutOfRangeException
    563273b4        2          168 System.Threading.ThreadAbortException
    563208d0        5        16972 System.Object[]
    Total 19 objects

    Handles:
        Strong Handles:       14
        Pinned Handles:       5
\\

COMMAND: histinit.
HistInit

Before running any of the Hist - family commands you need to initialize the SOS 
structures from the stress log saved in the debuggee.  This is achieved by the 
HistInit command.

Sample output:

    (lldb) histinit
    Attempting to read Stress log
    STRESS LOG:
        facilitiesToLog  = 0xffffffff
        levelToLog       = 6
        MaxLogSizePerThread = 0x10000 (65536)
        MaxTotalLogSize = 0x1000000 (16777216)
        CurrentTotalLogChunk = 9
        ThreadsWithLogs  = 3
        Clock frequency  = 3.392 GHz
        Start time         15:26:31
        Last message time  15:26:56
        Total elapsed time 25.077 sec
    .....................................
    ---------------------------- 2407 total entries -----------------------------


    SUCCESS: GCHist structures initialized

\\

COMMAND: histobjfind.
HistObjFind <obj_address>

To examine log entries related to an object whose present address is known one 
would use this command. The output of this command contains all entries that 
reference the object:

    (lldb) histobjfind 028970d4 
     GCCount   Object                                  Message
    ---------------------------------------------------------
        2296 028970d4 Promotion for root 01e411b8 (MT = 5b6c5cd8)
        2296 028970d4 Relocation NEWVALUE for root 00223fc4
        2296 028970d4 Relocation NEWVALUE for root 01e411b8
    ...
        2295 028970d4 Promotion for root 01e411b8 (MT = 5b6c5cd8)
        2295 028970d4 Relocation NEWVALUE for root 00223fc4
        2295 028970d4 Relocation NEWVALUE for root 01e411b8
    ...

\\

COMMAND: histroot.
HistRoot <root>

The root value obtained from sos HistObjFind can be used to track the movement of 
an object through the GCs.

HistRoot provides information related to both promotions and relocations of the 
root specified as the argument.

    (lldb) histroot 01e411b8 
     GCCount    Value       MT Promoted?                Notes
    ---------------------------------------------------------
        2296 028970d4 5b6c5cd8       yes 
        2295 028970d4 5b6c5cd8       yes 
        2294 028970d4 5b6c5cd8       yes 
        2293 028970d4 5b6c5cd8       yes 
        2292 028970d4 5b6c5cd8       yes 
        2291 028970d4 5b6c5cd8       yes 
        2290 028970d4 5b6c5cd8       yes 
        2289 028970d4 5b6c5cd8       yes 
        2288 028970d4 5b6c5cd8       yes 
        2287 028970d4 5b6c5cd8       yes 
        2286 028970d4 5b6c5cd8       yes 
        2285 028970d4 5b6c5cd8       yes 
         322 028970e8 5b6c5cd8       yes Duplicate promote/relocs
    ...

\\

COMMAND: histobj.
HistObj <obj_address>

This command examines all stress log relocation records and displays the chain 
of GC relocations that may have led to the address passed in as an argument.
Conceptually the output is:

        GenN    obj_address   root1, root2, root3,
        GenN-1  prev_obj_addr root1, root2,
        GenN-2  prev_prev_oa  root1, root4, 
        ...

Sample output:
    (lldb) histobj 028970d4 
     GCCount   Object                                    Roots
    ---------------------------------------------------------
        2296 028970d4 00223fc4, 01e411b8, 
        2295 028970d4 00223fc4, 01e411b8, 
        2294 028970d4 00223fc4, 01e411b8, 
        2293 028970d4 00223fc4, 01e411b8, 
        2292 028970d4 00223fc4, 01e411b8, 
        2291 028970d4 00223fc4, 01e411b8, 
        2290 028970d4 00223fc4, 01e411b8, 
        2289 028970d4 00223fc4, 01e411b8, 
        2288 028970d4 00223fc4, 01e411b8, 
        2287 028970d4 00223fc4, 01e411b8, 
        2286 028970d4 00223fc4, 01e411b8, 
        2285 028970d4 00223fc4, 01e411b8, 
         322 028970d4 01e411b8, 
           0 028970d4 

\\

COMMAND: histclear.
HistClear

This command releases any resources used by the Hist-family of commands. 
Generally there's no need to call this explicitly, as each HistInit will first 
cleanup the previous resources.

    (lldb) histclear
    Completed successfully.
\\

COMMAND: sethostruntime.
SetHostRuntime [-c][-netcore] [-none] [-clear] <runtime-directory>

-c, -netcore - switch to hosting on the .NET Core runtime
-none        - disable hosting managed code (for testing).
-clear       - clear the .NET Core host runtime path.

This command sets the path to the .NET Core runtime to use to host the managed 
code that runs as part of SOS in the debugger (lldb). The runtime needs
to be at least version 2.1.0 or greater. If there are spaces in directory, it
needs to be single-quoted (').

Normally, SOS attempts to find an installed .NET Core runtime to run its
managed code automatically but this command is available if it fails. The
default is to use the same runtime (libcoreclr) being debugged. Use this
command if the default runtime being debugged isn't working enough to run
the SOS code or if the version is less than 2.1.0.

If you received the following error message when running a SOS command, use
this command to set the path to 2.1.0 or greater .NET Core runtime.

    (lldb) clrstack
    Error: Fail to initialize CoreCLR 80004005
    ClrStack  failed

    (lldb) sethostruntime /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.6

You can use the "dotnet --info" in a command shell to find the path of an installed
.NET Core runtime.
\\

COMMAND: sosstatus.
SOSStatus [-reset]

-reset - reset all the cached internal SOS state.

Displays internal SOS status or resets the internal cached state.
\\

COMMAND: sosflush.
sosflush

Resets the internal cached state.
\\

COMMAND: setclrpath.
setclrpath <path-to-runtime>

Sets the path to load the runtime DAC/DBI files. This command may be necessary for dumps that were created
on another machine or for triage dumps.

    (lldb) setclrpath /home/user/coreclr/bin/Product/Linux.x64.Debug
\\

COMMAND: runtimes.
runtimes

List the .NET runtimes in the target process.
\\

