1. Turn on source mode in the UI or by running the .lines command
2. Choose the function you are interested in
3. Run the following command for that function
• X module!function
4. The first part of the output for this will be the memory address for the function, e.g.
• kd> x nt!IofCallDriver
• 82842ee0 nt!IofCallDriver
5. From the Edit menu, choose “Go To Address” and enter the address highlighted above.

If everything is setup correctly, the source for the target function will open.

From the Start Menu -> Administrative Tools -> Server Manager, install the following roles and features…

Roles:

• Add the Hyper-V role
• Add the “Windows Search Service” role under “File Services” - this will enable fast search through explorer / mail items / etc.

Features:

• Add “Wireless LAN service” – without this, you will not be able to connect through your wireless network adapter.
• Add the “Desktop Experience”
• Add the “.NET Framework 3.5.1 features”
• Add the “Quality Windows Audio Video Experience”
• Add the “XPS Viewer” (if needed)
• Add “Bitlocker Drive Encryption” (if needed)

Click on the root Server Manager node in the Server Manager tree view:

Disable the IE Enhanced Security Configuration (optional - do this at your own risk)

One of the drawbacks of having a Hyper-V server on your laptop is you lose the ability to put the machine into the ‘sleep’ low power state. This is specifically due to the hypervisor, not Windows Server 2008 R2 so if you opt to boot without the hypervisor, this state becomes available to you again. You can use the BCDEdit boot utility to setup a boot option enabling you to start the machine without the hypervisor so that you can specifically choose to boot into the hypervisor when you need Hyper-V functionality:

BCDEdit:

• Start a command window as administrator
• Clone your existing BCD boot settings so you can boot into either configuration <bcdedit /copy {current} /d "Hyper-V Off">
• You will get output similar to the following: “The entry was successfully copied to {0e448378-857f-11e0-b3b3-d8d3859a8e19}” <copy the highlighted section>
• Enter the following command: <BCDEdit –set {0e448378-857f-11e0-b3b3-d8d3859a8e19} hypervisorlaunchtype off> using the GUID you copied from the last step

Power Settings:

• Go into your laptop power settings and make sure sleep enabled in power settings. You can access power settings by right clicking the battery icon on the right side of your taskbar.

Note: The sleep option may not show up on start menu, but will react to hardware power settings. So if you configure your machine to sleep when the power button is pressed in your power plan (configured in Power Options) this will work.

Turn on Aero Glass:

• From the start menu -> Administrative Tools -> Services, scroll down to the ‘themes’ service, right click on it and choose properties. Start the service and set the startup type to ‘automatic’
• Right click on the desktop and choose ‘Personalize’. Select an Aero Theme (probably Windows 7).
• From the start menu, right click on “Computer” and choose “Properties”. From the “System Properties” dialog, choose the “Advanced” tab. Click “Settings” from the Performance section. In the “Visual Effects” tab, change to “Adjust for best appearance”.

Change Performance Settings to match the client version:

• From the start menu, right click on “Computer” and choose “Properties”. From the “System Properties” dialog, choose the “Advanced” tab. Click “Settings” from the Performance section. In the “Advanced” tab, change ‘Adjust for best performance of:’ setting to “Programs”

Another annoying thing about running Server on a laptop is that every time you shutdown the computer, the system pops up a dialog demanding that you tell it why you are shutting it down. Take the following steps to turn this behavior off:

• From the Start Menu, type “gpedit.msc” in the search box and hit enter.
• In the Local Group Policy Editor tree view go to Computer Configuration->Administrative Templates->System node. Scroll through the settings in the left pane to find the “Display Shutdown Event Tracker” setting. Double click on this and change it to “disabled”.

I believe that at this point your Server 2008 R2 machine will be as close to a Windows 7 Client as possible. If there are any tricks that I missed, please let me know and I will add them.

There are two different syntaxes available in Windbg, MASM (assembler) and C++. Several commands allow you to choose between these, reset the debugger default, etc. For a complete treatment, see Windbg help heading ‘Evaluating Expressions’. For our purposes, there are several key things to understand. The MASM syntax is the default, but you can specify the syntax you want for your command by using either @@c++(<commands>), or @@masm(<commands>). The @@(<commands>) symbol has the effect of switching from the current syntax to the alternate syntax. If you want to evaluate an expression using the C++ syntax, you specify ‘??’ as the evaluation command, for MASM use ‘?’. Each syntax has its own strengths and weaknesses. We will be looking at traversing structures which is one of the major strengths of the C++ syntax so we will primarily be using it in this post. As not everyone involved in kernel debugging is intimately familiar with C++, examples of using this syntax can be helpful.

In order to work through the following examples, you will need to have Windbg setup on your machine with public OS symbols working correctly. You will also need a sample OS kernel crash dump. The dump must contain the full kernel memory space so a “small kernel dump” will not work. Alternatively, you can connect to, and kernel debug, a target machine. These preliminary steps are outside the scope of this post, but there are lots of articles on the web and in Windbg help explaining how to do this. I used Windows 7 X86 to create and test the examples. Once you have loaded your dump file and symbols are verified, try the following:

Get a thread to use:

• !process - (use any addresses after “THREAD” from the output)

Dump the Executive Thread Block pointed to by this address

• Dt <address> _ethread

Use the C++ evaluator (??) to evaluate one of the structures members after casting it to the correct type

• ?? ((nt!_kthread *) 0x8add4540)->Process - (note that the 0x prefix is mandatory. Without this you will get an error)

Use the MASM evaluator (?) to evaluate this using MASM syntax – note the 0x150 offset is the location of the ‘Process’ member.

• ? poi(0x8add4540 + 0x150) - (poi() dereferences a pointer. Dumps the address of the structure, but not the type as it does not map this to the symbol data)

You can use the dump type command (dt) or specific extensions to display similar type information to that seen in the c++ example, given the address from the MASM command

• !process poi(0x8add4540 + 0x150) : gives the extension output correctly

A big advantage of C++ syntax is the access to symbolic information, as seen in the example above. Besides being more readable and easier to work with, the symbolic names of structure members are less likely to change in future OS service packs and releases than raw offsets, making this a more reliable method of traversing structures.

We can now look at a more complex example using the internal list of ‘Dispatcher’ objects associated with a particular thread. For an overview of dispatcher objects, see Windows Internals 5^th Edition page 178. This post is only covering how to access objects through various syntaxes in windbg. The following structures were chosen as examples for their complexity, we are not going to look at their functionality, or synchronization issues, and we will not be creating a functionally useful script (we will do that in later posts). This exercise is just designed to learn the mechanics. We don’t need to understand the functionality of the structures, but we do need to understand how they relate to one another. The below illustration shows these relationships…

The goal of this exercise is to start with address of a particular _DISPATCHER_HEADER structure, and try to get all the way to the name of the app that started the process containing the thread that is waiting for it (whew!).

The easiest way to get a _DISPATCHER_HEADER structure to play with is to look at the output of !process for the system process. Here are the commands to run in your sample dump file to get the address of a _DISPATCHER_HEADER object…

• !process 0 0 system – (output as below, copy the highlighted address)
• PROCESS 83f3da40 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000
• DirBase: 00185000 ObjectTable: 86c01cb8 HandleCount: 474.
• Image: System
• !process <address>
• e.g. “!process 83f3da40”

<Look for any thread that shows it is waiting on something – use the address of the object being waited for in the next steps (highlighted)>

<…>
THREAD 8af5a990 Cid 0004.0740 Teb: 00000000 Win32Thread: 00000000 WAIT: (WrQueue) KernelMode Non-Alertable
8af59d80 QueueObject
Not impersonating
DeviceMap 86c07868
Owning Process 83f3da40 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 2417 Ticks: 10245 (0:00:01:42.597)
Context Switch Count 1 IdealProcessor: 0
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address srv2!SrvProcWorkerThread (0x926686cb)
Stack Init 80fe4fd0 Current 80fe4c08 Base 80fe5000 Limit 80fe2000 Call 0
Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
ChildEBP RetAddr
80fe4c20 8286fc6d nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
80fe4c58 8286ead3 nt!KiSwapThread+0x266
80fe4c80 8286f7c5 nt!KiCommitThreadWait+0x1df
<…>

Now that we have the address of our dispatcher object, we need to get to the first _KWAIT_BLOCK in its list of wait blocks. This is a little tricky as the _DISPATCHER_HEADER stores pointers to these in a linked list so the WaitListHead member actually contains the Flink pointing to the first _KWAIT_BLOCK (see ‘dt _DISPATCHER_HEADER and ‘dt _LIST_ENTRY’).  The Flink points to the first wait block so we will cast the Flink to this type to access its members.

In the following examples, I am using the addresses from the thread example output above. The highlighted addresses will need to be changed to match those from your system.

• ?? ((nt!_dispatcher_header *)0x8af59d80)->WaitListHead.Flink - (to get the linked list)
• ?? (_kwait_block *)(((nt!_dispatcher_header *)0x8af59d80)->WaitListHead.Flink) - (to get the _kwait_block object)

Looking at the _kwait_block structure, we can see that it contains a _kthread member. We can access that next…

• ?? ((_kwait_block *)(((nt!_dispatcher_header *)0x8af59d80)->WaitListHead.Flink))->Thread

Within the _kthread structure, there is a ‘Process’ member of type _kprocess. Since the correct type is contained in the structure, we can access without casting with the C++ syntax

• ?? ((_kwait_block *)(((nt!_dispatcher_header *)0x8af59d80)->WaitListHead.Flink))->Thread->Process

With heavy use of Windows Internals 5^th Edition, and the ‘dt’ command, we can find that every _kprocess structure is the first member of a containing _eprocess structure. This means that we can cast the pointer to an _eprocess structure and access its ‘ImageFileName’ member, which will give us the name of the exe file associated with the process (our end goal)…

• ?? (_eprocess *)(((_kwait_block *)(((nt!_dispatcher_header *)0x8af59d80)->WaitListHead.Flink))->Thread->Process)
• ?? ((nt!_EPROCESS *)((nt!_KWAIT_BLOCK *)((nt!_DISPATCHER_HEADER *)0x8bab3250)->WaitListHead.Flink)->Thread->Process)->ImageFileName

If we want to see the actual image file name, we can use da (dump ascii) instead of ‘??’ to dump the file name. Remember though that Windbg defaults to MASM syntax so if we are not using the ‘??’ command specific to evaluating C++ syntax, we have to place our command within the @@c++() parentheses

• da @@C++(((nt!_EPROCESS *)((nt!_KWAIT_BLOCK *)((nt!_DISPATCHER_HEADER *)0x8bab3250)->WaitListHead.Flink)->Thread->Process)->ImageFileName)

This example is chosen to be (hopefully) as complex as most scenarios you might encounter in your own debugging. In a future series of articles, I am planning to provide an example of implementing a full scripted command (or command program) that is as easy to use as Windbg built in commands / extensions, practically useful, and available across debugging sessions. The idea is to show how you can create a library of custom commands, specific to your own drivers / troubleshooting tasks.