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.

http://www.microsoft.com/en-us/download/details.aspx?id=7029

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.

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…

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.

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

….

#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.

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.

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)

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"