krabsetw icon indicating copy to clipboard operation
krabsetw copied to clipboard

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

Open subvert0r opened this issue 1 year ago • 3 comments

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) ?

subvert0r avatar May 29 '24 14:05 subvert0r

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.

swannman avatar May 31 '24 04:05 swannman

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?

subvert0r avatar Jun 03 '24 15:06 subvert0r

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.

swannman avatar Jun 03 '24 16:06 swannman