bcircle-alfresco-installer

------------------------------------------------------------------------------- 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 : IT1 { ... void IT1.M1(U u) // this method's name is 'IT1.M1' { ... } } bpmd bpmd.exe ExplicitItfImpl`1.IT1.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.M1 (note that the fully qualified type name for ExplicitItfImpl became Outer+ExplicitItfImpl, using the '+' separator, while the method name is Outer.IT1.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.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