May 022013
 

Thought I will share some interesting differences between a .net class and a struct.

Class Struct
Allocated on the heap. Allocated on the stack. They are value types and don’t require heap allocation.
A variable of a class type stores a reference to a dynamically allocated object. A variable of a struct type directly stores the data of the struct.
Supports user-specified inheritance. Does not support user-specified inheritance and all struct types implicitly inherit from type object.
An array of, class Point instances of, size 100 implies 101 separate objects are instantiated. One for the array and one each for the 100 elements. An array, of struct Point instances, of size 100 implies only one object i.e. the array is instantiated and the struct Point instances are stored inline in the array.
Dynamic allocation done via ‘new’ call. Struct constructors are invoked with the new operator but that does not imply that memory is being allocated. Instead of dynamically allocating an object and returning a reference to it, a struct constructor simply returns the struct value itself (typically in a temporary location on the stack), and this value is then copied as necessary.
With classes, it is possible for two variables to reference the same object and thus possible for operations on one variable to affect the object referenced by the other variable. With structs, the variables each have their own copy of the data, and it is not possible for operations on one to affect the other. For example, the output produced by the following code fragment depends on whether Point is a class or a struct.
Classes are kind of faster as only their references are copied around. Structs are copied by value unless we specify ref, out parameters hence the copying overhead is there.

 

Structs are particularly useful for small data structures that have value semantics. Complex numbers, points in a coordinate system, or key-value pairs in a dictionary are all good examples of structs. The use of structs rather than classes for small data structures can make a large difference in the number of memory allocations an application performs.

These differences are picked up from the C# 4.0 language specification.

Share
Apr 272013
 

Filename and line number information is stored inside private symbols (.pdb file). So if private symbols are available the debugger will try figuring out the line number information. Note: public symbols doesn’t have line number information.

So the question I’ve heard people new to windbg ask is how to turn off line number display. What’s the command for this. What I normally do is and the easiest of all is the ‘.lines’ command. This is a toggle command, next time you execute .lines, the command will turn ‘on’ line number information.

Another option is to use .symopt command:
http://msdn.microsoft.com/en-in/library/windows/hardware/ff558827(v=vs.85).aspx

The symbol option of interest to us is: SYMOPT_LOAD_LINES. Following is the MSDN description of this item.

This symbol option allows line number information to be read from source files. This option must be on for source debugging to work correctly.

In KD and CDB, this option is off by default; in WinDbg, this option is on by default. In CDB and KD, the -lines command-line option will turn this option on. Once the debugger is running, it can be turned on or off by using .symopt+0×10 or .symopt-0×10, respectively. It can also be toggled on and off by using the .lines (Toggle Source Line Support) command.

This option is on by default in DBH. Once DBH is running, it can be turned on or off by using symopt +10 or symopt -10, respectively.

Share
Apr 272013
 

Non-Invasive debugging is a useful technique to debug hung processes. The debugger suspends all threads in the process and has access to all threads, memory and register’s of the process.

To do non-invasive debugging via windbg/cdb check this link out:
http://msdn.microsoft.com/en-in/library/windows/hardware/ff552274(v=vs.85).aspx

To do this via WinDbg UI, press F6 or File->Attach to a Process…

image

While non-invasive debugging is in progress we also can have another instance of the debugger attached to the same process. This proves that for non-invasive debugging the debugger is not attached to the process reason being by default on Windows only one debugger can be attached at any time to a process. Also while debugging non-invasively common windbg commands like ‘g’ won’t work because we don’t have a debugger to the process  which can instruct the process to resume execution.

As written already: for non-invasive debugging the debugger suspends all the threads in the process so this also means that we can resume execution of these threads too. The command to do this is as follows…

0:000> ~*m

~m resumes a thread while ~n suspends a thread. If we don’t resume the threads we won’t see the process UI as the UI thread is also in a suspended state.

Now with two debuggers monitoring the process we can view the process’ memory via the non-invasive debugger as well. For e.g. when you set a breakpoint via the second debugger  (attached invasively) its interesting to see how the function code is modified by the debugger to get the breakpoint to work, see below e.g.

We’ve set a breakpoint on ntdll!ntopenfile. This is how the code looks when broken into by the debugger…

0:001> uf ntdll!ntopenfile
ntdll!ZwOpenFile:
000007f9`25972f10 4c8bd1          mov     r10,rcx           <<<<—- This three byte instruction is replaced, see below
000007f9`25972f13 b831000000      mov     eax,31h
000007f9`25972f18 0f05            syscall
000007f9`25972f1a c3              ret

But during execution of the process (after setting breakpoint) and checking the assembler code via non-invasive debugger we see something different…

0:000> uf ntdll!ntopenfile
ntdll!ZwOpenFile:
000007f9`25972f10 cc              int     3  <<<<——- Single byte instruction cc, and followed by
000007f9`25972f11 8bd1         mov     edx,ecx <<— 8bd1: remaining two bytes of the above three bytes instruction
000007f9`25972f13 b831000000      mov     eax,31h
000007f9`25972f18 0f05            syscall
000007f9`25972f1a c3              ret

In effect the original three byte instruction (4c8bd1) is replaced by (cc8bd1). The only change: 4c –> cc. cc evaluates to int 3. When the breakpoint is hit (or when we press Ctrl + Break) the breakpoint instruction is replaced by original op code i.e. 4c8bd1.

We could figure this out via the non-Invasive debugger. If a process is hung we can in effect go through the call stacks and find out potential hang scenarios, for e.g. a process waiting on a network drive.

Share
Jan 092013
 

This hidden Visual C++ compiler switch will print out the full path of files included via #includes. You add this option likewise…

image

Sample output…

1>  Note: including file:  C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxwin.h
1>  Note: including file:   C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afx.h
1>  Note: including file:    C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\new.h
1>  Note: including file:     C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\crtdefs.h
1>  Note: including file:      C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\sal.h

….

Share
Apr 102012
 

kf is a useful command to find out stack memory taken by a frame. See below…
I have three functions which looks like this…

#pragma auto_inline(off)
void TestStack2()
{
       printf("hello");
       return;
}
void TestStack1()
{
       TestStack2();
       char bytes[0x190] = {9};
       printf("hello: %s", bytes);
}
void TestStack()
{
       TestStack1();
       char bytes[0x90] = {9};
       printf("hello: %s", bytes);
}

// Check out the frame sizes…
  Memory  ChildEBP RetAddr 
          0024f000 00291578 TestMFC1!TestStack2+0×5
      19c 0024f19c 002915d8 TestMFC1!TestStack1+0×18
       9c 0024f238 002916ea TestMFC1!TestStack+0×18
       28 0024f260 7856f282 TestMFC1!CTestMFC1Dlg::OnInitDialog+0xca
        8 0024f268 752c62fa mfc100!AfxDlgProc+0×31
       2c 0024f294 752ef9df USER32!InternalCallWinProc+0×23
       7c 0024f310 752ef784 USER32!UserCallDlgProcCheckWow+0xd7
       <snip…>

Alternatively we can take difference of child ebp and current esp to know frame size.

Share
Mar 062012
 

Sometimes we could have a dump which does not load .pdb files even though they are present in the dump folder. The reason for the load failure is not necessarily every time a code change but could be just a rebuild of the source code. In such cases if you force load the .pdb file you should get a call stack that makes sense but you got to be good at API’s and libraries to make sure the stack makes sense. So until you get a proper .pdb file you can force load a .pdb file and work on the dump.
——————————————————-
Remember: Always insist on correct pdb file.
——————————————————-
So the command to enable this feature is: ‘.symopt’. Lists out the current symbol loading options. On my machine this is what I get…

0:000> .symopt
Symbol options are 0×30377:
0×00000001 – SYMOPT_CASE_INSENSITIVE
0×00000002 – SYMOPT_UNDNAME
0×00000004 – SYMOPT_DEFERRED_LOADS
0×00000010 – SYMOPT_LOAD_LINES
0×00000020 – SYMOPT_OMAP_FIND_NEAREST
0×00000100 – SYMOPT_NO_UNQUALIFIED_LOADS
0×00000200 – SYMOPT_FAIL_CRITICAL_ERRORS
0×00010000 – SYMOPT_AUTO_PUBLICS
0×00020000 – SYMOPT_NO_IMAGE_SEARCH

These flags determine how and what symbols will be loaded. These options also determine whether line number information should be loaded or not.

So in our debugging scenario if we want to load symbols in a loose manner, i.e., without strict mapping of .pdb with .exe we will have to enable the following option…

0×00000040 – SYMOPT_LOAD_ANYTHING 

In windbg we do this via…

0:000> .symopt+ 0×40
Symbol options are 0×30377:
0×00000001 – SYMOPT_CASE_INSENSITIVE
0×00000002 – SYMOPT_UNDNAME
0×00000004 – SYMOPT_DEFERRED_LOADS
0×00000010 – SYMOPT_LOAD_LINES
0×00000020 – SYMOPT_OMAP_FIND_NEAREST
0×00000040 – SYMOPT_LOAD_ANYTHING <———– Prevents validation of .pdb file
0×00000100 – SYMOPT_NO_UNQUALIFIED_LOADS
0×00000200 – SYMOPT_FAIL_CRITICAL_ERRORS
0×00010000 – SYMOPT_AUTO_PUBLICS
0×00020000 – SYMOPT_NO_IMAGE_SEARCH

To re-enable strict mapping between .exe and .pdb use

0:000> .symopt- 0×40
Symbol options are 0×30377:
0×00000001 – SYMOPT_CASE_INSENSITIVE
0×00000002 – SYMOPT_UNDNAME
0×00000004 – SYMOPT_DEFERRED_LOADS
0×00000010 – SYMOPT_LOAD_LINES
0×00000020 – SYMOPT_OMAP_FIND_NEAREST
0×00000100 – SYMOPT_NO_UNQUALIFIED_LOADS
0×00000200 – SYMOPT_FAIL_CRITICAL_ERRORS
0×00010000 – SYMOPT_AUTO_PUBLICS
0×00020000 – SYMOPT_NO_IMAGE_SEARCH

Note the +/- in the above command. ‘+’ enables, ‘-’ disables.

Share
Feb 272012
 

Use ‘lml’ to list all dlls whose symbols has been loaded/failed to load, the list will also include dlls which failed symbol loading. See sample…

0:000> lml
start end module name
00000000`03d90000 00000000`040e3000 Test1 T (no symbols
00000000`77d40000 00000000`77eb3000 kernel32 (private pdb symbols) c:\sym\kernel32.pdb\F0EC676938D745549823C7204D03B07B2\kernel32.pdb
00000000`77ec0000 00000000`77ffc000 ntdll (private pdb symbols) c:\sym\ntdll.pdb\C5666A2C21444EFAA53EB4F1CFBE56D22\ntdll.pdb
00000001`55600000 00000001`55801000 Test2 (export symbols) Test2.dll
00000001`80000000 00000001`806c2000 Test3 T (no symbols
000007ff`57040000 000007ff`57071000 iphlpapi (private pdb symbols) c:\sym\iphlpapi.pdb\487BEF7A066A4E5DB7C0230E9B8564CA2\iphlpapi.pdb
000007ff`57140000 000007ff`573c5000 ole32 (private pdb symbols) c:\sym\ole32.pdb\7DDC15A822B0415CAD8C3BC2BF86C3082\ole32.pdb
000007ff`77310000 000007ff`77340000 ws2_32 (private pdb symbols) c:\sym\ws2_32.pdb\89321AB9C6CD443FB74F07BA57B507452\ws2_32.pdb
000007ff`7fd30000 000007ff`7fed0000 rpcrt4 (private pdb symbols) c:\sym\rpcrt4.pdb\8852BC6255D84F43A64A5FA4BE7D74162\rpcrt4.pdb

I’ve highlighted the dlls which failed symbol loading.

Use ‘lme’ if you want to list only those dlls which failed symbol loading. See sample…
0:000> lme
start end module name
00000000`03d90000 00000000`040e3000 Test1 T (no symbols
00000001`55600000 00000001`55801000 Test2 (export symbols) Test2.dll
00000001`80000000 00000001`806c2000 Test3 T (no symbols)

Share
Feb 242012
 

-> Please note for demo purpose we are using current thread stack range as address range: poi(@$teb+8) poi(@$teb+4) <-

Search for an ascii string beginning with "Rtl"
s -a poi(@$teb+8) poi(@$teb+4) "Rtl"
//Output
0fd3d906 52 74 6c 47 65 74 50 72-6f 64 75 63 74 49 6e 66 RtlGetProductInf

Search for a unicode string "AgentService"
s -u poi(@$teb+8) poi(@$teb+4) "AgentService"
//Output
0fd3ed7c 0041 0067 0065 006e 0074 0053 0065 0072 A.g.e.n.t.S.e.r.
0fd3edec 0041 0067 0065 006e 0074 0053 0065 0072 A.g.e.n.t.S.e.r.


Display all ascii strings which are at least 8 in length

s -[l8]sa poi(@$teb+8) poi(@$teb+4)
// Output
0fd3d0d4 "mscorlib.pdb"
0fd3d906 "RtlGetProductInfo"


Display all unicode strings which are at least 58 in length

s -[l58]su poi(@$teb+8) poi(@$teb+4)
// Output
0fd3bc08 "謬矐뻬࿓ilC:\Windows\WinSxS\x86_micr"
0fd3bc48 "osoft.vc80.crt_1fc8b3b9a1e18e3b_"
0fd3bc88 "8.0.50727.6195_none_d09154e04427"
0fd3bcc8 "2b9a"

Share