microsoft / krabsetw

KrabsETW provides a modern C++ wrapper and a .NET wrapper around the low-level ETW trace consumption functions.
Other
577 stars 147 forks source link

Missing events when event burst happen even after setting the EVENT_TRACE_PROPERTIES to large number of buffers? #235

Open subvert0r opened 1 month ago

subvert0r commented 1 month ago

I have minimized my callback function to just collect as much as info as possible and just pass that to another thread, But I am still missing some events when a particular provider sends too many events to my callback.

Note that I have a separate callback function for each provider, but I still lose events on all providers when one particular provider sends me too much events. I cannot make my callback functions any faster, and have already filtered as much as possible.

My question is, is there anyway I can configure krabs to somehow save events and not drop them? Memory usage is not a problem for me, if this causes more memory usage It's fine by me, I just don't want to lose any event. Is there anyway I can achieve this?

Even when I set the trace properties like below to a large number of buffers, I am still missing events. For example when I register to the Microsoft-Windows-RPC provider (which generates a lot of events):

    EVENT_TRACE_PROPERTIES properties = { 0 };
    properties.BufferSize = 128;
    properties.MinimumBuffers = 50;
    properties.MaximumBuffers = 500;
    properties.FlushTimer = 1;
    properties.LogFileMode = EVENT_TRACE_REAL_TIME_MODE;
    m_userTrace.set_trace_properties(&properties);

So why am I still missing events, even after setting the property to a large number of buffers (500 buffer in this case) ?

swannman commented 1 month ago

Hi @subvert0r, another technique would be to divide the ETW providers across multiple trace sessions. Each trace session gets its own buffer, so you can create a dedicated trace session for each of your noisiest providers and let the low-volume providers share the default one.

subvert0r commented 1 month ago

Hi @subvert0r, another technique would be to divide the ETW providers across multiple trace sessions. Each trace session gets its own buffer, so you can create a dedicated trace session for each of your noisiest providers and let the low-volume providers share the default one.

But why increasing the BufferSize and maximum number of buffers doesn't help in my case?

Any other way to solve this, other than creating a separate trace session?

swannman commented 1 month ago

I haven't experimented with configuring MinimumBuffers and MaximumBuffers, so I can't speak from experience here. If you the high volume of events is sustained, rather than a very short burst, then it makes sense that increasing the size or number of buffers would not solve the problem. Creating a separate trace session is the best way I'm aware of to solve this.