Closed subvert0r closed 11 months ago
Although some events are emitted in both the kernel debug trace session and a user-mode trace session, they may not have the same information. For example, the process start events emitted by the kernel debug trace session contain the process command line, but the Microsoft-Windows-Kernel-Process provider spreads the process start and command line information across two event types that must be correlated together.
In general, I would recommend using a user-mode trace session unless you need to subscribe to an event that can only be found on the kernel debug trace session.
but the Microsoft-Windows-Kernel-Process provider spreads the process start and command line information across two event types that must be correlated together.
One last question to wrap this up:
Any performance difference between the two? Meaning the impact on the system performance. Will any of them noticeably slow down the machine if they are turned on all the time and are consumed by a user-mode process?
Yes, it's possible for there to be a performance impact when enabling any ETW provider. Windows components typically check whether any trace sessions have subscribed to their ETW provider + enabled the appropriate keywords for tracing; if none are subscribed, they skip emitting the event.
In practice, the overhead of simply emitting an ETW event is imperceptible in both the kernel and user-mode case. However, applications may choose to enable more expensive diagnostics when an ETW provider is enabled. For example, several years ago we observed a severe performance impact when enabling verbose tracing for SQL Server queries. I would be most concerned about this when enabling ETW providers that are not part of the core Windows operating system.
Yes, it's possible for there to be a performance impact when enabling any ETW provider. Windows components typically check whether any trace sessions have subscribed to their ETW provider + enabled the appropriate keywords for tracing; if none are subscribed, they skip emitting the event.
In practice, the overhead of simply emitting an ETW event is imperceptible in both the kernel and user-mode case. However, applications may choose to enable more expensive diagnostics when an ETW provider is enabled. For example, several years ago we observed a severe performance impact when enabling verbose tracing for SQL Server queries. I would be most concerned about this when enabling ETW providers that are not part of the core Windows operating system.
Correct, But I'm asking about the difference between the performance impact of the kernel_trace providers and their similar provider in the user_trace.
For example in the following two scenarios:
Which of these two will impact the performance of the machine more? And is it a minor difference or..? I think the answer to this question can help a lot of people understand the difference between kernel_trace and user_trace providers.
Because so far I have gotten all the data I need using user_trace providers, but now I wanted to also get the command line of the processes and found out I need a kernel_trace for that, If I enable kernel_trace and use process_provider, can this impact the performance of some machines in a noticable way? Because if so, then I would stick to just using Microsoft-Windows-Kernel-Process.
Which of these two will impact the performance of the machine more?
In my experience I have not observed any performance impact from either of your 2 scenarios, and have not observed any difference between them.
Some events can be consumed both with a kernel_trace and also a user_trace.
For example the process event, which can be consumed both with the kernel_trace using krabs::guids::process, and also with a user_trace using Microsoft-Windows-Kernel-Process.
Any benefit of using a kernel_trace for these vs using a user_trace? What about the drawbacks?
I think the docs should get updated to explain more regarding the differences between the user_trace and kernel_trace.