Log in

View Full Version : First time using WinDbg, having some issues


TheUsualSuspect
November 9th, 2010, 13:04
First of all, hello everyone!

While I'm rather familiar with debugging and reverse engineering in ring3, I finally made the leap into the ring0 world for a private project and so far it seems it is as fascinating as I imagined it to be. It took me quite some time to get my setup running (WinDbg, VirtualKD, VirtualBox) but eventually it worked. Now my first problem is with WinDbg.

I use VirtualKD to do remote kernel debugging and am interested in the inner workings of win32k.sys. But when I fire up WinDbg, something weird happens:

Code:

kd> x win32k!NtUserInvalidateRect
bf8153d5 win32k!NtUserInvalidateRect = <no type information>
kd> u win32k!NtUserInvalidateRect
win32k!NtUserInvalidateRect:
bf8153d5 ?? ???
^ Memory access error in 'u win32k!NtUserInvalidateRect'
kd> dd win32k!NtUserInvalidateRect
bf8153d5 ???????? ???????? ???????? ????????
bf8153e5 ???????? ???????? ???????? ????????
bf8153f5 ???????? ???????? ???????? ????????
bf815405 ???????? ???????? ???????? ????????
bf815415 ???????? ???????? ???????? ????????
bf815425 ???????? ???????? ???????? ????????
bf815435 ???????? ???????? ???????? ????????
bf815445 ???????? ???????? ???????? ????????


I have no clue what this means. From what I know kernel pages can be paged out and thus might be unaccessible. I tried to use the .pagein command but it just works on virtual memory addresses.

What's even more weird is that when I do the same thing on the box itself with LiveKd, I can look at the memory but obviously don't set breakpoints and trace the code flow.

As I said I'm pretty much a beginner when it comes to kernel debugging and I have no idea what this could be. Any concept I'm missing?

Kayaker
November 11th, 2010, 01:46
Hi

You need to be in a usermode context first to be able to see win32k memory space. See here for an explanation:

http://www.woodmann.com/forum/showthread.php?6047-Can-t-see-WIN32K-with-SoftIce

What isn't mentioned (explicitly) is the effect of the additional SSDT (System Service Descriptor Table) Shadow Table, which is part of win32k and kicks in only for GUI threads. I think that's probably the underlying issue here.

Choose any non-system process from your guest system and set to that process context. You should be able to see win32k.sys then (I just confirmed that works with Windbg/Vmware)


Code:
kd> !process 0 0 winlogon.exe
PROCESS 81408da0 SessionId: 0 Cid: 024c Peb: 7ffdf000 ParentCid: 01f4
DirBase: 06ba3000 ObjectTable: e14dba88 HandleCount: 418.
Image: winlogon.exe

kd> .process 81408da0
Implicit process is now 81408da0


Btw, how do you like VirtualKD? I've been wanting to set that up since it's supposed to speed up remote debugging immensely. I don't actually remote debug much mind you since I'm still a Softice dinosaur for now, but I know I should get with the times...

Cheers,
Kayaker

TheUsualSuspect
November 13th, 2010, 17:49
Thanks, that did the trick. I definitely need to read up on a lot of concepts to understand kernel mode but it is fascinating. Regarding VirtualKD: I think I like it. I can't really compare it to anything, regular named pipe debugging wouldn't work but it supposedly is way faster. It seems fast, but breaking a running OS sometimes takes up to 5 seconds on my (very) strong rig. I don't know how long this would be otherwise for example. For now, it works and that's what counts