| 導購 | 订阅 | 在线投稿
分享
 
 
 

Debug Tutorial Part 6: Navigating The Kernel Debugger

來源:互聯網網民  2006-04-18 05:20:49  評論

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

or

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

or

!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 <DirBase>, you can use .trap <trap address>, 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 = <NO type information>

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 <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)

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

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, let's take a look at each piece of header information. We remember from before that the process address was actually an EPROCESS structure. Well, this is an ETHREAD structure. This can be displayed by using dt nt!_ETHREAD <address> or !threadfields.

So, let's break it down.

THREAD fcdbd020 Cid a4.84 Teb: 7ffde000

Win32Thread: e1b7b8e8 WAIT: (WrUserRequest)

UserMode Non-Alertable

fcdb9820 SynchronizationEvent

The first address is the address of the ETHREAD structure as we mentioned. The second is the Process.Thread ID. The process ID is A4h, the thread ID is 84h. Thread IDs are useful when looking at deadlocks since the synchronization objects are owned by threads. It's also good when looking for window information as each window is owned by a particular thread. These thread IDs are available in the user mode debugger.

The TEB. The Thread Environment Block is as mentioned in a previous tutorial. This has thread specific information as well as it points to the PEB, so threads can easily access certain information. The stack limit and end is here as well. !teb or dt _TEB <address>. You obviously need to be in the context of the process and thread to use !teb. If the TEB is NULL, this means it's a system thread. The thread is only executing in the kernel, it's not a user mode thread.

The next is the "Win32Thread". What's this? This is a per-thread data structure that WIN32k.SYS maintains.

The last part is the state of the thread. This thread is in a wait state. It's waiting in a non-alertable state in usermode. For more information on alertable, non-alertable, kernel verse. usermode waits, please refer to MSDN's articles about KeWaitForMultipleObjects or information about APC (Asynchronous Procedure Calls).

Not impersonating

Whether this thread is impersonating or not. If you are familar with RPC, the server can impersonate the caller to perform operations on the caller's behalf or get information about the caller. If this thread was impersonating, you would see an impersonation token here which you could do !token <address> on to get the information. Certain calls into the kernel will look at this impersonation token if it is there and use it instead of the process' user token.

Owning Process fcdbe2c0

The own process' EPROCESS address. In this case, it's Winlogon. You may see weird things sometimes where a thread seems to have a different owner than it's being displayed in. The kernel may call KeAttachProcess() to perform actions in a different context.

Wait Start TickCount 49551906 Elapsed Ticks: 14128

Context Switch Count 3360 LargeStack

UserTime 0:00:00.0290

KernelTime 0:00:01.0041

Time this thread spent in usermode and kernel mode. If you are looking for a process hog, these are the values you look at to find the process, then the thread. "Elapsed Ticks" is how long it's been since this thread was executed. If you're looking for a hog right after it happened, this is another field to look at, what threads have the least elapsed ticks.

Start Address winlogon!WinMainCRTStartup (0x01001674)

This is the starting address of the thread.

Stack Init f7660000 Current f765fcc8 Base f7660000 Limit f765d000 Call 0

This refers to the kernel stack, not the user mode stack which can be found in the TEB. The current position of the kernel mode stack and its limits, and where it started.

Priority 15 BasePriority 15 PriorityDecrement 0 DecrementCount 0

The priority of this thread.

You may see other things, but this is a basic listing. If you notice an LPC, you can do things like "!lpc message <message id>" to get the originator of the call if they are still around, for example.

Now that we are in the context, we can do things like set break points, change memory, etc. Just remember that changing memory in a driver will change this memory for everyone. Setting breakpoints is the same way, you set the breakpoint for everyone on the system. This is a kernel debugger and the kernel mode drivers are global to the system (or the session, for other certain drivers we will not cover here).

What else can I do?

There're a lot of things that you can do, but like I mentioned before, we will just be covering some of the basics. It also depends on the area that you work in. For example, someone who is developing hardware drivers may never use or even look at anything in usermode or even that high up the driver stack. They may only know some of the hardware commands. Someone who only works with usermode applications or interaction may only use the kernel debugger for some extra information, or figure out who's calling with an RPC, etc.

Page Table Entries

The only problem with using the kernel debugger or kernel dump is that some information may not be there, it may be paged out. So, how can we tell if memory is valid or paged out?

In the x86 processor, there are levels of indirection when it comes to translating a virtual address to a physical address. There is a Page Directory Entry that points to a Page Table Entry. If you want to find the Page Table Entry, this is how you can do it. Remember, we already know how to find physical addresses for virtual addresses using the page directory of the process.

!pte is the answer to find Page Table Entries.

kd> !pte 80461691

80461691 - PDE at C0300804 PTE at C0201184

contains 00034163 contains 00461121

pfn 34 G-DA--KWV pfn 461 G--A--KRV

kd> dc C0300804 L1

c0300804 00034163

kd> dc C0201184 L1

c0201184 00461121

Just to show, if you dc those addresses, that's what you get. The Virtual Address is first added to the GDT/LDT and then it's translated. Part of the Virtual Address is taken as an offset to get the Page Directory Entry. Then next part of the Address is taken to get the Page Entry Table. The last 3 nibbles of the virtual address are actually the last 3 nibbles of where the PTE points to. So, the PTE says 461xxx is the physical address. Let's find out and dump the virtual and physical addresses:

kd> !dc 461691

# 461690 8be58bd3 dff1240d 3c558bff 01289189 .....$....U<..(.

# 4616a0 f7fa0000 00007045 06750002 016c45f6 ....Ep....u..El.

# 4616b0 1d8b5874 ffdff124 002e43c6 004a7b80 tX..$....C...{J.

# 4616c0 dd8b4874 c7444389 003b5043 43c70000 tH...CD.CP;....C

# 4616d0 00002338 3443c700 00000023 003043c7 8#....C4#....C0.

# 4616e0 b9000000 00000001 059815ff fb508040 ............@.P.

# 4616f0 6a006a53 f132e801 ff59fffc 40059c15 Sj.j..2...Y....@

# 461700 44438b80 90abebfa 548bff8b 8b644c24 ..CD.......T$Ld.

kd> dc 80461691

80461691 0d8be58b ffdff124 893c558b 00012891 ....$....U<..(..

804616a1 45f7fa00 02000070 f6067500 74016c45 ...Ep....u..El.t

804616b1 241d8b58 c6ffdff1 80002e43 74004a7b X..$....C...{J.t

804616c1 89dd8b48 43c74443 00003b50 3843c700 H...CD.CP;....C8

804616d1 00000023 233443c7 c7000000 00003043 #....C4#....C0..

804616e1 01b90000 ff000000 40059815 53fb5080 ...........@.P.S

804616f1 016a006a fcf132e8 15ff59ff 8040059c j.j..2...Y....@.

80461701 fa44438b 8b90abeb 24548bff 1d8b644c .CD.......T$Ld..

As you can see, it's true. The Physical Address dump is a little different as it dumped it at the start of the memory rather than 1 so it was aligned, but you can see it's the same information. If we had dumped them "dc 80461690", you would see they are the same.

You can also go backwards, take a PTE address, and find the virtual address it belongs to.

kd> !pte C0201184

80461000 - PDE at C0300804 PTE at C0201184

contains 00034163 contains 00461121

pfn 34 G-DA--KWV pfn 461 G--A--KRV

What happens on invalid addresses?

kd> !pte 40

00000040 - PDE at C0300000 PTE at C0000000

contains 01800067 contains 00000000

pfn 1800 --DA--UWV not valid

kd> dc C0300000 L1

c0300000 01800067

kd> dc C0000000 L1

c0000000 00000000

kd> !pte 66740020

66740020 - PDE at C0300664 PTE at C0199D00

contains 00000000 unavailable

kd> dc C0300664 L1

c0300664 00000000

kd> dc C0199D00 L1

c0199d00 00a8d4c0

"Not Valid" means it's not a valid virtual address. (Some addresses may be "not valid" just because they have never been used yet, so they're not mapped I have found, at least that's my theory! For example, stack memory is mapped into your process but it's never been dirty, so why put it in the page file?) "Unavailable" means it's not available, but it is valid or it believes it to be. Otherwise, the address is valid. Sometimes, if an address is "unavailable", it will list a pagefile offset, and sometimes it will not. Executables and binaries are done using memory mapped files. You can see this by doing !memusage. That means that these, unless modified, would not be in the pagefile, and thus there is no pagefile offset.

There is also a !sysptes that can dump all system ptes.

Handle Information

Displaying handle information in the kernel is easy. Once you set your context to the correct process, just !handle as you do in user mode, with an exception. You need to specify the process to dump the handles.

kd> !handle 0 0 fcdbe2c0

processor number 0

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

DirBase: 0401d000 ObjectTable: fcdc39c8 TableSize: 354.

Image: winlogon.exe

Handle Table at e1b78000 with 354 Entries in use

0004: Object: e1267030 GrantedAccess: 000f001f

0008: Object: fcdee160 GrantedAccess: 00100003

000c: Object: fcdee120 GrantedAccess: 00100003

0010: Object: fcdbe280 GrantedAccess: 00100003

The first is the handle # used in usermode. The second is the "Object" or kernel address of the object, and the last is the access granted to the object. You may also specify flags to dump more information as seen below:

kd> !handle 0 ff fcdbe2c0

processor number 0

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

DirBase: 0401d000 ObjectTable: fcdc39c8 TableSize: 354.

Image: winlogon.exe

Handle Table at e1b78000 with 354 Entries in use

0000: free handle

0004: Object: e1267030 GrantedAccess: 000f001f

Object: e1267030 Type: (fcebc580) Section

ObjectHeader: e1267018

HandleCount: 1 PointerCount: 1

0008: Object: fcdee160 GrantedAccess: 00100003

Object: fcdee160 Type: (fcebf420) Event

ObjectHeader: fcdee148

HandleCount: 1 PointerCount: 1

000c: Object: fcdee120 GrantedAccess: 00100003

Object: fcdee120 Type: (fcebf420) Event

ObjectHeader: fcdee108

HandleCount: 1 PointerCount: 1

0010: Object: fcdbe280 GrantedAccess: 00100003

Object: fcdbe280 Type: (fcebf420) Event

ObjectHeader: fcdbe268

HandleCount: 1 PointerCount: 1

0014: Object: fcec6c50 GrantedAccess: 00000003

Object: fcec6c50 Type: (fcee4b40) Directory

ObjectHeader: fcec6c38

HandleCount: 15 PointerCount: 44

Directory Object: fcebfab0 Name: KnownDlls

HashBucket[ 00 ]: e137ca00 Section 'gdi32.dll'

e134b900 Section 'imagehlp.dll'

e13154a0 Section 'url.dll'

HashBucket[ 02 ]: e13dee00 Section 'MPR.dll'

HashBucket[ 03 ]: e135b040 Section 'ole32.dll'

e135d2a0 Section 'urlmon.dll'

HashBucket[ 04 ]: e1373600 Section 'lz32.dll'

e138bde0 Section 'olesvr32.dll'

HashBucket[ 06 ]: e137ef40 Section 'shell32.dll'

e12c7880 Section 'wldap32.dll'

HashBucket[ 09 ]: e13126e0 Section 'user32.dll'

e13118a0 Section 'version.dll'

HashBucket[ 10 ]: e135af80 Section 'olecli32.dll'

HashBucket[ 14 ]: e13713e0 Section 'MSASN1.DLL'

HashBucket[ 16 ]: e1314c60 Section 'COMCTL32.DLL'

fcde6c50 SymbolicLink 'KnownDllPath'

HashBucket[ 17 ]: e13171c0 Section 'CRYPT32.dll'

HashBucket[ 18 ]: e1316e60 Section 'advapi32.dll'

e13583a0 Section 'oleaut32.dll'

HashBucket[ 19 ]: e135c980 Section 'SHLWAPI.DLL'

e12c2fc0 Section 'wow32.dll'

e1316460 Section 'olecnv32.dll'

HashBucket[ 23 ]: e131a520 Section 'comdlg32.dll'

HashBucket[ 26 ]: e1317b80 Section 'wininet.dll'

HashBucket[ 27 ]: e12d5fc0 Section 'olethk32.dll'

HashBucket[ 28 ]: e124c800 Section 'MSVCRT.DLL'

HashBucket[ 31 ]: e134dbe0 Section 'rpcrt4.dll'

HashBucket[ 32 ]: e130b460 Section 'kernel32.dll'

0018: Object: fccc3c88 GrantedAccess: 00100020 (Inherit)

Object: fccc3c88 Type: (fced7c40) File

ObjectHeader: fccc3c70

HandleCount: 1 PointerCount: 1

Directory Object: 00000000 Name: \WINNT\system32 {HarddiskVolume1}

001c: Object: fcdfb730 GrantedAccess: 000f000f

Object: fcdfb730 Type: (fcee4b40) Directory

ObjectHeader: fcdfb718

HandleCount: 14 PointerCount: 18

Directory Object: fcebfab0 Name: Windows

HashBucket[ 04 ]: e1b76d40 Port 'SbApiPort'

HashBucket[ 09 ]: e1b65a00 Port 'ApiPort'

HashBucket[ 32 ]: fcdc1750 Directory 'WindowStations'

0020: Object: fcdb9de0 GrantedAccess: 00100003

Object: fcdb9de0 Type: (fcebf420) Event

ObjectHeader: fcdb9dc8

HandleCount: 1 PointerCount: 1

0024: Object: e1b7be30 GrantedAccess: 001f0001 (Protected)

Object: e1b7be30 Type: (fceb7640) Port

ObjectHeader: e1b7be18

HandleCount: 1 PointerCount: 18

0028: Object: fceca3c0 GrantedAccess: 00000001

Object: fceca3c0 Type: (fcebda40) Mutant

ObjectHeader: fceca3a8

HandleCount: 15 PointerCount: 16

Directory Object: fcebfab0 Name: NlsCacheMutant

002c: Object: fcdb99a0 GrantedAccess: 00100003

Object: fcdb99a0 Type: (fcebf420) Event

ObjectHeader: fcdb9988

HandleCount: 1 PointerCount: 1

You can also, instead of using 0, specify an actual handle value to just list one handle.

kd> !handle 2c ff fcdbe2c0

processor number 0

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

DirBase: 0401d000 ObjectTable: fcdc39c8 TableSize: 354.

Image: winlogon.exe

Handle Table at e1b78000 with 354 Entries in use

002c: Object: fcdb99a0 GrantedAccess: 00100003

Object: fcdb99a0 Type: (fcebf420) Event

ObjectHeader: fcdb9988

HandleCount: 1 PointerCount: 1

There are other methods to dump the object. You notice there's an Object: and an address, !object can also be used on that address. All the kernel debugger really does when finding handle information is look for that ObjectTable address, and find the handle table, then just dump the information since it knows the data structure.

Let's attempt to interpret this table manually. First, the ObjectTable is at fcdc39c8.

kd> dc fcdc39c8

fcdc39c8 00000000 00000162 e1b78000 fcdbe2c0 ....b...........

fcdc39d8 000000a4 0000016f 00000300 fcdbe0a8 ....o...........

fcdc39e8 fcdbe5a8 00000000 00000000 00000000 ................

fcdc39f8 00000000 00000000 00000000 00000000 ................

fcdc3a08 00000000 00000000 00000000 00000000 ................

fcdc3a18 00000000 fcdb079c fcdc42bc 00040000 .........B......

fcdc3a28 00000000 fcdc3a2c fcdc3a2c 0030005c ....,:..,:..\.0.

fcdc3a38 00300030 00000030 07018004 69436d4d 0.0.0.......MmCi

kd> ? 162

Evaluate expression: 354 = 00000162

You notice that I dumped a variable that basically specified the number of handles in use. You also notice that the next value is the address that !handle said was the handle table. Now, let's dump this.

kd> dc e1b78000

e1b78000 e1b78400 00000000 00000000 00000000 ................

e1b78010 00000000 00000000 00000000 00000000 ................

e1b78020 00000000 00000000 00000000 00000000 ................

e1b78030 00000000 00000000 00000000 00000000 ................

e1b78040 00000000 00000000 00000000 00000000 ................

e1b78050 00000000 00000000 00000000 00000000 ................

e1b78060 00000000 00000000 00000000 00000000 ................

e1b78070 00000000 00000000 00000000 00000000 ................

kd> dc e1b78400

e1b78400 e1b78800 e1d47000 e1d47800 00000000 .....p...x......

e1b78410 00000000 00000000 00000000 00000000 ................

e1b78420 00000000 00000000 00000000 00000000 ................

e1b78430 00000000 00000000 00000000 00000000 ................

e1b78440 00000000 00000000 00000000 00000000 ................

e1b78450 00000000 00000000 00000000 00000000 ................

e1b78460 00000000 00000000 00000000 00000000 ................

e1b78470 00000000 00000000 00000000 00000000 ................

kd> dc e1b78800

e1b78800 00000000 00000001 61267018 000f001f .........p&a....

e1b78810 7cdee148 00100003 7cdee108 00100003 H..|.......|....

e1b78820 7cdbe268 00100003 7cec6c38 00000003 h..|....8l.|....

e1b78830 7ccc3c72 00100020 7cdfb718 000f000f r<.| ......|....

e1b78840 7cdb9dc8 00100003 61b7be19 001f0001 ...|.......a....

e1b78850 7ceca3a8 00000001 7cdb9988 00100003 ...|.......|....

e1b78860 613f5ec8 000f003f 6125dcd8 000f001f .^?a?.....%a....

e1b78870 7cdb9809 001f0003 7cdc3778 0002000f ...|....x7.|....

Now, I dump the address and it looks like there's another address. So, I dump that and looks like there's 3 addresses now, so I dump the first one. What did I find? Well, I found what appears to be the "table". The second DWORD of every pair appears to match the access mask of the objects in order of the dump, if you look above. 000f001f, followed by 00100003, matches exactly. Now, how do the first numbers relate to the object? If I dump them, they are not valid addresses! There are a few ways we could approach this dilemma. The first would be to debug the kernel debugger and figure out where it's going to translate this. The second would be to make a call into the kernel with one of these objects and figure out what it's doing to translate them. The last would obviously be attempt everything we can think of to translate it back. Well, let's try something. Let's set a "ba r1" on one of those locations and hope Winlogon attempts to use it. We could also write our own application, but I'm a bit lazy. We need to find an object we think Winlogon will attempt to use often though.

I actually think it may be easier to do this with an application like Notepad. Find handles it has open, then set break points on those, and close it. It will need to close those handles!

We have already figured out that if this location is 0, it's a "free" handle.

Now, I've set 4 "BA R1 <address>" in the Notepad object table. We can only set a maximum of 4, so I randomly chose a few handles. I then close Notepad. I end up in a function called "ExMapHandleToPointer".

eax=e1dfb8f0 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0

eip=804b3971 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl zr na po nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246

nt!ExLockHandleTableEntry+0xe:

804b3971 85f6 test esi,esi

kd>; p;r

eax=e1dfb8f0 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0

eip=804b3973 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000202

nt!ExLockHandleTableEntry+0x10:

804b3973 8975f8 mov [ebp-0x8],esi ss:0010:fb6e6b00=e1dfb800

kd>;

eax=e1dfb8f0 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0

eip=804b3976 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000202

nt!ExLockHandleTableEntry+0x13:

804b3976 0f8449f0ffff je nt!ExLockHandleTableEntry+0x5c (804b29c5) [br=0]

kd>;

eax=e1dfb8f0 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0

eip=804b397c esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000202

nt!ExLockHandleTableEntry+0x15:

804b397c 0f8eabdb0000 jle nt!ExLockHandleTableEntry+0x31 (804c152d) [br=0]

kd>;

eax=e1dfb8f0 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0

eip=804b3982 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000202

nt!ExLockHandleTableEntry+0x17:

804b3982 8bc6 mov eax,esi

kd>;

eax=61caf508 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0

eip=804b3984 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000202

nt!ExLockHandleTableEntry+0x19:

804b3984 0d00000080 or eax,0x80000000

kd>;

eax=e1caf508 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0

eip=804b3989 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei ng nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000282

nt!ExLockHandleTableEntry+0x1e:

804b3989 8945fc mov [ebp-0x4],eax ss:0010:fb6e6b04=e1dfb800

kd>;

eax=e1caf508 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0

eip=804b398c esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei ng nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000282

nt!ExLockHandleTableEntry+0x21:

804b398c 8b45f8 mov eax,[ebp-0x8] ss:0010:fb6e6b00=61caf508

kd>;

eax=61caf508 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0

eip=804b398f esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei ng nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000282

nt!ExLockHandleTableEntry+0x24:

804b398f 8b4d0c mov ecx,[ebp+0xc] ss:0010:fb6e6b14=e1dfb8f0

kd>;

eax=61caf508 ebx=00000000 ecx=e1dfb8f0 edx=00000000 esi=61caf508 edi=fb6e6bd0

eip=804b3992 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei ng nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000282

nt!ExLockHandleTableEntry+0x27:

804b3992 8b55fc mov edx,[ebp-0x4] ss:0010:fb6e6b04=e1caf508

kd>;

eax=61caf508 ebx=00000000 ecx=e1dfb8f0 edx=e1caf508 esi=61caf508 edi=fb6e6bd0

eip=804b3995 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei ng nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000282

nt!ExLockHandleTableEntry+0x2a:

804b3995 0fb111 cmpxchg [ecx],edx ds:0023:e1dfb8f0=61caf508

kd>;

Breakpoint 1 hit

eax=61caf508 ebx=00000000 ecx=e1dfb8f0 edx=e1caf508 esi=61caf508 edi=fb6e6bd0

eip=804b3998 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl zr na po nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246

nt!ExLockHandleTableEntry+0x2d:

804b3998 3bc6 cmp eax,esi

kd>;

eax=61caf508 ebx=00000000 ecx=e1dfb8f0 edx=e1caf508 esi=61caf508 edi=fb6e6bd0

eip=804b399a esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl zr na po nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246

nt!ExLockHandleTableEntry+0x2f:

804b399a 0f858ddb0000 jne nt!ExLockHandleTableEntry+0x31 (804c152d) [br=0]

kd>;

eax=61caf508 ebx=00000000 ecx=e1dfb8f0 edx=e1caf508 esi=61caf508 edi=fb6e6bd0

eip=804b39a0 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl zr na po nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246

nt!ExLockHandleTableEntry+0x60:

804b39a0 b001 mov al,0x1

kd>;

eax=61caf501 ebx=00000000 ecx=e1dfb8f0 edx=e1caf508 esi=61caf508 edi=fb6e6bd0

eip=804b39a2 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl zr na po nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246

nt!ExLockHandleTableEntry+0x62:

804b39a2 5e pop esi

kd>;

eax=61caf501 ebx=00000000 ecx=e1dfb8f0 edx=e1caf508 esi=e1dfb8f0 edi=fb6e6bd0

eip=804b39a3 esp=fb6e6afc ebp=fb6e6b08 iopl=0 nv up ei pl zr na po nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246

nt!ExLockHandleTableEntry+0x63:

804b39a3 5b pop ebx

kd>;

eax=61caf501 ebx=00000078 ecx=e1dfb8f0 edx=e1caf508 esi=e1dfb8f0 edi=fb6e6bd0

eip=804b39a4 esp=fb6e6b00 ebp=fb6e6b08 iopl=0 nv up ei pl zr na po nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246

nt!ExLockHandleTableEntry+0x64:

804b39a4 c9 leave

kd>;

eax=61caf501 ebx=00000078 ecx=e1dfb8f0 edx=e1caf508 esi=e1dfb8f0 edi=fb6e6bd0

eip=804b39a5 esp=fb6e6b0c ebp=fb6e6bc4 iopl=0 nv up ei pl zr na po nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246

nt!ExLockHandleTableEntry+0x65:

804b39a5 c20800 ret 0x8

kd>;

eax=61caf501 ebx=00000078 ecx=e1dfb8f0 edx=e1caf508 esi=e1dfb8f0 edi=fb6e6bd0

eip=804b3a17 esp=fb6e6b18 ebp=fb6e6bc4 iopl=0 nv up ei pl zr na po nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246

nt!ExMapHandleToPointer+0x1e:

804b3a17 f6d8 neg al

kd>;

eax=61caf5ff ebx=00000078 ecx=e1dfb8f0 edx=e1caf508 esi=e1dfb8f0 edi=fb6e6bd0

eip=804b3a19 esp=fb6e6b18 ebp=fb6e6bc4 iopl=0 nv up ei ng nz ac po cy

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000297

nt!ExMapHandleToPointer+0x20:

804b3a19 1bc0 sbb eax,eax

kd>;

eax=ffffffff ebx=00000078 ecx=e1dfb8f0 edx=e1caf508 esi=e1dfb8f0 edi=fb6e6bd0

eip=804b3a1b esp=fb6e6b18 ebp=fb6e6bc4 iopl=0 nv up ei ng nz ac po cy

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000297

nt!ExMapHandleToPointer+0x22:

804b3a1b 23c6 and eax,esi

kd>;

eax=e1dfb8f0 ebx=00000078 ecx=e1dfb8f0 edx=e1caf508 esi=e1dfb8f0 edi=fb6e6bd0

eip=804b3a1d esp=fb6e6b18 ebp=fb6e6bc4 iopl=0 nv up ei ng nz na po nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000286

nt!ExMapHandleToPointer+0x24:

804b3a1d 5e pop esi

kd>;

eax=e1dfb8f0 ebx=00000078 ecx=e1dfb8f0 edx=e1caf508 esi=00000000 edi=fb6e6bd0

eip=804b3a1e esp=fb6e6b1c ebp=fb6e6bc4 iopl=0 nv up ei ng nz na po nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000286

nt!ExMapHandleToPointer+0x25:

804b3a1e c20800 ret 0x8

kd>; !handle 78 ff fcc654e0

processor number 0

PROCESS fcc654e0 SessionId: 0 Cid: 03ac Peb: 7ffdf000 ParentCid: 02e0

DirBase: 03cc6000 ObjectTable: fcc59988 TableSize: 16.

Image: NOTEPAD.EXE

Handle Table at e1dfb000 with 16 Entries in use

0078: Object: e1caf520 GrantedAccess: 000f003f (Locked)

Object: e1caf520 Type: (fcebc160) Key

ObjectHeader: e1caf508

HandleCount: 1 PointerCount: 1

Directory Object: 00000000 Name: \REGISTRY\USER

So, what have we accomplished. We notice that we index into the handle table and find that weird number. That weird number is then replaced by the object header "e1caf508". The actual object is at ObjectHeader + 18h, so e1caf508 + 18 = e1caf520.

kd> !object e1caf520

Object: e1caf520 Type: (fcebc160) Key

ObjectHeader: e1caf508

HandleCount: 1 PointerCount: 1

Directory Object: 00000000 Name: \REGISTRY\USER

Now, what was the calculation to get to this? So simple, "or eax,0x80000000". Let's give it a try now on some of those other objects. We had 7cdee148, and we get fcdee148. Add 18h, and we should be able to !object.

kd> !object fcdee160

Object: fcdee160 Type: (fcebf420) Event

ObjectHeader: fcdee148

HandleCount: 1 PointerCount: 1

So, that's how simple it is.

Heap Information

The heap for a particular process can be displayed from kernel mode. Set your context to that process and dump the PEB. The PEB will point to the number of heaps and a heap list which can be used. Each heap then has a VirtualAlloc list that can be used as a linked list. This can all be done in usermode as well, nothing special here. The only difference is that you may not be able to display all of the information if it's paged out. Anyway, luckily you don't even have to go through all that. You can simply use !heap in the kernel! Just set your context and just use !heap as normal. You may refer back to Debug Tutorial Part 3 to learn more about heaps.

Pools

Kernel drivers generally use memory from the Paged and Non-Paged pool. You can take an address and do !pool to determine its size, tag information, etc. If you develop drivers, you know that when you allocate memory in the kernel, it comes from a global pool, not per-process. So if you corrupt memory, you can end up corrupting other drivers in the system. When a driver allocates memory, they generally specify a "pool tag" which is then associated with the memory. This is how we can tell what driver allocated what memory. There is also !poolfind * to find pool based on a pool tag. You can look online or other places to find information about a pool tag and what it relates to.

For example, let's do !pool on the objects we were handling before.

kd> !pool e1caf520

e1caf000 size: 60 previous size: 0 (Allocated) NtFd

e1caf060 size: 20 previous size: 60 (Free) ....

e1caf080 size: 40 previous size: 20 (Allocated) NtFs

e1caf0c0 size: 20 previous size: 40 (Free) Key

e1caf0e0 size: 20 previous size: 20 (Allocated) CMVI

e1caf100 size: 40 previous size: 20 (Allocated) CMVa

e1caf140 size: 20 previous size: 40 (Free) CMVa

e1caf160 size: 40 previous size: 20 (Lookaside) Key (Protected)

e1caf1a0 size: 20 previous size: 40 (Allocated) Ntf0

e1caf1c0 size: 40 previous size: 20 (Allocated) IoNm

e1caf200 size: 20 previous size: 40 (Free) Gla8

e1caf220 size: 40 previous size: 20 (Allocated) CMVa

e1caf260 size: 40 previous size: 40 (Allocated) CMVa

e1caf2a0 size: 20 previous size: 40 (Free) Key

e1caf2c0 size: 60 previous size: 20 (Allocated) Ntfo

e1caf320 size: 40 previous size: 60 (Allocated) CMNb (Protected)

e1caf360 size: 40 previous size: 40 (Allocated) CMIn (Protected)

e1caf3a0 size: a0 previous size: 40 (Allocated) SeSd

e1caf440 size: 20 previous size: a0 (Free) Usqm

e1caf460 size: 40 previous size: 20 (Allocated) CMVa

e1caf4a0 size: 40 previous size: 40 (Allocated) CMVa

e1caf4e0 size: 20 previous size: 40 (Allocated) Ntf0

*e1caf500 size: 40 previous size: 20 (Allocated) *Key (Protected)

e1caf540 size: 20 previous size: 40 (Free) Gla8

e1caf560 size: 40 previous size: 20 (Allocated) CMVa

e1caf5a0 size: 20 previous size: 40 (Free) SYSA

e1caf5c0 size: 20 previous size: 20 (Allocated) CMNb (Protected)

e1caf5e0 size: 40 previous size: 20 (Allocated) CMNb (Protected)

e1caf620 size: 40 previous size: 40 (Allocated) CMNb (Protected)

e1caf660 size: a0 previous size: 40 (Allocated) CMDa

e1caf700 size: 40 previous size: a0 (Allocated) NtFL

e1caf740 size: 40 previous size: 40 (Allocated) CMNb (Protected)

e1caf780 size: a0 previous size: 40 (Allocated) MmSt

e1caf820 size: 40 previous size: a0 (Allocated) CMNb (Protected)

e1caf860 size: 20 previous size: 40 (Allocated) ObDi

e1caf880 size: 20 previous size: 20 (Free) CMDa

e1caf8a0 size: 20 previous size: 20 (Allocated) CMVI

e1caf8c0 size: 40 previous size: 20 (Allocated) IoNm

e1caf900 size: 80 previous size: 40 (Allocated) FSim

e1caf980 size: 20 previous size: 80 (Free) MmSt

e1caf9a0 size: 60 previous size: 20 (Allocated) CMDa

e1cafa00 size: 3e0 previous size: 60 (Allocated) NtfF

e1cafde0 size: 60 previous size: 3e0 (Allocated) CMDa

e1cafe40 size: 40 previous size: 60 (Allocated) CMVa

e1cafe80 size: 40 previous size: 40 (Allocated) CMVa

e1cafec0 size: 80 previous size: 40 (Allocated) FSim

e1caff40 size: 40 previous size: 80 (Allocated) Key (Protected)

e1caff80 size: 80 previous size: 40 (Allocated) Gla@

The Kernel Debugger will display the allocation with an "*". All the kernel debugger does is it takes the address, and takes off the last 3 numbers and replace them with 0. In this case, e1caf520, became e1caf000. It then simply walks the pool from there. It's a linked list, just like the user mode heap, except it doesn't go by pointer links but rather by size links. The sizes point forward and backward. In the above case, the sizes are shifted by 5, and the sizes are represented by bytes. Take the last allocation for example.

kd> db e1caff80

e1caff80 02 81 02 04 47 6c 61 40-59 01 10 08 00 00 00 00 ....Gla@Y.......

e1caff90 00 00 00 80 00 00 00 00-07 00 00 00 00 00 00 00 ................

e1caffa0 00 00 00 00 14 00 00 80-8b 00 00 00 f0 00 75 00 ..............u.

e1caffb0 00 00 00 00 d4 d0 c8 00-00 00 00 00 00 00 00 00 ................

e1caffc0 01 00 00 00 00 00 00 00-ff ff ff 00 04 00 00 00 ................

e1caffd0 08 00 00 00 c8 d0 d4 00-00 00 00 00 d4 d0 c8 00 ................

e1caffe0 01 05 00 00 00 00 00 05-15 00 00 00 85 e7 7e 2f ..............~/

e1cafff0 23 f3 f6 63 f8 9f b4 74-01 02 00 00 00 00 00 00 #..c...t........

kd> ? 02 << 5

Evaluate expression: 64 = 00000040

kd> ? 04 << 5

Evaluate expression: 128 = 00000080

The flags in the middle specify a SHORT that tells whether the allocation is free or used, for example. The tag is the next 4 bytes, and then is the allocated memory. 8 byte header, just like in user mode. (Of course, there is a large header in usermode for large allocations in the "VirtualAlloc" list of the heap.) Of course, the kernel can allocate large blocks of memory as well in the pool, how does that work? You just get a few pages of memory not allocated from a pool, you get your own address that looks like "e1caf000", and unlike doing this in usermode that has a 32 byte header information with size, there is no header information.

Ready Threads

Ready threads are threads that are ready to be executed, in a READY state as opposed to a WAIT state.

kd> !ready 0

Ready Threads at priority 0

THREAD fcebf020 Cid 8.4 Teb: 00000000 Win32Thread: 00000000 READY

Just !ready will display the entire thread information. In Windows XP/2003, there is also a !running which will show the currently running threads on multiprocessor systems. Also, ~<number><NUMBER>s in the usermode debugger switches between threads, in the kernel debugger it switches between processors.

CPU ID

There are other things you can do like !cpuid.

kd> !cpuid

CP F/M/S Manufacturer MHz

0 5,8,12 AuthenticAMD 350

Virtual Memory Usage

To display memory usage, you can use !vm.

kd> !vm

*** Virtual Memory Usage ***

Physical Memory: 31613 ( 126452 Kb)

Page File: \??\C:\pagefile.sys

Current: 184320Kb Free Space: 180464Kb

Minimum: 184320Kb Maximum: 368640Kb

Available Pages: 17617 ( 70468 Kb)

ResAvail Pages: 26203 ( 104812 Kb)

Modified Pages: 543 ( 2172 Kb)

NonPagedPool Usage: 677 ( 2708 Kb)

NonPagedPool Max: 12528 ( 50112 Kb)

PagedPool 0 Usage: 2993 ( 11972 Kb)

PagedPool 1 Usage: 439 ( 1756 Kb)

PagedPool 2 Usage: 451 ( 1804 Kb)

PagedPool Usage: 3883 ( 15532 Kb)

PagedPool Maximum: 25600 ( 102400 Kb)

Shared Commit: 324 ( 1296 Kb)

Special Pool: 0 ( 0 Kb)

Free System PTEs: 14442 ( 57768 Kb)

Shared Process: 1125 ( 4500 Kb)

PagedPool Commit: 3883 ( 15532 Kb)

Driver Commit: 912 ( 3648 Kb)

Committed pages: 11945 ( 47780 Kb)

Commit limit: 73862 ( 295448 Kb)

Total Private: 5662 ( 22648 Kb)

00a4 winlogon.exe 1358 ( 5432 Kb)

00d8 services.exe 587 ( 2348 Kb)

02e4 explorer.exe 557 ( 2228 Kb)

01b4 SPOOLSV.EXE 503 ( 2012 Kb)

00e4 lsass.exe 446 ( 1784 Kb)

01e8 svchost.exe 412 ( 1648 Kb)

00a8 csrss.exe 329 ( 1316 Kb)

0374 mspaint.exe 303 ( 1212 Kb)

008c smss.exe 273 ( 1092 Kb)

018c svchost.exe 227 ( 908 Kb)

0290 winvnc.exe 164 ( 656 Kb)

0264 winmgmt.exe 154 ( 616 Kb)

02e0 cmd.exe 143 ( 572 Kb)

0228 mstask.exe 141 ( 564 Kb)

0210 regsvc.exe 59 ( 236 Kb)

0008 System 6 ( 24 Kb)

If you're looking for "is the system out of memory", you basically want to look at the "committed pages" versus the "commit limit". The committed pages are how much memory is currently being used and the commit limit is how much total memory can be used.

The next tool that can be used is !memusage which builds a map of all memory mapped files on the system.

kd> !memusage

loading PFN database

loading (99% complete)

Zeroed: 3163 ( 12652 kb)

Free: 20 ( 80 kb)

Standby: 14434 ( 57736 kb)

Modified: 543 ( 2172 kb)

ModifiedNoWrite: 0 ( 0 kb)

Active/Valid: 13567 ( 54268 kb)

Transition: 0 ( 0 kb)

Unknown: 0 ( 0 kb)

TOTAL: 31727 (126908 kb)

Building kernel map

Finished building kernel map

Usage Summary (in Kb):

Control Valid Standby Dirty Shared Locked PageTables name

fce7a3c8 468 16776 0 0 0 0 No Name for File

fccf6148 0 2876 0 0 0 0 mapped_file( CIM.REP )

fcd43388 0 96 0 0 0 0 mapped_file( chord.wav )

fcc40568 0 48 0 0 0 0 mapped_file( index.dat )

fcc64308 0 2420 0 0 0 0 mapped_file( mshtml.dll )

fcce8b28 0 188 0 0 0 0 mapped_file( rasppp.dll )

fcc76728 0 208 0 0 0 0 mapped_file( h323.tsp )

fccec3c8 220 92 0 0 0 0 mapped_file( netcfgx.dll )

fce48e88 1152 180 0 0 0 0 mapped_file( win32k.sys )

fcde4f28 16 460 0 0 0 0 mapped_file( wininet.dll )

fcc7f808 0 32 0 0 0 0 mapped_file( wbemcomn.dll )

fcc4d7a8 0 388 0 0 0 0 mapped_file( ntvdm.exe )

fcceb128 80 200 0 0 0 0 mapped_file( rasdlg.dll )

fcde5a08 200 896 0 120 0 0 mapped_file( shell32.dll )

fceca188 3196 1280 0 0 0 0 No Name for File

fccecd88 108 36 0 0 0 0 mapped_file( tapisrv.dll )

fcda5a28 8 204 0 0 0 0 mapped_file( msgina.dll )

fcc83348 0 300 0 0 0 0 mapped_file( wbemess.dll )

fcce9248 40 756 0 0 0 0 mapped_file( shdocvw.dll )

fcd10a68 0 32 0 0 0 0 mapped_file( notepad.exe )

fcd7dd08 0 504 0 0 0 0 mapped_file( jscript.dll )

fcc7cc48 0 32 0 0 0 0 mapped_file( mswsock.dll )

fcc4a4a8 0 116 0 0 0 0 mapped_file( dxtmsft.dll )

fcce95e8 32 40 0 0 0 0 mapped_file( ntmarta.dll )

fcce89a8 0 12 0 0 0 0 mapped_file( ntlsapi.dll )

fcc821a8 0 68 0 0 0 0 mapped_file( modemui.dll )

fcc7a4e8 16 196 0 0 0 0 mapped_file( msi.dll )

fccec688 112 32 0 0 0 0 mapped_file( rasmans.dll )

fcc4ea68 240 64 0 0 0 0 mapped_file( mspaint.exe )

fcd64ba8 0 32 0 0 0 0 mapped_file( tapisrv.dll )

fcde4aa8 0 36 0 0 0 0 mapped_file( mpr.dll )

fcdc33a8 164 64 0 0 0 0 mapped_file( winsrv.dll )

fcceeb08 0 32 0 0 0 0 mapped_file( wkssvc.dll )

fccf3ee8 0 32 0 0 0 0 mapped_file( winlogon.exe )

fcc54a28 112 36 0 0 0 0 mapped_file( cmd.exe )

fcc60408 0 148 0 0 0 0 mapped_file( dxtrans.dll )

fccee4a8 0 32 0 0 0 0 mapped_file( cryptsvc.dll )

fcc7fe08 0 32 0 0 0 0 mapped_file( SPOOLSV.EXE )

fcd7e788 80 512 0 0 0 0 mapped_file( browseui.dll )

fcc7ed28 0 0 4 0 0 0 mapped_file( software.LOG )

fcc7f128 40 264 0 8 0 0 mapped_file( netshell.dll )

fcc51ac8 0 32 0 0 0 0 mapped_file( jscript.dll )

...

-------- 12 0 0 ----- ----- 8 pagefile section (78a7)

-------- 456 0 0 ----- ----- 72 process ( mstask.exe )

-------- 452 536 116 ----- ----- 92 process ( lsass.exe )

-------- 140 0 0 ----- ----- 28 process ( smss.exe )

-------- 88 452 0 ----- ----- 52 process ( winmgmt.exe )

-------- 236 0 0 ----- ----- 36 process ( regsvc.exe )

-------- 520 0 0 ----- ----- 72 process ( winvnc.exe )

-------- 12 0 0 ----- ----- 8 pagefile section (6933)

-------- 1320 100 0 ----- 0 ----- driver ( ntoskrnl.exe )

-------- 60 16 0 ----- 0 ----- driver ( hal.dll )

...

As you can see, all files that are loaded in the system are loaded as memory mapped files. This means the Operating System uses the copy on disk to continuously load it into memory. It doesn't copy it into memory and then put it in the page file. To get information on one of these memory mapped files, such as how many references are currently being mapped, etc., use !ca.

kd> !ca fcdee008

ControlArea @fcdee008

Segment: e1b764c8 Flink 0 Blink: 0

Section Ref 1 Pfn Ref 1e Mapped Views: 1

User Ref 2 Subsections 4 Flush Count: 0

File Object fcdbe728 ModWriteCount 0 System Views: 0

WaitForDel 0 Paged Usage 100 NonPaged Usage c0

Flags (90000a0) Image File HadUserReference Accessed

File: \WINNT\system32\winlogon.exe

Segment @ e1b764c8:

ControlArea fcdee008 Total Ptes 0 NonExtendPtes: 2d

WriteUserRef 2d Extend Info 0 SizeOfSegment: 2d000

Image Base 0 Committed e1b765b8 Based Addr 2d36f438

PTE Template: 3

Image commit 1000000 Image Info: 0

ProtoPtes e1b76500

Subsection 1. @ fcdee040

ControlArea: fcdee008 Starting Sector 0 Number Of Sectors 2

Base Pte e1b76500 Ptes In subsect 1 Unused Ptes 0

Flags 15 Sector Offset 0 Protection 1

ReadOnly SubsectionStatic

Subsection 2. @ fcdee060

ControlArea: fcdee008 Starting Sector 2 Number Of Sectors ff

Base Pte e1b76504 Ptes In subsect 20 Unused Ptes 0

Flags 35 Sector Offset 0 Protection 3

ReadOnly SubsectionStatic

Subsection 3. @ fcdee080

ControlArea: fcdee008 Starting Sector 101 Number Of Sectors 11

Base Pte e1b76584 Ptes In subsect 3 Unused Ptes 0

Flags 55 Sector Offset 0 Protection 5

ReadOnly SubsectionStatic

Subsection 4. @ fcdee0a0

ControlArea: fcdee008 Starting Sector 112 Number Of Sectors 48

Base Pte e1b76590 Ptes In subsect 9 Unused Ptes 0

Flags 15 Sector Offset 0 Protection 1

ReadOnly SubsectionStatic

You will notice there is only one mapped view for Winlogon on this machine. Don't worry if it says 0 views and the process is running; look on the list, there may be two listings for that file and the other one is the mapview being used.

Conclusion

This is a simple introduction to the kernel debugger and a few things that you can do. While I haven't covered everything, I hope that you now know at least the basics and can navigate it. There's always the help and http://www.google.com/! You learn something new everyday; one person can't know everything, but they can try! I tried to make sure the information presented is as accurate as possible, but things can get through, so let me know if I missed something or misrepresented something. I may add more Kernel Debugging tutorials in the future, with other topics. We didn't even cover IRPs!

You usually don't end up working with every single detail in the listing. You usually end up using a bunch of different commands to get different information, and each command you may only ever use a subset of the data, and this is fine. You may not even care what the other data is or even know what it is. Perhaps even if you know what it is, it would never be useful to you. So, don't get discouraged if you don't know what a piece of displayed information is or if you can't find any references to it online. If you really need to know though, you could always set ba's on the address and track down who's using it for what.

About Toby Opferman

 
特别声明:以上内容(如有图片或视频亦包括在内)为网络用户发布,本站仅提供信息存储服务。
 
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 "[url=http://www.codeproject.com/debug/cdbntsd.asp]Debug Tutorial Part 1[/url]". /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 [url=http://www.vmware.com/support/gsx3/doc/devices_serial_debug_gsx.html]VMWare[/url]. 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 "[url=http://www.codeproject.com/debug/cdbntsd.asp]Debug Tutorial Part 1[/url]". 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 or 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 or !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 <DirBase>, you can use .trap <trap address>, 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 = <NO type information> 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 <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) 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 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, let's take a look at each piece of header information. We remember from before that the process address was actually an EPROCESS structure. Well, this is an ETHREAD structure. This can be displayed by using dt nt!_ETHREAD <address> or !threadfields. So, let's break it down. THREAD fcdbd020 Cid a4.84 Teb: 7ffde000 Win32Thread: e1b7b8e8 WAIT: (WrUserRequest) UserMode Non-Alertable fcdb9820 SynchronizationEvent The first address is the address of the ETHREAD structure as we mentioned. The second is the Process.Thread ID. The process ID is A4h, the thread ID is 84h. Thread IDs are useful when looking at deadlocks since the synchronization objects are owned by threads. It's also good when looking for window information as each window is owned by a particular thread. These thread IDs are available in the user mode debugger. The TEB. The Thread Environment Block is as mentioned in a previous tutorial. This has thread specific information as well as it points to the PEB, so threads can easily access certain information. The stack limit and end is here as well. !teb or dt _TEB <address>. You obviously need to be in the context of the process and thread to use !teb. If the TEB is NULL, this means it's a system thread. The thread is only executing in the kernel, it's not a user mode thread. The next is the "Win32Thread". What's this? This is a per-thread data structure that WIN32k.SYS maintains. The last part is the state of the thread. This thread is in a wait state. It's waiting in a non-alertable state in usermode. For more information on alertable, non-alertable, kernel verse. usermode waits, please refer to MSDN's articles about KeWaitForMultipleObjects or information about APC (Asynchronous Procedure Calls). Not impersonating Whether this thread is impersonating or not. If you are familar with RPC, the server can impersonate the caller to perform operations on the caller's behalf or get information about the caller. If this thread was impersonating, you would see an impersonation token here which you could do !token <address> on to get the information. Certain calls into the kernel will look at this impersonation token if it is there and use it instead of the process' user token. Owning Process fcdbe2c0 The own process' EPROCESS address. In this case, it's Winlogon. You may see weird things sometimes where a thread seems to have a different owner than it's being displayed in. The kernel may call KeAttachProcess() to perform actions in a different context. Wait Start TickCount 49551906 Elapsed Ticks: 14128 Context Switch Count 3360 LargeStack UserTime 0:00:00.0290 KernelTime 0:00:01.0041 Time this thread spent in usermode and kernel mode. If you are looking for a process hog, these are the values you look at to find the process, then the thread. "Elapsed Ticks" is how long it's been since this thread was executed. If you're looking for a hog right after it happened, this is another field to look at, what threads have the least elapsed ticks. Start Address winlogon!WinMainCRTStartup (0x01001674) This is the starting address of the thread. Stack Init f7660000 Current f765fcc8 Base f7660000 Limit f765d000 Call 0 This refers to the kernel stack, not the user mode stack which can be found in the TEB. The current position of the kernel mode stack and its limits, and where it started. Priority 15 BasePriority 15 PriorityDecrement 0 DecrementCount 0 The priority of this thread. You may see other things, but this is a basic listing. If you notice an LPC, you can do things like "!lpc message <message id>" to get the originator of the call if they are still around, for example. Now that we are in the context, we can do things like set break points, change memory, etc. Just remember that changing memory in a driver will change this memory for everyone. Setting breakpoints is the same way, you set the breakpoint for everyone on the system. This is a kernel debugger and the kernel mode drivers are global to the system (or the session, for other certain drivers we will not cover here). What else can I do? There're a lot of things that you can do, but like I mentioned before, we will just be covering some of the basics. It also depends on the area that you work in. For example, someone who is developing hardware drivers may never use or even look at anything in usermode or even that high up the driver stack. They may only know some of the hardware commands. Someone who only works with usermode applications or interaction may only use the kernel debugger for some extra information, or figure out who's calling with an RPC, etc. Page Table Entries The only problem with using the kernel debugger or kernel dump is that some information may not be there, it may be paged out. So, how can we tell if memory is valid or paged out? In the x86 processor, there are levels of indirection when it comes to translating a virtual address to a physical address. There is a Page Directory Entry that points to a Page Table Entry. If you want to find the Page Table Entry, this is how you can do it. Remember, we already know how to find physical addresses for virtual addresses using the page directory of the process. !pte is the answer to find Page Table Entries. kd> !pte 80461691 80461691 - PDE at C0300804 PTE at C0201184 contains 00034163 contains 00461121 pfn 34 G-DA--KWV pfn 461 G--A--KRV kd> dc C0300804 L1 c0300804 00034163 kd> dc C0201184 L1 c0201184 00461121 Just to show, if you dc those addresses, that's what you get. The Virtual Address is first added to the GDT/LDT and then it's translated. Part of the Virtual Address is taken as an offset to get the Page Directory Entry. Then next part of the Address is taken to get the Page Entry Table. The last 3 nibbles of the virtual address are actually the last 3 nibbles of where the PTE points to. So, the PTE says 461xxx is the physical address. Let's find out and dump the virtual and physical addresses: kd> !dc 461691 # 461690 8be58bd3 dff1240d 3c558bff 01289189 .....$....U<..(. # 4616a0 f7fa0000 00007045 06750002 016c45f6 ....Ep....u..El. # 4616b0 1d8b5874 ffdff124 002e43c6 004a7b80 tX..$....C...{J. # 4616c0 dd8b4874 c7444389 003b5043 43c70000 tH...CD.CP;....C # 4616d0 00002338 3443c700 00000023 003043c7 8#....C4#....C0. # 4616e0 b9000000 00000001 059815ff fb508040 ............@.P. # 4616f0 6a006a53 f132e801 ff59fffc 40059c15 Sj.j..2...Y....@ # 461700 44438b80 90abebfa 548bff8b 8b644c24 ..CD.......T$Ld. kd> dc 80461691 80461691 0d8be58b ffdff124 893c558b 00012891 ....$....U<..(.. 804616a1 45f7fa00 02000070 f6067500 74016c45 ...Ep....u..El.t 804616b1 241d8b58 c6ffdff1 80002e43 74004a7b X..$....C...{J.t 804616c1 89dd8b48 43c74443 00003b50 3843c700 H...CD.CP;....C8 804616d1 00000023 233443c7 c7000000 00003043 #....C4#....C0.. 804616e1 01b90000 ff000000 40059815 53fb5080 ...........@.P.S 804616f1 016a006a fcf132e8 15ff59ff 8040059c j.j..2...Y....@. 80461701 fa44438b 8b90abeb 24548bff 1d8b644c .CD.......T$Ld.. As you can see, it's true. The Physical Address dump is a little different as it dumped it at the start of the memory rather than 1 so it was aligned, but you can see it's the same information. If we had dumped them "dc 80461690", you would see they are the same. You can also go backwards, take a PTE address, and find the virtual address it belongs to. kd> !pte C0201184 80461000 - PDE at C0300804 PTE at C0201184 contains 00034163 contains 00461121 pfn 34 G-DA--KWV pfn 461 G--A--KRV What happens on invalid addresses? kd> !pte 40 00000040 - PDE at C0300000 PTE at C0000000 contains 01800067 contains 00000000 pfn 1800 --DA--UWV not valid kd> dc C0300000 L1 c0300000 01800067 kd> dc C0000000 L1 c0000000 00000000 kd> !pte 66740020 66740020 - PDE at C0300664 PTE at C0199D00 contains 00000000 unavailable kd> dc C0300664 L1 c0300664 00000000 kd> dc C0199D00 L1 c0199d00 00a8d4c0 "Not Valid" means it's not a valid virtual address. (Some addresses may be "not valid" just because they have never been used yet, so they're not mapped I have found, at least that's my theory! For example, stack memory is mapped into your process but it's never been dirty, so why put it in the page file?) "Unavailable" means it's not available, but it is valid or it believes it to be. Otherwise, the address is valid. Sometimes, if an address is "unavailable", it will list a pagefile offset, and sometimes it will not. Executables and binaries are done using memory mapped files. You can see this by doing !memusage. That means that these, unless modified, would not be in the pagefile, and thus there is no pagefile offset. There is also a !sysptes that can dump all system ptes. Handle Information Displaying handle information in the kernel is easy. Once you set your context to the correct process, just !handle as you do in user mode, with an exception. You need to specify the process to dump the handles. kd> !handle 0 0 fcdbe2c0 processor number 0 PROCESS fcdbe2c0 SessionId: 0 Cid: 00a4 Peb: 7ffdf000 ParentCid: 008c DirBase: 0401d000 ObjectTable: fcdc39c8 TableSize: 354. Image: winlogon.exe Handle Table at e1b78000 with 354 Entries in use 0004: Object: e1267030 GrantedAccess: 000f001f 0008: Object: fcdee160 GrantedAccess: 00100003 000c: Object: fcdee120 GrantedAccess: 00100003 0010: Object: fcdbe280 GrantedAccess: 00100003 The first is the handle # used in usermode. The second is the "Object" or kernel address of the object, and the last is the access granted to the object. You may also specify flags to dump more information as seen below: kd> !handle 0 ff fcdbe2c0 processor number 0 PROCESS fcdbe2c0 SessionId: 0 Cid: 00a4 Peb: 7ffdf000 ParentCid: 008c DirBase: 0401d000 ObjectTable: fcdc39c8 TableSize: 354. Image: winlogon.exe Handle Table at e1b78000 with 354 Entries in use 0000: free handle 0004: Object: e1267030 GrantedAccess: 000f001f Object: e1267030 Type: (fcebc580) Section ObjectHeader: e1267018 HandleCount: 1 PointerCount: 1 0008: Object: fcdee160 GrantedAccess: 00100003 Object: fcdee160 Type: (fcebf420) Event ObjectHeader: fcdee148 HandleCount: 1 PointerCount: 1 000c: Object: fcdee120 GrantedAccess: 00100003 Object: fcdee120 Type: (fcebf420) Event ObjectHeader: fcdee108 HandleCount: 1 PointerCount: 1 0010: Object: fcdbe280 GrantedAccess: 00100003 Object: fcdbe280 Type: (fcebf420) Event ObjectHeader: fcdbe268 HandleCount: 1 PointerCount: 1 0014: Object: fcec6c50 GrantedAccess: 00000003 Object: fcec6c50 Type: (fcee4b40) Directory ObjectHeader: fcec6c38 HandleCount: 15 PointerCount: 44 Directory Object: fcebfab0 Name: KnownDlls HashBucket[ 00 ]: e137ca00 Section 'gdi32.dll' e134b900 Section 'imagehlp.dll' e13154a0 Section 'url.dll' HashBucket[ 02 ]: e13dee00 Section 'MPR.dll' HashBucket[ 03 ]: e135b040 Section 'ole32.dll' e135d2a0 Section 'urlmon.dll' HashBucket[ 04 ]: e1373600 Section 'lz32.dll' e138bde0 Section 'olesvr32.dll' HashBucket[ 06 ]: e137ef40 Section 'shell32.dll' e12c7880 Section 'wldap32.dll' HashBucket[ 09 ]: e13126e0 Section 'user32.dll' e13118a0 Section 'version.dll' HashBucket[ 10 ]: e135af80 Section 'olecli32.dll' HashBucket[ 14 ]: e13713e0 Section 'MSASN1.DLL' HashBucket[ 16 ]: e1314c60 Section 'COMCTL32.DLL' fcde6c50 SymbolicLink 'KnownDllPath' HashBucket[ 17 ]: e13171c0 Section 'CRYPT32.dll' HashBucket[ 18 ]: e1316e60 Section 'advapi32.dll' e13583a0 Section 'oleaut32.dll' HashBucket[ 19 ]: e135c980 Section 'SHLWAPI.DLL' e12c2fc0 Section 'wow32.dll' e1316460 Section 'olecnv32.dll' HashBucket[ 23 ]: e131a520 Section 'comdlg32.dll' HashBucket[ 26 ]: e1317b80 Section 'wininet.dll' HashBucket[ 27 ]: e12d5fc0 Section 'olethk32.dll' HashBucket[ 28 ]: e124c800 Section 'MSVCRT.DLL' HashBucket[ 31 ]: e134dbe0 Section 'rpcrt4.dll' HashBucket[ 32 ]: e130b460 Section 'kernel32.dll' 0018: Object: fccc3c88 GrantedAccess: 00100020 (Inherit) Object: fccc3c88 Type: (fced7c40) File ObjectHeader: fccc3c70 HandleCount: 1 PointerCount: 1 Directory Object: 00000000 Name: \WINNT\system32 {HarddiskVolume1} 001c: Object: fcdfb730 GrantedAccess: 000f000f Object: fcdfb730 Type: (fcee4b40) Directory ObjectHeader: fcdfb718 HandleCount: 14 PointerCount: 18 Directory Object: fcebfab0 Name: Windows HashBucket[ 04 ]: e1b76d40 Port 'SbApiPort' HashBucket[ 09 ]: e1b65a00 Port 'ApiPort' HashBucket[ 32 ]: fcdc1750 Directory 'WindowStations' 0020: Object: fcdb9de0 GrantedAccess: 00100003 Object: fcdb9de0 Type: (fcebf420) Event ObjectHeader: fcdb9dc8 HandleCount: 1 PointerCount: 1 0024: Object: e1b7be30 GrantedAccess: 001f0001 (Protected) Object: e1b7be30 Type: (fceb7640) Port ObjectHeader: e1b7be18 HandleCount: 1 PointerCount: 18 0028: Object: fceca3c0 GrantedAccess: 00000001 Object: fceca3c0 Type: (fcebda40) Mutant ObjectHeader: fceca3a8 HandleCount: 15 PointerCount: 16 Directory Object: fcebfab0 Name: NlsCacheMutant 002c: Object: fcdb99a0 GrantedAccess: 00100003 Object: fcdb99a0 Type: (fcebf420) Event ObjectHeader: fcdb9988 HandleCount: 1 PointerCount: 1 You can also, instead of using 0, specify an actual handle value to just list one handle. kd> !handle 2c ff fcdbe2c0 processor number 0 PROCESS fcdbe2c0 SessionId: 0 Cid: 00a4 Peb: 7ffdf000 ParentCid: 008c DirBase: 0401d000 ObjectTable: fcdc39c8 TableSize: 354. Image: winlogon.exe Handle Table at e1b78000 with 354 Entries in use 002c: Object: fcdb99a0 GrantedAccess: 00100003 Object: fcdb99a0 Type: (fcebf420) Event ObjectHeader: fcdb9988 HandleCount: 1 PointerCount: 1 There are other methods to dump the object. You notice there's an Object: and an address, !object can also be used on that address. All the kernel debugger really does when finding handle information is look for that ObjectTable address, and find the handle table, then just dump the information since it knows the data structure. Let's attempt to interpret this table manually. First, the ObjectTable is at fcdc39c8. kd> dc fcdc39c8 fcdc39c8 00000000 00000162 e1b78000 fcdbe2c0 ....b........... fcdc39d8 000000a4 0000016f 00000300 fcdbe0a8 ....o........... fcdc39e8 fcdbe5a8 00000000 00000000 00000000 ................ fcdc39f8 00000000 00000000 00000000 00000000 ................ fcdc3a08 00000000 00000000 00000000 00000000 ................ fcdc3a18 00000000 fcdb079c fcdc42bc 00040000 .........B...... fcdc3a28 00000000 fcdc3a2c fcdc3a2c 0030005c ....,:..,:..\.0. fcdc3a38 00300030 00000030 07018004 69436d4d 0.0.0.......MmCi kd> ? 162 Evaluate expression: 354 = 00000162 You notice that I dumped a variable that basically specified the number of handles in use. You also notice that the next value is the address that !handle said was the handle table. Now, let's dump this. kd> dc e1b78000 e1b78000 e1b78400 00000000 00000000 00000000 ................ e1b78010 00000000 00000000 00000000 00000000 ................ e1b78020 00000000 00000000 00000000 00000000 ................ e1b78030 00000000 00000000 00000000 00000000 ................ e1b78040 00000000 00000000 00000000 00000000 ................ e1b78050 00000000 00000000 00000000 00000000 ................ e1b78060 00000000 00000000 00000000 00000000 ................ e1b78070 00000000 00000000 00000000 00000000 ................ kd> dc e1b78400 e1b78400 e1b78800 e1d47000 e1d47800 00000000 .....p...x...... e1b78410 00000000 00000000 00000000 00000000 ................ e1b78420 00000000 00000000 00000000 00000000 ................ e1b78430 00000000 00000000 00000000 00000000 ................ e1b78440 00000000 00000000 00000000 00000000 ................ e1b78450 00000000 00000000 00000000 00000000 ................ e1b78460 00000000 00000000 00000000 00000000 ................ e1b78470 00000000 00000000 00000000 00000000 ................ kd> dc e1b78800 e1b78800 00000000 00000001 61267018 000f001f .........p&a.... e1b78810 7cdee148 00100003 7cdee108 00100003 H..|.......|.... e1b78820 7cdbe268 00100003 7cec6c38 00000003 h..|....8l.|.... e1b78830 7ccc3c72 00100020 7cdfb718 000f000f r<.| ......|.... e1b78840 7cdb9dc8 00100003 61b7be19 001f0001 ...|.......a.... e1b78850 7ceca3a8 00000001 7cdb9988 00100003 ...|.......|.... e1b78860 613f5ec8 000f003f 6125dcd8 000f001f .^?a?.....%a.... e1b78870 7cdb9809 001f0003 7cdc3778 0002000f ...|....x7.|.... Now, I dump the address and it looks like there's another address. So, I dump that and looks like there's 3 addresses now, so I dump the first one. What did I find? Well, I found what appears to be the "table". The second DWORD of every pair appears to match the access mask of the objects in order of the dump, if you look above. 000f001f, followed by 00100003, matches exactly. Now, how do the first numbers relate to the object? If I dump them, they are not valid addresses! There are a few ways we could approach this dilemma. The first would be to debug the kernel debugger and figure out where it's going to translate this. The second would be to make a call into the kernel with one of these objects and figure out what it's doing to translate them. The last would obviously be attempt everything we can think of to translate it back. Well, let's try something. Let's set a "ba r1" on one of those locations and hope Winlogon attempts to use it. We could also write our own application, but I'm a bit lazy. We need to find an object we think Winlogon will attempt to use often though. I actually think it may be easier to do this with an application like Notepad. Find handles it has open, then set break points on those, and close it. It will need to close those handles! We have already figured out that if this location is 0, it's a "free" handle. Now, I've set 4 "BA R1 <address>" in the Notepad object table. We can only set a maximum of 4, so I randomly chose a few handles. I then close Notepad. I end up in a function called "ExMapHandleToPointer". eax=e1dfb8f0 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0 eip=804b3971 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl zr na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246 nt!ExLockHandleTableEntry+0xe: 804b3971 85f6 test esi,esi kd>; p;r eax=e1dfb8f0 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0 eip=804b3973 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000202 nt!ExLockHandleTableEntry+0x10: 804b3973 8975f8 mov [ebp-0x8],esi ss:0010:fb6e6b00=e1dfb800 kd>; eax=e1dfb8f0 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0 eip=804b3976 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000202 nt!ExLockHandleTableEntry+0x13: 804b3976 0f8449f0ffff je nt!ExLockHandleTableEntry+0x5c (804b29c5) [br=0] kd>; eax=e1dfb8f0 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0 eip=804b397c esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000202 nt!ExLockHandleTableEntry+0x15: 804b397c 0f8eabdb0000 jle nt!ExLockHandleTableEntry+0x31 (804c152d) [br=0] kd>; eax=e1dfb8f0 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0 eip=804b3982 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000202 nt!ExLockHandleTableEntry+0x17: 804b3982 8bc6 mov eax,esi kd>; eax=61caf508 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0 eip=804b3984 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000202 nt!ExLockHandleTableEntry+0x19: 804b3984 0d00000080 or eax,0x80000000 kd>; eax=e1caf508 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0 eip=804b3989 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei ng nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000282 nt!ExLockHandleTableEntry+0x1e: 804b3989 8945fc mov [ebp-0x4],eax ss:0010:fb6e6b04=e1dfb800 kd>; eax=e1caf508 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0 eip=804b398c esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei ng nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000282 nt!ExLockHandleTableEntry+0x21: 804b398c 8b45f8 mov eax,[ebp-0x8] ss:0010:fb6e6b00=61caf508 kd>; eax=61caf508 ebx=00000000 ecx=e1dfb800 edx=00000000 esi=61caf508 edi=fb6e6bd0 eip=804b398f esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei ng nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000282 nt!ExLockHandleTableEntry+0x24: 804b398f 8b4d0c mov ecx,[ebp+0xc] ss:0010:fb6e6b14=e1dfb8f0 kd>; eax=61caf508 ebx=00000000 ecx=e1dfb8f0 edx=00000000 esi=61caf508 edi=fb6e6bd0 eip=804b3992 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei ng nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000282 nt!ExLockHandleTableEntry+0x27: 804b3992 8b55fc mov edx,[ebp-0x4] ss:0010:fb6e6b04=e1caf508 kd>; eax=61caf508 ebx=00000000 ecx=e1dfb8f0 edx=e1caf508 esi=61caf508 edi=fb6e6bd0 eip=804b3995 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei ng nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000282 nt!ExLockHandleTableEntry+0x2a: 804b3995 0fb111 cmpxchg [ecx],edx ds:0023:e1dfb8f0=61caf508 kd>; Breakpoint 1 hit eax=61caf508 ebx=00000000 ecx=e1dfb8f0 edx=e1caf508 esi=61caf508 edi=fb6e6bd0 eip=804b3998 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl zr na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246 nt!ExLockHandleTableEntry+0x2d: 804b3998 3bc6 cmp eax,esi kd>; eax=61caf508 ebx=00000000 ecx=e1dfb8f0 edx=e1caf508 esi=61caf508 edi=fb6e6bd0 eip=804b399a esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl zr na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246 nt!ExLockHandleTableEntry+0x2f: 804b399a 0f858ddb0000 jne nt!ExLockHandleTableEntry+0x31 (804c152d) [br=0] kd>; eax=61caf508 ebx=00000000 ecx=e1dfb8f0 edx=e1caf508 esi=61caf508 edi=fb6e6bd0 eip=804b39a0 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl zr na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246 nt!ExLockHandleTableEntry+0x60: 804b39a0 b001 mov al,0x1 kd>; eax=61caf501 ebx=00000000 ecx=e1dfb8f0 edx=e1caf508 esi=61caf508 edi=fb6e6bd0 eip=804b39a2 esp=fb6e6af8 ebp=fb6e6b08 iopl=0 nv up ei pl zr na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246 nt!ExLockHandleTableEntry+0x62: 804b39a2 5e pop esi kd>; eax=61caf501 ebx=00000000 ecx=e1dfb8f0 edx=e1caf508 esi=e1dfb8f0 edi=fb6e6bd0 eip=804b39a3 esp=fb6e6afc ebp=fb6e6b08 iopl=0 nv up ei pl zr na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246 nt!ExLockHandleTableEntry+0x63: 804b39a3 5b pop ebx kd>; eax=61caf501 ebx=00000078 ecx=e1dfb8f0 edx=e1caf508 esi=e1dfb8f0 edi=fb6e6bd0 eip=804b39a4 esp=fb6e6b00 ebp=fb6e6b08 iopl=0 nv up ei pl zr na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246 nt!ExLockHandleTableEntry+0x64: 804b39a4 c9 leave kd>; eax=61caf501 ebx=00000078 ecx=e1dfb8f0 edx=e1caf508 esi=e1dfb8f0 edi=fb6e6bd0 eip=804b39a5 esp=fb6e6b0c ebp=fb6e6bc4 iopl=0 nv up ei pl zr na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246 nt!ExLockHandleTableEntry+0x65: 804b39a5 c20800 ret 0x8 kd>; eax=61caf501 ebx=00000078 ecx=e1dfb8f0 edx=e1caf508 esi=e1dfb8f0 edi=fb6e6bd0 eip=804b3a17 esp=fb6e6b18 ebp=fb6e6bc4 iopl=0 nv up ei pl zr na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246 nt!ExMapHandleToPointer+0x1e: 804b3a17 f6d8 neg al kd>; eax=61caf5ff ebx=00000078 ecx=e1dfb8f0 edx=e1caf508 esi=e1dfb8f0 edi=fb6e6bd0 eip=804b3a19 esp=fb6e6b18 ebp=fb6e6bc4 iopl=0 nv up ei ng nz ac po cy cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000297 nt!ExMapHandleToPointer+0x20: 804b3a19 1bc0 sbb eax,eax kd>; eax=ffffffff ebx=00000078 ecx=e1dfb8f0 edx=e1caf508 esi=e1dfb8f0 edi=fb6e6bd0 eip=804b3a1b esp=fb6e6b18 ebp=fb6e6bc4 iopl=0 nv up ei ng nz ac po cy cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000297 nt!ExMapHandleToPointer+0x22: 804b3a1b 23c6 and eax,esi kd>; eax=e1dfb8f0 ebx=00000078 ecx=e1dfb8f0 edx=e1caf508 esi=e1dfb8f0 edi=fb6e6bd0 eip=804b3a1d esp=fb6e6b18 ebp=fb6e6bc4 iopl=0 nv up ei ng nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000286 nt!ExMapHandleToPointer+0x24: 804b3a1d 5e pop esi kd>; eax=e1dfb8f0 ebx=00000078 ecx=e1dfb8f0 edx=e1caf508 esi=00000000 edi=fb6e6bd0 eip=804b3a1e esp=fb6e6b1c ebp=fb6e6bc4 iopl=0 nv up ei ng nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000286 nt!ExMapHandleToPointer+0x25: 804b3a1e c20800 ret 0x8 kd>; !handle 78 ff fcc654e0 processor number 0 PROCESS fcc654e0 SessionId: 0 Cid: 03ac Peb: 7ffdf000 ParentCid: 02e0 DirBase: 03cc6000 ObjectTable: fcc59988 TableSize: 16. Image: NOTEPAD.EXE Handle Table at e1dfb000 with 16 Entries in use 0078: Object: e1caf520 GrantedAccess: 000f003f (Locked) Object: e1caf520 Type: (fcebc160) Key ObjectHeader: e1caf508 HandleCount: 1 PointerCount: 1 Directory Object: 00000000 Name: \REGISTRY\USER So, what have we accomplished. We notice that we index into the handle table and find that weird number. That weird number is then replaced by the object header "e1caf508". The actual object is at ObjectHeader + 18h, so e1caf508 + 18 = e1caf520. kd> !object e1caf520 Object: e1caf520 Type: (fcebc160) Key ObjectHeader: e1caf508 HandleCount: 1 PointerCount: 1 Directory Object: 00000000 Name: \REGISTRY\USER Now, what was the calculation to get to this? So simple, "or eax,0x80000000". Let's give it a try now on some of those other objects. We had 7cdee148, and we get fcdee148. Add 18h, and we should be able to !object. kd> !object fcdee160 Object: fcdee160 Type: (fcebf420) Event ObjectHeader: fcdee148 HandleCount: 1 PointerCount: 1 So, that's how simple it is. Heap Information The heap for a particular process can be displayed from kernel mode. Set your context to that process and dump the PEB. The PEB will point to the number of heaps and a heap list which can be used. Each heap then has a VirtualAlloc list that can be used as a linked list. This can all be done in usermode as well, nothing special here. The only difference is that you may not be able to display all of the information if it's paged out. Anyway, luckily you don't even have to go through all that. You can simply use !heap in the kernel! Just set your context and just use !heap as normal. You may refer back to [url=http://www.codeproject.com/debug/cdbntsd3.asp]Debug Tutorial Part 3[/url] to learn more about heaps. Pools Kernel drivers generally use memory from the Paged and Non-Paged pool. You can take an address and do !pool to determine its size, tag information, etc. If you develop drivers, you know that when you allocate memory in the kernel, it comes from a global pool, not per-process. So if you corrupt memory, you can end up corrupting other drivers in the system. When a driver allocates memory, they generally specify a "pool tag" which is then associated with the memory. This is how we can tell what driver allocated what memory. There is also !poolfind * to find pool based on a pool tag. You can look online or other places to find information about a pool tag and what it relates to. For example, let's do !pool on the objects we were handling before. kd> !pool e1caf520 e1caf000 size: 60 previous size: 0 (Allocated) NtFd e1caf060 size: 20 previous size: 60 (Free) .... e1caf080 size: 40 previous size: 20 (Allocated) NtFs e1caf0c0 size: 20 previous size: 40 (Free) Key e1caf0e0 size: 20 previous size: 20 (Allocated) CMVI e1caf100 size: 40 previous size: 20 (Allocated) CMVa e1caf140 size: 20 previous size: 40 (Free) CMVa e1caf160 size: 40 previous size: 20 (Lookaside) Key (Protected) e1caf1a0 size: 20 previous size: 40 (Allocated) Ntf0 e1caf1c0 size: 40 previous size: 20 (Allocated) IoNm e1caf200 size: 20 previous size: 40 (Free) Gla8 e1caf220 size: 40 previous size: 20 (Allocated) CMVa e1caf260 size: 40 previous size: 40 (Allocated) CMVa e1caf2a0 size: 20 previous size: 40 (Free) Key e1caf2c0 size: 60 previous size: 20 (Allocated) Ntfo e1caf320 size: 40 previous size: 60 (Allocated) CMNb (Protected) e1caf360 size: 40 previous size: 40 (Allocated) CMIn (Protected) e1caf3a0 size: a0 previous size: 40 (Allocated) SeSd e1caf440 size: 20 previous size: a0 (Free) Usqm e1caf460 size: 40 previous size: 20 (Allocated) CMVa e1caf4a0 size: 40 previous size: 40 (Allocated) CMVa e1caf4e0 size: 20 previous size: 40 (Allocated) Ntf0 *e1caf500 size: 40 previous size: 20 (Allocated) *Key (Protected) e1caf540 size: 20 previous size: 40 (Free) Gla8 e1caf560 size: 40 previous size: 20 (Allocated) CMVa e1caf5a0 size: 20 previous size: 40 (Free) SYSA e1caf5c0 size: 20 previous size: 20 (Allocated) CMNb (Protected) e1caf5e0 size: 40 previous size: 20 (Allocated) CMNb (Protected) e1caf620 size: 40 previous size: 40 (Allocated) CMNb (Protected) e1caf660 size: a0 previous size: 40 (Allocated) CMDa e1caf700 size: 40 previous size: a0 (Allocated) NtFL e1caf740 size: 40 previous size: 40 (Allocated) CMNb (Protected) e1caf780 size: a0 previous size: 40 (Allocated) MmSt e1caf820 size: 40 previous size: a0 (Allocated) CMNb (Protected) e1caf860 size: 20 previous size: 40 (Allocated) ObDi e1caf880 size: 20 previous size: 20 (Free) CMDa e1caf8a0 size: 20 previous size: 20 (Allocated) CMVI e1caf8c0 size: 40 previous size: 20 (Allocated) IoNm e1caf900 size: 80 previous size: 40 (Allocated) FSim e1caf980 size: 20 previous size: 80 (Free) MmSt e1caf9a0 size: 60 previous size: 20 (Allocated) CMDa e1cafa00 size: 3e0 previous size: 60 (Allocated) NtfF e1cafde0 size: 60 previous size: 3e0 (Allocated) CMDa e1cafe40 size: 40 previous size: 60 (Allocated) CMVa e1cafe80 size: 40 previous size: 40 (Allocated) CMVa e1cafec0 size: 80 previous size: 40 (Allocated) FSim e1caff40 size: 40 previous size: 80 (Allocated) Key (Protected) e1caff80 size: 80 previous size: 40 (Allocated) Gla@ The Kernel Debugger will display the allocation with an "*". All the kernel debugger does is it takes the address, and takes off the last 3 numbers and replace them with 0. In this case, e1caf520, became e1caf000. It then simply walks the pool from there. It's a linked list, just like the user mode heap, except it doesn't go by pointer links but rather by size links. The sizes point forward and backward. In the above case, the sizes are shifted by 5, and the sizes are represented by bytes. Take the last allocation for example. kd> db e1caff80 e1caff80 02 81 02 04 47 6c 61 40-59 01 10 08 00 00 00 00 ....Gla@Y....... e1caff90 00 00 00 80 00 00 00 00-07 00 00 00 00 00 00 00 ................ e1caffa0 00 00 00 00 14 00 00 80-8b 00 00 00 f0 00 75 00 ..............u. e1caffb0 00 00 00 00 d4 d0 c8 00-00 00 00 00 00 00 00 00 ................ e1caffc0 01 00 00 00 00 00 00 00-ff ff ff 00 04 00 00 00 ................ e1caffd0 08 00 00 00 c8 d0 d4 00-00 00 00 00 d4 d0 c8 00 ................ e1caffe0 01 05 00 00 00 00 00 05-15 00 00 00 85 e7 7e 2f ..............~/ e1cafff0 23 f3 f6 63 f8 9f b4 74-01 02 00 00 00 00 00 00 #..c...t........ kd> ? 02 << 5 Evaluate expression: 64 = 00000040 kd> ? 04 << 5 Evaluate expression: 128 = 00000080 The flags in the middle specify a SHORT that tells whether the allocation is free or used, for example. The tag is the next 4 bytes, and then is the allocated memory. 8 byte header, just like in user mode. (Of course, there is a large header in usermode for large allocations in the "VirtualAlloc" list of the heap.) Of course, the kernel can allocate large blocks of memory as well in the pool, how does that work? You just get a few pages of memory not allocated from a pool, you get your own address that looks like "e1caf000", and unlike doing this in usermode that has a 32 byte header information with size, there is no header information. Ready Threads Ready threads are threads that are ready to be executed, in a READY state as opposed to a WAIT state. kd> !ready 0 Ready Threads at priority 0 THREAD fcebf020 Cid 8.4 Teb: 00000000 Win32Thread: 00000000 READY Just !ready will display the entire thread information. In Windows XP/2003, there is also a !running which will show the currently running threads on multiprocessor systems. Also, ~<number><NUMBER>s in the usermode debugger switches between threads, in the kernel debugger it switches between processors. CPU ID There are other things you can do like !cpuid. kd> !cpuid CP F/M/S Manufacturer MHz 0 5,8,12 AuthenticAMD 350 Virtual Memory Usage To display memory usage, you can use !vm. kd> !vm *** Virtual Memory Usage *** Physical Memory: 31613 ( 126452 Kb) Page File: \??\C:\pagefile.sys Current: 184320Kb Free Space: 180464Kb Minimum: 184320Kb Maximum: 368640Kb Available Pages: 17617 ( 70468 Kb) ResAvail Pages: 26203 ( 104812 Kb) Modified Pages: 543 ( 2172 Kb) NonPagedPool Usage: 677 ( 2708 Kb) NonPagedPool Max: 12528 ( 50112 Kb) PagedPool 0 Usage: 2993 ( 11972 Kb) PagedPool 1 Usage: 439 ( 1756 Kb) PagedPool 2 Usage: 451 ( 1804 Kb) PagedPool Usage: 3883 ( 15532 Kb) PagedPool Maximum: 25600 ( 102400 Kb) Shared Commit: 324 ( 1296 Kb) Special Pool: 0 ( 0 Kb) Free System PTEs: 14442 ( 57768 Kb) Shared Process: 1125 ( 4500 Kb) PagedPool Commit: 3883 ( 15532 Kb) Driver Commit: 912 ( 3648 Kb) Committed pages: 11945 ( 47780 Kb) Commit limit: 73862 ( 295448 Kb) Total Private: 5662 ( 22648 Kb) 00a4 winlogon.exe 1358 ( 5432 Kb) 00d8 services.exe 587 ( 2348 Kb) 02e4 explorer.exe 557 ( 2228 Kb) 01b4 SPOOLSV.EXE 503 ( 2012 Kb) 00e4 lsass.exe 446 ( 1784 Kb) 01e8 svchost.exe 412 ( 1648 Kb) 00a8 csrss.exe 329 ( 1316 Kb) 0374 mspaint.exe 303 ( 1212 Kb) 008c smss.exe 273 ( 1092 Kb) 018c svchost.exe 227 ( 908 Kb) 0290 winvnc.exe 164 ( 656 Kb) 0264 winmgmt.exe 154 ( 616 Kb) 02e0 cmd.exe 143 ( 572 Kb) 0228 mstask.exe 141 ( 564 Kb) 0210 regsvc.exe 59 ( 236 Kb) 0008 System 6 ( 24 Kb) If you're looking for "is the system out of memory", you basically want to look at the "committed pages" versus the "commit limit". The committed pages are how much memory is currently being used and the commit limit is how much total memory can be used. The next tool that can be used is !memusage which builds a map of all memory mapped files on the system. kd> !memusage loading PFN database loading (99% complete) Zeroed: 3163 ( 12652 kb) Free: 20 ( 80 kb) Standby: 14434 ( 57736 kb) Modified: 543 ( 2172 kb) ModifiedNoWrite: 0 ( 0 kb) Active/Valid: 13567 ( 54268 kb) Transition: 0 ( 0 kb) Unknown: 0 ( 0 kb) TOTAL: 31727 (126908 kb) Building kernel map Finished building kernel map Usage Summary (in Kb): Control Valid Standby Dirty Shared Locked PageTables name fce7a3c8 468 16776 0 0 0 0 No Name for File fccf6148 0 2876 0 0 0 0 mapped_file( CIM.REP ) fcd43388 0 96 0 0 0 0 mapped_file( chord.wav ) fcc40568 0 48 0 0 0 0 mapped_file( index.dat ) fcc64308 0 2420 0 0 0 0 mapped_file( mshtml.dll ) fcce8b28 0 188 0 0 0 0 mapped_file( rasppp.dll ) fcc76728 0 208 0 0 0 0 mapped_file( h323.tsp ) fccec3c8 220 92 0 0 0 0 mapped_file( netcfgx.dll ) fce48e88 1152 180 0 0 0 0 mapped_file( win32k.sys ) fcde4f28 16 460 0 0 0 0 mapped_file( wininet.dll ) fcc7f808 0 32 0 0 0 0 mapped_file( wbemcomn.dll ) fcc4d7a8 0 388 0 0 0 0 mapped_file( ntvdm.exe ) fcceb128 80 200 0 0 0 0 mapped_file( rasdlg.dll ) fcde5a08 200 896 0 120 0 0 mapped_file( shell32.dll ) fceca188 3196 1280 0 0 0 0 No Name for File fccecd88 108 36 0 0 0 0 mapped_file( tapisrv.dll ) fcda5a28 8 204 0 0 0 0 mapped_file( msgina.dll ) fcc83348 0 300 0 0 0 0 mapped_file( wbemess.dll ) fcce9248 40 756 0 0 0 0 mapped_file( shdocvw.dll ) fcd10a68 0 32 0 0 0 0 mapped_file( notepad.exe ) fcd7dd08 0 504 0 0 0 0 mapped_file( jscript.dll ) fcc7cc48 0 32 0 0 0 0 mapped_file( mswsock.dll ) fcc4a4a8 0 116 0 0 0 0 mapped_file( dxtmsft.dll ) fcce95e8 32 40 0 0 0 0 mapped_file( ntmarta.dll ) fcce89a8 0 12 0 0 0 0 mapped_file( ntlsapi.dll ) fcc821a8 0 68 0 0 0 0 mapped_file( modemui.dll ) fcc7a4e8 16 196 0 0 0 0 mapped_file( msi.dll ) fccec688 112 32 0 0 0 0 mapped_file( rasmans.dll ) fcc4ea68 240 64 0 0 0 0 mapped_file( mspaint.exe ) fcd64ba8 0 32 0 0 0 0 mapped_file( tapisrv.dll ) fcde4aa8 0 36 0 0 0 0 mapped_file( mpr.dll ) fcdc33a8 164 64 0 0 0 0 mapped_file( winsrv.dll ) fcceeb08 0 32 0 0 0 0 mapped_file( wkssvc.dll ) fccf3ee8 0 32 0 0 0 0 mapped_file( winlogon.exe ) fcc54a28 112 36 0 0 0 0 mapped_file( cmd.exe ) fcc60408 0 148 0 0 0 0 mapped_file( dxtrans.dll ) fccee4a8 0 32 0 0 0 0 mapped_file( cryptsvc.dll ) fcc7fe08 0 32 0 0 0 0 mapped_file( SPOOLSV.EXE ) fcd7e788 80 512 0 0 0 0 mapped_file( browseui.dll ) fcc7ed28 0 0 4 0 0 0 mapped_file( software.LOG ) fcc7f128 40 264 0 8 0 0 mapped_file( netshell.dll ) fcc51ac8 0 32 0 0 0 0 mapped_file( jscript.dll ) ... -------- 12 0 0 ----- ----- 8 pagefile section (78a7) -------- 456 0 0 ----- ----- 72 process ( mstask.exe ) -------- 452 536 116 ----- ----- 92 process ( lsass.exe ) -------- 140 0 0 ----- ----- 28 process ( smss.exe ) -------- 88 452 0 ----- ----- 52 process ( winmgmt.exe ) -------- 236 0 0 ----- ----- 36 process ( regsvc.exe ) -------- 520 0 0 ----- ----- 72 process ( winvnc.exe ) -------- 12 0 0 ----- ----- 8 pagefile section (6933) -------- 1320 100 0 ----- 0 ----- driver ( ntoskrnl.exe ) -------- 60 16 0 ----- 0 ----- driver ( hal.dll ) ... As you can see, all files that are loaded in the system are loaded as memory mapped files. This means the Operating System uses the copy on disk to continuously load it into memory. It doesn't copy it into memory and then put it in the page file. To get information on one of these memory mapped files, such as how many references are currently being mapped, etc., use !ca. kd> !ca fcdee008 ControlArea @fcdee008 Segment: e1b764c8 Flink 0 Blink: 0 Section Ref 1 Pfn Ref 1e Mapped Views: 1 User Ref 2 Subsections 4 Flush Count: 0 File Object fcdbe728 ModWriteCount 0 System Views: 0 WaitForDel 0 Paged Usage 100 NonPaged Usage c0 Flags (90000a0) Image File HadUserReference Accessed File: \WINNT\system32\winlogon.exe Segment @ e1b764c8: ControlArea fcdee008 Total Ptes 0 NonExtendPtes: 2d WriteUserRef 2d Extend Info 0 SizeOfSegment: 2d000 Image Base 0 Committed e1b765b8 Based Addr 2d36f438 PTE Template: 3 Image commit 1000000 Image Info: 0 ProtoPtes e1b76500 Subsection 1. @ fcdee040 ControlArea: fcdee008 Starting Sector 0 Number Of Sectors 2 Base Pte e1b76500 Ptes In subsect 1 Unused Ptes 0 Flags 15 Sector Offset 0 Protection 1 ReadOnly SubsectionStatic Subsection 2. @ fcdee060 ControlArea: fcdee008 Starting Sector 2 Number Of Sectors ff Base Pte e1b76504 Ptes In subsect 20 Unused Ptes 0 Flags 35 Sector Offset 0 Protection 3 ReadOnly SubsectionStatic Subsection 3. @ fcdee080 ControlArea: fcdee008 Starting Sector 101 Number Of Sectors 11 Base Pte e1b76584 Ptes In subsect 3 Unused Ptes 0 Flags 55 Sector Offset 0 Protection 5 ReadOnly SubsectionStatic Subsection 4. @ fcdee0a0 ControlArea: fcdee008 Starting Sector 112 Number Of Sectors 48 Base Pte e1b76590 Ptes In subsect 9 Unused Ptes 0 Flags 15 Sector Offset 0 Protection 1 ReadOnly SubsectionStatic You will notice there is only one mapped view for Winlogon on this machine. Don't worry if it says 0 views and the process is running; look on the list, there may be two listings for that file and the other one is the mapview being used. Conclusion This is a simple introduction to the kernel debugger and a few things that you can do. While I haven't covered everything, I hope that you now know at least the basics and can navigate it. There's always the help and [url=http://www.google.com/]http://www.google.com/[/url]! You learn something new everyday; one person can't know everything, but they can try! I tried to make sure the information presented is as accurate as possible, but things can get through, so let me know if I missed something or misrepresented something. I may add more Kernel Debugging tutorials in the future, with other topics. We didn't even cover IRPs! You usually don't end up working with every single detail in the listing. You usually end up using a bunch of different commands to get different information, and each command you may only ever use a subset of the data, and this is fine. You may not even care what the other data is or even know what it is. Perhaps even if you know what it is, it would never be useful to you. So, don't get discouraged if you don't know what a piece of displayed information is or if you can't find any references to it online. If you really need to know though, you could always set ba's on the address and track down who's using it for what. About Toby Opferman
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 
 熱帖排行
 
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有