CODEWITHSUNDEEP
windowssystem-calls
Dave McGinnis
Dave McGinnis

Reputation: 615

Consuming Windows NT Kernel System Call Trace Session Dumps

I am trying to somehow log (programmatically or to a log file) every system call which a select number of processes call during a given time span. Using the answer to Is there something like linux ptrace syscall in Windows?, I have been able to correctly use ETW to trace all of the system calls being called into an etl file, which I can then translate to an XML file using tracerpt. Looking at the XML files and the other formats available, however, I've found two major issues:

  1. The system calls are given in terms of the memory address to the call, but I can't seem to find any good way of translating these addresses to names. For reference, a sample system call address is 0xFFFFF80002AC22BC.

  2. All of the process IDs are set to 0xFFFFFFFF, yet it seems as if the system calls are being logged for all processes, not just the process which started the trace. How should I determine which process made which system call, or at least filter to a single or a select number of processes which I want to trace?

Does anyone have any solutions to the above issues, or, even better, some sample code which might take one of these log file formats that tracerpt can output and put it into a human readable and usable format?

Upvotes: 0

Views: 1076

Answers (2)

canzar
canzar

Reputation: 340

(1) The library containing the kernel system functions listed by the kernel tracer is not loaded at the same location every time the system is rebooted. One way you can resolve the system call addresses in using the kernel debugger. For example ln <address> will give give you the name of the function at <address>. If you type lm in the kernel across multiple reboots, you will notice that the module 'nt' is always at a different location.

(2) From what I have read, you are right about having to track context switching but I have never actually attempted to do this.

Upvotes: 0

Dave McGinnis
Dave McGinnis

Reputation: 615

So I think, after looking around, I've been able to resolve these issues in a way that at least makes it useful (although sadly not useful to me because of other issues).

  1. The addresses are consistent, and I have a theory that these addresses are a constant offset inside of the library's image on memory, so all you would need to do is take the difference from the address to the library it belongs to, and that could map directly to the name of the system call manually, or you could use a symbol table for the executable to find the name. Neither of these has been tested by me, but seem to be the way to go after looking at it.

  2. To find what process is making the system call, as you go through the log, if you include context switch information, you know what process is on which core at which time, and each system call includes what core the system call is occurring on, so that will give you the thread which is calling the system call accurately.

Upvotes: 1

Related Questions