+++ /dev/null
--------------------------------------------------------------------------------
-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)
-DumpArray ThreadState
-DumpStackObjects (dso) IP2MD (ip2md)
-DumpHeap (dumpheap) u (clru)
-DumpVC DumpStack (dumpstack)
-GCRoot (gcroot) EEStack (eestack)
-PrintException (pe) ClrStack (clrstack)
- GCInfo
- EHInfo
- bpmd (bpmd)
-
-Examining CLR data structures Diagnostic Utilities
------------------------------ -----------------------------
-DumpDomain VerifyHeap
-EEHeap (eeheap) FindAppDomain
-Name2EE (name2ee) DumpLog (dumplog)
-DumpMT (dumpmt)
-DumpClass (dumpclass)
-DumpMD (dumpmd)
-Token2EE
-DumpModule (dumpmodule)
-DumpAssembly
-DumpRuntimeTypes
-DumpIL (dumpil)
-DumpSig
-DumpSigElem
-
-Examining the GC history Other
------------------------------ -----------------------------
-HistInit (histinit) FAQ
-HistRoot (histroot) CreateDump (createdump)
-HistObj (histobj) Help (soshelp)
-HistObjFind (histobjfind)
-HistClear (histclear)
-\\
-
-COMMAND: faq.
->> Where can I get the right version of SOS for my build?
-
-If you are running a xplat version of coreclr, the sos module (exact name
-is platform dependent) is installed in the same directory as the main coreclr
-module. There is also an lldb sos plugin command that allows the path where
-the sos, dac and dbi modules are loaded:
-
- "setsospath /home/user/coreclr/bin/Product/Linux.x64.Debug""
-
-If you are using a dump file created on another machine, it is a little bit
-more complex. You need to make sure the dac module that came with that install
-is in the directory set with the above command.
-
->> I have a chicken and egg problem. I want to use SOS commands, but the CLR
- isn't loaded yet. What can I do?
-
-TBD
-
->> 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: 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: 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
--max Ignore objects larger than the size given in bytes
--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] <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 freachable 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 freachable
-objects, there is a -nostacks option.
-\\
-
-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: 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.
-
-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]
-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.
-
-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.
-createdump [options] [dumpFileName]
--n - create minidump.
--h - create minidump with heap (default).
--t - create triage minidump.
--f - create full core dump (everything).
--d - enable diagnostic messages.
-
-Creates a platform (ELF core on Linux, etc.) minidump. The pid can be placed in the dump
-file name with %d. The default is '/tmp/coredump.%d'.
-\\
-
-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
- Transparency: Critical
-
-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
- Transparency: Critical
-
- 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 Windows 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.
-
-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) Stop after coreclr is loaded - TBD
-
- 2) Add the breakpoint with command such as:
- bpmd myapp.exe MyApp.Main
- 3) g
- 4) 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.exe 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 breapoints on G3.F() and
- G1.G():
-
- bpmd myapp.exe G3`3.F
- bpmd myapp.exe 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.exe 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.exe 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 seperate 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: 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: 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: 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 registry keys under
-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework:
-
-
-(DWORD) StressLog = 1
-(DWORD) LogFacility = 0xffffffbf (this is a bit mask, almost all logging is on.
- This is also the default value if the key
- isn't specified)
-(DWORD) StressLogSize = 65536 (this is the default value if the key isn't
- specified)
-(DWORD) 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: 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 !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.
-
-\\
projects / platform / upstream / dotnet / runtime.git / commitdiff