0

I am using Event Tracing for Windows (ETW) to do kernel tracing of syscalls in Windows Server 2008 R2.

I am running:

logman start "NT Kernel Logger" -p "Windows Kernel Trace" (process,thread,cswitch,syscall) -o events.etl -ets

In the resulting kernel traces, I am looking at the SysCallAddress attribute and I see lot of what I would expect: for example 0xFFFFF80001999EE0 which is nt!NtWriteFile.

The problem is that I am seeing a lot of address in the 0xFFFFF960 range, for example 0xFFFFF9600004421C and I don't know what is at these addresses. The ln command in the kernel debugger returns no information for any of these addresses. Does anybody know what lives at these addresses that the kernel tracer regards as syscalls?

canzar
  • 340
  • 4
  • 17

1 Answers1

3

Those are syscalls into win32k.sys. Think GetMessage, EndDraw, etc.

Neeraj Singh
  • 589
  • 3
  • 6
  • Thank you for the response! Do you have any references? Also, why does the debugger not tell me anything about them? – canzar May 10 '12 at 15:25
  • win32k is mapped into session space. If your debugger is broken in and not in the context a process in a session, then nothing will be visible. Use .process /p /r
    to get to a place where you can see those addresses.
     – Neeraj Singh May 12 '12 at 04:46
  • Upon closer inspection I notice that I can in fact see these imports when I am in a process context. However, I can only resolve a subset of them. I see that win32k starts at `fffff960 00e0000` and I can resolve those calls that occur beyond that address, but there are calls that come before that address, for example `FFFFF960 0005CE44`. Any insight into these? No matter what process I have chosen, there was never a library loaded at this address range. – canzar May 16 '12 at 20:27
  • There are only two different modules which expose syscalls, so the function would either be in win32k or ntoskrnl. These module addresses move every time you reboot.. any chance that is occurring? – Neeraj Singh May 20 '12 at 18:17
  • :) of course they do -- the system had in fact rebooted since I gathered the trace I was examining -- thanks for the help. – canzar May 21 '12 at 16:38
  • Btw I also found that issuing a .reload in the kernel debugger, which loads the unloaded module list and symbols, also allows me to resolve these names without switching contexts. – canzar May 25 '12 at 17:17