Hello,
I am recently working on a project in my company and we try to implement event tracing to monitor certain API calls from user-mode. We want to use ETW to see when a process loads a DLL in memory and what functions and when is calling from that dll and eventually trace those api calls to the native calls if there is the case.
I can say we have partially done that, with an NT KERNEL LOGGER session of ETW, and with the Syscall flag enabled, we now receive a trace message for each native api call, but one problem is that the message header where the ProcessId and ThreadId are located shows for each call the (DWORD)ProcessId = -1 , which is not what we have expected.
I have read the article about xperf and stack tracing for each process, gave it a try, and looks like something we can use, but need to actually implement the programatically what xperf does in terms of stack tracing.
Does anyone have any insights on this subject ? Is there another way to do this except hooking ? In fact we are actually trying to export this to user mode so we do not use hooking in kernel.
Thank.
You might have more luck getting the thread and process info if you start
the trace as EVENT_TRACE_REAL_TIME_MODE as logging mode (in the
EVENT_TRACE_PROPERTIES) structures. That means you cannot process or display
the events as they are taking place, until the trace is stopped.
Another way may be to include the CSwitch class and figure out given the
time stamp what thread/process is running on that CPU. But honestly as
events are not guaranteed to get delivered to your consumer this is prone to
error and mess.
//Daniel
wrote in message news:xxxxx@ntdev…
> Hello,
> I am recently working on a project in my company and we try to implement
> event tracing to monitor certain API calls from user-mode. We want to use
> ETW to see when a process loads a DLL in memory and what functions and
> when is calling from that dll and eventually trace those api calls to the
> native calls if there is the case.
>
> I can say we have partially done that, with an NT KERNEL LOGGER session of
> ETW, and with the Syscall flag enabled, we now receive a trace message for
> each native api call, but one problem is that the message header where the
> ProcessId and ThreadId are located shows for each call the
> (DWORD)ProcessId = -1 , which is not what we have expected.
>
> I have read the article about xperf and stack tracing for each process,
> gave it a try, and looks like something we can use, but need to actually
> implement the programatically what xperf does in terms of stack tracing.
>
> Does anyone have any insights on this subject ? Is there another way to do
> this except hooking ? In fact we are actually trying to export this to
> user mode so we do not use hooking in kernel.
>
> Thank.
>
>
You might have more luck getting the thread and process info if you start the trace as >EVENT_TRACE_REAL_TIME_MODE as logging mode (in the EVENT_TRACE_PROPERTIES) structures. >That means you cannot process or display the events as they are taking place, until the trace is >stopped.
You want to say I DON’T start it in realtime mode, so I can process them from a trace file, after I stop the trace session. I tried that bu unfortunately that is not it, as for CSwitch, it is to risky to even presume using it because we need pretty concise data.
I see EnableTraceEx2() API call has ENABLE_TRACE_PARAMETERS where I can set a flag EVENT_ENABLE_PROPERTY_STACK_TRACE.
This would give me for each message trace a
typedef struct _EVENT_EXTENDED_ITEM_STACK_TRACE32 {
ULONG64 MatchId;
ULONG Address[ANYSIZE_ARRAY];
} EVENT_EXTENDED_ITEM_STACK_TRACE32, *PEVENT_EXTENDED_ITEM_STACK_TRACE32;
Has anyone ever used this ?
How can I convert Address[i] -> to Advapi32!StartTraceW ?
Any hints ?
And how can I interpret the documentation for MatchId:
"MatchId
A unique identifier that you use to match the kernel-mode calls to the user-mode calls; the kernel-mode calls and user-mode calls are captured in separate events if the environment prevents both from being captured in the same event. If the kernel-mode and user-mode calls were captured in the same event, the value is zero.
Typically, on 32-bit computers, you can always capture both the kernel-mode and user-mode calls in the same event. However, if you use the frame pointer optimization compiler option, the stack may not be capture, captured correctly, or truncated."
As I can tell if two messages have the same match ID one comes with calls from UserMode and the other are the calls matched in kernel.
Anyway the problem stands how do I get the call stack trace like xperf with debugging information I may say so…
wrote in message news:xxxxx@ntdev…
> You want to say I DON’T start it in realtime mode, so I can process them
> from a trace file, after I stop the trace session. I tried that bu
> unfortunately that is not it, as for CSwitch, it is to risky to even
> presume using it because we need pretty concise data.
>
Contrary to what the name suggests, in real-time mode events are not
delivered until the trace is stopped. I think this is what XPERF does.
//Daniel
I am using realtime processing for the events and I process them as they are created, and I can see that traceview utlity does the same, because I do parallel tests.
What xperf does si flush the trace buffers to a file after you decide to end the tracing session.
Hi, I encounter the same problem, how do you finally solve it, I mean convert Address[i] → to Advapi32!StartTraceW ?
You’re posting to an 11 year old thread, which – as I’m SURE you know – is not allowed by the forum guidelines.
If you have a question, start a new thread. This one has been locked.
Peter