当前位置：.Net技术首页 >> 评论及其它 >> Debug Tutorial Part 6: Navigating The Kernel Debugger

Debug Tutorial Part 6: Navigating The Kernel Debugger

2006-04-21 19:49:13 作者：iiprogram 来源：互联网浏览次数：5 文字大小：【大】【中】【小】

简介：Introduction In this tutorial, we will be covering a few of the basic features of the kernel debugger, and get used to using it. I obviously can't cover everything, so only select topics will be ...

关键字：Navigating Debugger Tutorial Kernel Debug Part The

Introduction

In this tutorial, we will be covering a few of the basic features of the kernel debugger, and get used to using it. I obviously can't cover everything, so only select topics will be covered to just get used to the debugger. Hopefully, you will find this article useful in your debugging adventures.

Setup

To setup the Kernel Debugger, you will need to modify your BOOT.INI file as mentioned in "Debug Tutorial Part 1". /DEBUG /DEBUGPORT=COM1 /BAUDRATE=115200 should be entered as options. If you do not specify the speed, the default I believe is 19200. I would create a separate entry in the boot.ini so you can select between debugging and not debugging. You can do this by just copying what is already there and modifying it.

[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional"

/fastdetect

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional"

/fastdetect /debug /debugport=com1 /baudrate=115200

(Shown on seperate line to prevent long lines in this article.

Should be on the same line in boot.ini).

You can also use Firewire if you have that setup. To connect, connect a NULL Modem cable from the specified COM port of the machine you want to debug, to the COM port of the machine you want to use to debug.

There are also other kernel debuggers out there that run on the same machine, like Softice. There's even a "LiveKD" that can be used. This tutorial will only refer to the free tools that can be downloaded from Microsoft for Windows NT. There are other versions of the tools for Windows 9x.

To connect to the machine, simply open WINDBG and select "Kernel Debug" from the File menu. Select "COM" tab, or other tab if you used Firewire, and then enter the options. The COM port you specify is where you connect the cable to the local machine, not the one you specified in the remote machine's BOOT.INI. If you're using VMWare, when you setup the COM port, you can select it to output to a Pipe. This URL shows the setup for VMWare.

You may need to press "Control + C" if the machine has already booted in order for you to enter the debugger.

Some other tips; if you are having trouble connecting, you may want to try some of the following:

Control + Break or "Break" in Debug menu.

Resynchronize (Debug -> Kernel Connection).

Cycle Baud Rates (Debug -> Kernel Connection).

Try a different COM Port, ensure the cable is on correct ports.

Close the debugger and try again by opening another debugger.

Ensure boot.ini is correct. When booting, should see "DEBUGGER ENABLED" by the name.

Ready To Go!

Now that we are connected, we are ready to go. First, ensure you are pointing to the Microsoft Symbol server using !symfix or any method specified in "Debug Tutorial Part 1". Set your symbol path using the environment variable, for example, and adding any other symbol paths you may need such as for your own software.

First, let's get started with something simple. Let's find all processes on the system. This is done by breaking into the kernel debugger and using the "!process 0 0". Remember, if you get an error, make sure you are pointing to Microsoft's symbol server. The debugger needs to locate certain variables in memory to perform different actions.

You may see something like this for each process:

PROCESS fcdbe2c0 SessionId: 0 Cid: 00a4 Peb: 7ffdf000 ParentCid: 008c

DirBase: 0401d000 ObjectTable: fcdc39c8 TableSize: 354.

Image: winlogon.exe

So, what does it all mean?

PROCESS

The first is the address of the EPROCESS structure. This is a kernel data structure that describes that process. The address for this process is "fcdbe2c0". If you have symbols, you can use the "dt" command which was mentioned in an earlier tutorial, to view this structure.

dt _EPROCESS fcdbe2c0

dt nt!_EPROCESS fcdbe2c0

If this does not work and you are debugging a Windows 2000 machine, you may want to use "!processfields" instead. It will show you the offsets into fcdbe2c0, and then you can dump the address manually to see the data you want.

SESSION ID

The next is the "Session ID". In a multi-user environment (Terminal Services), different users who log into a machine get their own "session". Normally, Session 0 is the console, although this is a bit different in Windows XP with the fast user switching feature. For kicks, log into Windows XP with a few users (unless you have 2000 or 2003 server edition, you can try the same thing) and type "qwinsta". It should give you output of the user and their session ID.

CID

The "Cid" is the Process Identifier. If you look in Task Manager and select "PID" to display in the columns, this is all it is. It's the PID of this process.

PEB

PEB is the Process Environment Block. This is a user mode data structure, and what does that mean? Generally, every process you will see the same address for this location. I hope that anyone wanting to use the kernel debugger understands Virtual Addresses. In the kernel, the system address space is mapped for all processes (without going into the details of "session space"), but the user mode addresses are mapped for that process. So, obviously, the same address in one process is not the same physical address as another. So, if all the addresses are the same, how would we view the PEB for a particular process? We need to change our "context" to that process. That way, the correct page directory tables are loaded, and we can correctly translate to the data in that process. We will learn how to set the context later. When you do though, just as in the local debugger, you can view the PEB in the kernel debugger.

dt _PEB 7ffdf000

!peb.

PARENT CID

The "Parent Cid" is exactly what you think it is. It's the process that created this process, the parent process.

DIRBASE

The "DirBase" is the directory base. This is the value of CR3 when this process is running. This is the address that starts the translation of Virtual Addresses to Physical Addresses. In fact, there is a command that can do this for you. !ptov. So, the Directory Base is 0401d000, you must take off the last 3 digits (which should always be 0).

!ptov 0401d

kd> !ptov 0401d

4195000 10000

40d6000 20000

3a5d000 6d000

40f9000 6e000

4117000 6f000

405a000 70000

409b000 71000

409c000 72000

412f000 73000

413a000 74000

42d1000 76000

426f000 77000

4416000 78000

4458000 7a000

439d000 7b000

43b6000 7c000

4880000 7d000

4831000 7e000

4ac3000 7f000

4b66000 80000

4a67000 81000

4f42000 84000

50a7000 89000

4f81000 8d000

523f000 94000

5240000 a8000

524f000 ac000

5226000 b3000

52c4000 bc000

4fda000 d6000

52af000 dc000

5403000 e2000

51cc000 e5000

509f000 ec000

5325000 ee000

52aa000 f0000

512c000 f2000

522e000 f3000

52f1000 f4000

5174000 f6000

5249000 f7000

575e000 f8000

56df000 f9000

5721000 fb000

58e3000 fd000

576c000 fe000

57ad000 ff000

5833000 105000

583c000 10e000

...

The address on the left is the Physical Address. The address on the right is the Virtual Address used by the application. To view a physical address, you do not need to switch contexts. You use the "!dc", "!db", etc. commands instead of the "dc", "db" commands which work on Virtual Address. You can also change the data stored at a physical address by using the "!eb", etc. commands to write data.

kd> !dc 5833000

# 5833000 72656d6d 6c616963 666f5320 72617774 mmercial Softwar

# 5833010 75502065 73696c62 73726568 30414320 e Publishers CA0

# 5833020 0d309f81 862a0906 0df78648 05010101 ..0...*.H.......

# 5833030 8d810300 89813000 00818102 6569d3c3 .....0........ie

# 5833040 54940152 62c628ab 5554b318 458744c5 R..T.(.b..TU.D.E

# 5833050 7ec23b4a c8d7d3d8 d88d8680 9c16f10c J;.~............

# 5833060 29a96bcc 73768fb2 62c5c892 1eed3ca6 .k.)..vs...b.<..

# 5833070 13f07505 4d146c00 079098d4 817369be .u...l.M.....is.

OBJECT TABLE

This is the table of the handle mappings for that process. This is a data structure that contains the size and a pointer to the object to handle list. This is how the kernel converts a usermode handle into its matching kernel object. We will look at handles again later.

TABLESIZE

This is the size of the table in base 10. Yes, this is a bit non-standard now since we have some numbers in hex like the PID, but the size of the table is in decimal. This shows how many entries this process has in its handle table. If you open Task Manager and view "Handle Count", it should match this number. This is how many handle entries are being used in this process.

IMAGE

This is a simple one. The image of this process, in this case it's WINLOGON.EXE.

Changing Contexts

There are different ways to change contexts. You can do .context , you can use .trap , but here I will show you how to switch to a thread.

First, let's dump WinLogon's threads.

!process fcdbe2c0 ff

The EPROCESS structure must be supplied to the kernel debugger along with some flags. Now, ff is to show everything.

kd> !process fcdbe2c0 ff

PROCESS fcdbe2c0 SessionId: 0 Cid: 00a4 Peb: 7ffdf000 ParentCid: 008c

DirBase: 0401d000 ObjectTable: fcdc39c8 TableSize: 354.

Image: winlogon.exe

VadRoot fcda2ce8 Clone 0 Private 798. Modified 1085. Locked 0.

DeviceMap fcebfa48

Token e1b762d0

ElapsedTime 21:07:55.0882

UserTime 0:00:01.0241

KernelTime 0:00:03.0805

QuotaPoolUsage[PagedPool] 36408

QuotaPoolUsage[NonPagedPool] 62184

Working Set Sizes (now,min,max) (652, 50, 345) (2608KB, 200KB, 1380KB)

PeakWorkingSetSize 2034

VirtualSize 34 Mb

PeakVirtualSize 36 Mb

PageFaultCount 4919

MemoryPriority BACKGROUND

BasePriority 13

CommitCharge 1357

THREAD fcdbd020 Cid a4.84 Teb: 7ffde000 Win32Thread: e1b7b8e8

WAIT: (WrUserRequest) UserMode Non-Alertable

fcdb9820 SynchronizationEvent

Not impersonating

Owning Process fcdbe2c0

Wait Start TickCount 49551906 Elapsed Ticks: 13726

Context Switch Count 3360 LargeStack

UserTime 0:00:00.0290

KernelTime 0:00:01.0041

Start Address 0x01001674

Stack Init f7660000 Current f765fcc8 Base f7660000 Limit f765d000 Call 0

Priority 15 BasePriority 15 PriorityDecrement 0 DecrementCount 0

Kernel stack not resident.

ChildEBP RetAddr Args to Child

f765fce0 8042d61c 00000000 e1b7b8e8 00000001 nt!KiSwapThread+0xc5

f765fd08 a00159cb fcdb9820 0000000d 00000001 nt!KeWaitForSingleObject+0x1a1

f765fd44 a0014f6c 000020ff 00000000 00000001 win32k!xxxSleepThread+0x183

f765fd54 a0014f53 0006fde8 80461691 00000000 win32k!xxxWaitMessage+0xe

f765fd5c 80461691 00000000 00000000 00000018 win32k!NtUserWaitMessage+0xb

f765fd5c 77e14b53 00000000 00000000 00000018 nt!KiSystemService+0xc4

0006fe14 77e23570 00070022 00000000 00000010 +0x77e14b53

0006fe38 77e2381e 01000000 01024c10 00000000 +0x77e23570

0006fe58 77e3dcf8 01000000 01024c10 00000000 +0x77e2381e

0006fe7c 01006052 01000000 00000578 00000000 +0x77e3dcf8

0006feb8 01005fa8 000766b8 01000000 00000578 +0x1006052

0006fef0 010099c7 000766b8 01000000 00000578 +0x1005fa8

0006ff28 010019e4 000766b8 00000005 0007366c +0x10099c7

0006ff58 0100179e 01000000 00000000 0007366c +0x10019e4

0006fff4 00000000 7ffdf000 000000c8 00000100 +0x100179e

THREAD fcdb8b80 Cid a4.c0 Teb: 7ffdd000 Win32Thread: 00000000

WAIT: (DelayExecution) UserMode Alertable

fcdb8c68 NotificationTimer

Not impersonating

Owning Process fcdbe2c0

Wait Start TickCount 49564648 Elapsed Ticks: 984

Context Switch Count 33085

UserTime 0:00:00.0000

KernelTime 0:00:00.0000

Start Address 0x77e92c50

Win32 Start Address 0x77f88164

Stack Init f78f4000 Current f78f3cc4 Base f78f4000 Limit f78f1000 Call 0

Priority 13 BasePriority 13 PriorityDecrement 0 DecrementCount 0

Kernel stack not resident.

ChildEBP RetAddr Args to Child

f78f3cdc 8042d00e f78f3d64 003dffac 003dffac nt!KiSwapThread+0xc5

f78f3d04 804c04e6 003dfc01 00000001 f78f3d34 nt!KeDelayExecutionThread+0x180

f78f3d54 80461691 00000001 003dffac 00000000 nt!NtDelayExecution+0x7f

f78f3d54 77f90333 00000001 003dffac 00000000 nt!KiSystemService+0xc4

003dffb4 77e92ca8 0006feb8 00000000 00000000 +0x77f90333

003dffec 00000000 77f88164 0006feb8 00000000 +0x77e92ca8

... (Continues on with more information)

Don't get worried by the "Kernel stack not resident". We know that memory gets swapped to disk, right? So, not all memory will always be available when using the kernel debugger. We just have to bear with this. In the above case, the stack is in memory, at least enough to get a stack trace, which isn't always true. The above just means that part of the stack isn't in memory, in this case.

So, let's set our context to the first thread.

kd> .process fcdbe2c0

Implicit process is now fcdbe2c0

WARNING: .cache forcedecodeuser is not enabled

kd> .cache forcedecodeuser

Max cache size is : 1024000 bytes (0x3e8 KB)

Total memory in cache : 0 bytes (0 KB)

Number of regions cached: 0

0 full reads broken into 0 partial reads

counts: 0 cached/0 uncached, 0.00% cached

bytes : 0 cached/0 uncached, 0.00% cached

** Transition PTEs are implicitly decoded

** User virtual addresses are translated to physical addresses before access

kd> .thread fcdbd020

Implicit thread is now fcdbd020

kd> kb

*** Stack trace for last set context - .thread/.cxr resets it

ChildEBP RetAddr Args to Child

f765fce0 8042d61c 00000000 e1b7b8e8 00000001 nt!KiSwapThread+0xc5

f765fd08 a00159cb fcdb9820 0000000d 00000001 nt!KeWaitForSingleObject+0x1a1

f765fd44 a0014f6c 000020ff 00000000 00000001 win32k!xxxSleepThread+0x183

f765fd54 a0014f53 0006fde8 80461691 00000000 win32k!xxxWaitMessage+0xe

f765fd5c 80461691 00000000 00000000 00000018 win32k!NtUserWaitMessage+0xb

f765fd5c 77e14b53 00000000 00000000 00000018 nt!KiSystemService+0xc4

WARNING: Frame IP not in any known module. Following frames may be wrong.

0006fe14 77e23570 00070022 00000000 00000010 0x77e14b53

0006fe38 77e2381e 01000000 01024c10 00000000 0x77e23570

0006fe58 77e3dcf8 01000000 01024c10 00000000 0x77e2381e

0006fe7c 01006052 01000000 00000578 00000000 0x77e3dcf8

0006feb8 01005fa8 000766b8 01000000 00000578 0x1006052

0006fef0 010099c7 000766b8 01000000 00000578 0x1005fa8

0006ff28 010019e4 000766b8 00000005 0007366c 0x10099c7

0006ff58 0100179e 01000000 00000000 0007366c 0x10019e4

0006fff4 00000000 7ffdf000 000000c8 00000100 0x100179e

kd> !reload

Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE

Loading Kernel Symbols

...................................................................................

Loading unloaded module list

No unloaded module list present

Loading User Symbols

..................................................

kd> kb

*** Stack trace for last set context - .thread/.cxr resets it

ChildEBP RetAddr Args to Child

f765fce0 8042d61c 00000000 e1b7b8e8 00000001 nt!KiSwapThread+0xc5

f765fd08 a00159cb fcdb9820 0000000d 00000001 nt!KeWaitForSingleObject+0x1a1

f765fd44 a0014f6c 000020ff 00000000 00000001 win32k!xxxSleepThread+0x183

f765fd54 a0014f53 0006fde8 80461691 00000000 win32k!xxxWaitMessage+0xe

f765fd5c 80461691 00000000 00000000 00000018 win32k!NtUserWaitMessage+0xb

f765fd5c 77e14b53 00000000 00000000 00000018 nt!KiSystemService+0xc4

0006fde0 77e23680 00000000 00000000 0000ffff USER32!NtUserWaitMessage+0xb

0006fe14 77e23570 00070022 00000000 00000010 USER32!DialogBox2+0x216

0006fe38 77e2381e 01000000 01024c10 00000000 USER32!InternalDialogBox+0xd1

0006fe58 77e3dcf8 01000000 01024c10 00000000 USER32!DialogBoxIndirectParamAorW+0x34

0006fe7c 01006052 01000000 00000578 00000000 USER32!DialogBoxParamW+0x3d

0006feb8 01005fa8 000766b8 01000000 00000578 winlogon!TimeoutDialogBoxParam+0x27

0006fef0 010099c7 000766b8 01000000 00000578 winlogon!WlxDialogBoxParam+0x7b

0006ff10 01004bdc 000766b8 00071fc8 000766b8 winlogon!BlockWaitForUserAction+0x3c

0006ff28 010019e4 000766b8 00000005 0007366c winlogon!MainLoop+0x1bf

0006ff58 0100179e 01000000 00000000 0007366c winlogon!WinMain+0x2a5

0006fff4 00000000 7ffdf000 000000c8 00000100 winlogon!WinMainCRTStartup+0x156

Now, you notice once I set my context, I had to reload symbols in order to view usermode symbols? That's because we need to force the kernel debugger to read the new context and load the new symbols for this process. If you switch processes multiple times, you may have noticed the kernel debugger will tell you the symbols for the previous process. This is why you should try to reload symbols once you switch contexts.

You should also note that the kernel stack is different from the usermode stack. When a thread calls into the kernel, it switches the stack. The kernel has its own stack, and usermode has its own stack. This is just an FYI.

So, now you may be asking what do all the parameters mean in the PROCESS and THREAD listings? The top header we already covered, so let's start with the Process header. Though, most of it will usually just be useless information to you.

VadRoot fcda2ce8 Clone 0 Private 798. Modified 1085. Locked 0.

The "VadRoot" is basically a pointer to a binary tree that contains the address of all Virtual Address in the process, including their start and end ranges. This is called a "Virtual Address Descriptor". If you walk this tree, you would end up seeing the same output you would if you did an x *! in the user mode debugger, but actually you may see more. This is because, this doesn't just include modules, but all mapped virtual address and their ranges. For example, if you did Virtual Alloc for some large blocks of memory, these would show up in this tree list.

Try !vad fcda2ce8

(Notice that you should obviously put the address that's listed in your kernel debugger there.)

DeviceMap fcebfa48

This is the Object Device Map for the system. While each process gets its own pointer to this object, as you can see below, it is stored globally in the kernel.

kd> x nt!ObSystemDeviceMap

8047f79c nt!ObSystemDeviceMap =

kd> dd nt!ObSystemDeviceMap L 1

8047f79c fcebfa48

This article will not go into displaying device stacks or anything like that. This article is just an introduction to the basics.

Token e1b762d0

The user's token for this process. Try !token e1b762d0:

ElapsedTime 21:07:55.0882

UserTime 0:00:01.0241

KernelTime 0:00:03.0805

The amount of time spent in the kernel and in usermode.

QuotaPoolUsage[PagedPool] 36408

QuotaPoolUsage[NonPagedPool] 62184

Working Set Sizes (now,min,max) (652, 50, 345) (2608KB, 200KB, 1380KB)

PeakWorkingSetSize 2034

VirtualSize 34 Mb

PeakVirtualSize 36 Mb

PageFaultCount 4919

MemoryPriority BACKGROUND

BasePriority 13

CommitCharge 1357

These are pretty self explanatory as well. They simply display memory usage and statistics.

Now, let's take a look at the thread information. We can do this by using !thread .

kd> !thread fcdbd020

THREAD fcdbd020 Cid a4.84 Teb: 7ffde000 Win32Thread: e1b7b8e8 WAIT:

(WrUserRequest) UserMode Non-Alertable

fcdb9820 SynchronizationEvent

Not impersonating

Owning Process fcdbe2c0

Wait Start TickCount 49551906 Elapsed Ticks: 14128

Context Switch Count 3360 LargeStack

UserTime 0:00:00.0290

KernelTime 0:00:01.0041

Start Address winlogon!WinMainCRTStartup (0x01001674)