stepping through sysenter

Hi!

I’m a computer science student that’s interested in Windows Internals.
Currently, I’m trying to trace user32!NtUserSetCursor. I have no idea what
this function does, so I thought diving in might be a fun way to learn not
just about what this function does but also a bit more about how my
operating system works.

The disassembly of user32!NtUserSetCursor on my box looks something like
this:
USER32!NtUserSetCursor:
7e429930 b8ff110000 mov eax,11FFh
7e429935 ba0003fe7f mov edx,offset SharedUserData!SystemCallStub
(7ffe0300)
7e42993a ff12 call dword ptr [edx]
7e42993c c20400 ret 4

It’s my understanding that the value being stored into eax is the index in
the KiServiceTable of the kernel-mode function that provides that service.
And the sysenter instruction that’s located in the “call edx” is somehow
going to magically do that look up and take me there.

When trying to single-step over that sysenter instruction with my kernel
debugger, it just brings me that “ret 4” instead of doing any kernel-mode
transition or anything. What am I doing wrong to step through the entire
process? I understand that doing this with a user-mode debugger will give
me this type of behavior, but I was under the impression that using a
kernel-mode debugger would allow me to debug everything involved in this
call?

I’m new to kernel debugging, but I think I’ve set up Windbg to debug a
Windows XP SP3 target running on VMware over a named pipe and set Windbg to
use the symbols at: http://msdl.microsoft.com/download/symbols.

Can someone please point me in the right direction?

Thanks!
-Cort

Windbg does not have a provision for stepping from user to kernel space.
I’ve never deal with things like NtUserSetCursor but for some of the common
calls such as NtWriteFile you can find the handler with the same name in the
kernel, and put a breakpoint there.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Cortney Jackson
Sent: Saturday, October 15, 2011 7:02 PM
To: Kernel Debugging Interest List
Subject: [windbg] stepping through sysenter

Hi!

I’m a computer science student that’s interested in Windows Internals.
Currently, I’m trying to trace user32!NtUserSetCursor. I have no idea what
this function does, so I thought diving in might be a fun way to learn not
just about what this function does but also a bit more about how my
operating system works.

The disassembly of user32!NtUserSetCursor on my box looks something like
this:
USER32!NtUserSetCursor:
7e429930 b8ff110000 mov eax,11FFh
7e429935 ba0003fe7f mov edx,offset SharedUserData!SystemCallStub
(7ffe0300)
7e42993a ff12 call dword ptr [edx]
7e42993c c20400 ret 4

It’s my understanding that the value being stored into eax is the index in
the KiServiceTable of the kernel-mode function that provides that service.
And the sysenter instruction that’s located in the “call edx” is somehow
going to magically do that look up and take me there.

When trying to single-step over that sysenter instruction with my kernel
debugger, it just brings me that “ret 4” instead of doing any kernel-mode
transition or anything. What am I doing wrong to step through the entire
process? I understand that doing this with a user-mode debugger will give
me this type of behavior, but I was under the impression that using a
kernel-mode debugger would allow me to debug everything involved in this
call?

I’m new to kernel debugging, but I think I’ve set up Windbg to debug a
Windows XP SP3 target running on VMware over a named pipe and set Windbg to
use the symbols at: http://msdl.microsoft.com/download/symbols.

Can someone please point me in the right direction?

Thanks!
-Cort
— WINDBG is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

“rdmsr 176” will give you IA32_SYSENTER_EIP MSR’s address.
You can put a break point at this address and analyze how it handles.

In case you want to debug a spesific service call, you can try the
following:
bp Address “j @eax = 0xXY ';‘g’”

hope it helps

On Sun, Oct 16, 2011 at 2:21 AM, Don Burn wrote:

> Windbg does not have a provision for stepping from user to kernel space.
> I’ve never deal with things like NtUserSetCursor but for some of the common
> calls such as NtWriteFile you can find the handler with the same name in
> the
> kernel, and put a breakpoint there.
>
>
> Don Burn
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Cortney Jackson
> Sent: Saturday, October 15, 2011 7:02 PM
> To: Kernel Debugging Interest List
> Subject: [windbg] stepping through sysenter
>
> Hi!
>
> I’m a computer science student that’s interested in Windows Internals.
> Currently, I’m trying to trace user32!NtUserSetCursor. I have no idea what
> this function does, so I thought diving in might be a fun way to learn not
> just about what this function does but also a bit more about how my
> operating system works.
>
> The disassembly of user32!NtUserSetCursor on my box looks something like
> this:
> USER32!NtUserSetCursor:
> 7e429930 b8ff110000 mov eax,11FFh
> 7e429935 ba0003fe7f mov edx,offset SharedUserData!SystemCallStub
> (7ffe0300)
> 7e42993a ff12 call dword ptr [edx]
> 7e42993c c20400 ret 4
>
> It’s my understanding that the value being stored into eax is the index in
> the KiServiceTable of the kernel-mode function that provides that service.
> And the sysenter instruction that’s located in the “call edx” is somehow
> going to magically do that look up and take me there.
>
> When trying to single-step over that sysenter instruction with my kernel
> debugger, it just brings me that “ret 4” instead of doing any kernel-mode
> transition or anything. What am I doing wrong to step through the entire
> process? I understand that doing this with a user-mode debugger will give
> me this type of behavior, but I was under the impression that using a
> kernel-mode debugger would allow me to debug everything involved in this
> call?
>
> I’m new to kernel debugging, but I think I’ve set up Windbg to debug a
> Windows XP SP3 target running on VMware over a named pipe and set Windbg to
> use the symbols at: http://msdl.microsoft.com/download/symbols.
>
> Can someone please point me in the right direction?
>
> Thanks!
> -Cort
> — WINDBG is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the
> List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

how are you setting up your breakpoint

are you using hardware bp

ba e 1 /p process address

this user32 function translates into win32k.sys

it seems to to stop in win32k.sys for me

i used notepad with ntsd-d (read about using kernel debugger to debug
in usermode topic in help )

set a bp on User32!ntSetCursor
when hit

issued a .breakin

and set ba e 1 /p EPROC Notepad Win32k!ntSetBlah
and g

drag dropped a file into notepad and i get proper hits

kd> k
ChildEBP RetAddr
f97a9d58 804de7ec win32k!NtUserSetCursor
f97a9d58 7c90e4f4 nt!KiFastCallEntry+0xf8
0007faf4 7e42993c ntdll!KiFastSystemCallRet
0007fda0 010033ca USER32!NtUserSetCursor+0xc
0007fdb4 01003416 NOTEPAD!FileDragOpen+0x4c
0007fdc0 0100383d NOTEPAD!doDrop+0x3a
0007fde0 7e418734 NOTEPAD!NPWndProc+0x414
0007fe0c 7e418816 USER32!InternalCallWinProc+0x28
0007fe74 7e4189cd USER32!UserCallWinProcCheckWow+0x150
0007fed4 7e418a10 USER32!DispatchMessageWorker+0x306
0007fee4 01002a12 USER32!DispatchMessageW+0xf
0007ff1c 01007511 NOTEPAD!WinMain+0xdc
0007ffc0 7c817067 NOTEPAD!WinMainCRTStartup+0x174
0007fff0 00000000 kernel32!BaseProcessStart+0x23
kd> .event_code
bf8210c0, 0x40 bytes valid.
bf8210c0 4e 28 89 45 f8 74 03 ff-40 04 e8 4d fc fd ff e8 N(.E.t…@…M…
bf8210d0 d7 00 fe ff eb c2 89 3d-38 be 9a bf eb ce 33 f6 …=8…3.
bf8210e0 eb 2e 90 90 90 90 90 8b-ff 55 8b ec 56 e8 68 fa …U…V.h.
bf8210f0 fd ff 8b 4d 08 85 c9 74-23 b2 03 e8 12 79 00 00 …M…t#…y…
Current code stream matches captured code stream
kd> !analyze
Last event: Hit breakpoint 0
debugger time: Sun Oct 16 06:50:37.703 2011 (UTC + 5:30)
kd> bl
0 e bf8210e7 e 1 0001 (0001) win32k!NtUserSetCursor
Match process data 8110e020

kd> t
win32k!NtUserSetCursor+0x2:
bf8210e9 55 push ebp
kd> t
win32k!NtUserSetCursor+0x3:
bf8210ea 8bec mov ebp,esp
kd> t
win32k!NtUserSetCursor+0x5:
bf8210ec 56 push esi
kd> t
win32k!NtUserSetCursor+0x6:
bf8210ed e868fafdff call win32k!EnterCrit (bf800b5a)
kd> p
win32k!NtUserSetCursor+0xb:
bf8210f2 8b4d08 mov ecx,dword ptr [ebp+8]
kd> p
win32k!NtUserSetCursor+0xe:
bf8210f5 85c9 test ecx,ecx
kd> p
win32k!NtUserSetCursor+0x10:
bf8210f7 7423 je win32k!NtUserSetCursor+0x1f (bf82111c)
kd> p
win32k!NtUserSetCursor+0x12:
bf8210f9 b203 mov dl,3
kd> p
win32k!NtUserSetCursor+0x14:
bf8210fb e812790000 call win32k!HMValidateHandle (bf828a12)
kd> p
win32k!NtUserSetCursor+0x19:
bf821100 85c0 test eax,eax
kd> p
win32k!NtUserSetCursor+0x1b:
bf821102 74da je win32k!NtUserSetCursor+0x2b (bf8210de)
kd> p
win32k!NtUserSetCursor+0x21:
bf821104 50 push eax
kd> p
win32k!NtUserSetCursor+0x22:
bf821105 e86cffffff call win32k!zzzSetCursor (bf821076)
kd> t
win32k!zzzSetCursor:
bf821076 8bff mov edi,edi
kd> t
win32k!zzzSetCursor+0x2:
bf821078 55 push ebp
kd> t
win32k!zzzSetCursor+0x3:
bf821079 8bec mov ebp,esp
kd> t
win32k!zzzSetCursor+0x5:
bf82107b 83ec0c sub esp,0Ch
kd> t
win32k!zzzSetCursor+0x8:
bf82107e 8b5508 mov edx,dword ptr [ebp+8]

On 10/16/11, Cortney Jackson wrote:
> Hi!
>
> I’m a computer science student that’s interested in Windows Internals.
> Currently, I’m trying to trace user32!NtUserSetCursor. I have no idea what
> this function does, so I thought diving in might be a fun way to learn not
> just about what this function does but also a bit more about how my
> operating system works.
>
> The disassembly of user32!NtUserSetCursor on my box looks something like
> this:
> USER32!NtUserSetCursor:
> 7e429930 b8ff110000 mov eax,11FFh
> 7e429935 ba0003fe7f mov edx,offset SharedUserData!SystemCallStub
> (7ffe0300)
> 7e42993a ff12 call dword ptr [edx]
> 7e42993c c20400 ret 4
>
> It’s my understanding that the value being stored into eax is the index in
> the KiServiceTable of the kernel-mode function that provides that service.
> And the sysenter instruction that’s located in the “call edx” is somehow
> going to magically do that look up and take me there.
>
> When trying to single-step over that sysenter instruction with my kernel
> debugger, it just brings me that “ret 4” instead of doing any kernel-mode
> transition or anything. What am I doing wrong to step through the entire
> process? I understand that doing this with a user-mode debugger will give
> me this type of behavior, but I was under the impression that using a
> kernel-mode debugger would allow me to debug everything involved in this
> call?
>
> I’m new to kernel debugging, but I think I’ve set up Windbg to debug a
> Windows XP SP3 target running on VMware over a named pipe and set Windbg to
> use the symbols at: http://msdl.microsoft.com/download/symbols.
>
> Can someone please point me in the right direction?
>
> Thanks!
> -Cort
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer


thanks and regards

raj_r

adsasds sad