Does krabs etw handle trace closure in case of program crash? Can it cause a problem in enabling and starting the same session again?

[subvert0r]

Assume that my process that is using krabs etw to register a user and kernel trace, goes in a crash loop (or multiple crashes in a row).

My question is, does krabs etw handle this case properly, so we wouldn't reach the maximum number of allowed trace sessions, or be able to register a new session with the same session name? Note that for both the kernel trace and user trace, I am using a constant trace name (not a random guid).

Do I actually need to call the stop function of my krabs::user_trace and krabs::kernel_trace before calling the start to handle this case? In this case, then what about the usage of T::trace_type::get_trace_guid() in trace_manager<T>::stop_trace()? Krabs seems to be generating a random guid for every new session, thus calling the stop function with the new program instance wouldn't amount to much I assume for closing the previous trace session since we dont have its guid anymore, right?

Also on another note, am I reading this code wrong, or Krabs is generating a new random guid everytime its calling get_trace_guid? Shouldn't it store the generated guid somewhere and use that after its generated?

    inline krabs::guid ut::get_trace_guid()
    {
        return krabs::guid::random_guid();
    }

[swannman]

You're doing the right thing by using a constant name for your trace session!

My understanding is:

• The trace session GUID is unused except when subscribing to the single instance of the NT Kernel Logger session
  • Docs (see "Guid"): https://learn.microsoft.com/en-us/windows/win32/etw/wnode-header
  • Here's where we use the appropriate GUID for the kernel trace if we're on an OS version where we must use the single NT Kernel Logger session: ref
• If you attempt to re-register a trace with a name that already exists, krabs will stop and restart the trace for you: ref

I would recommend building a small prototype to verify the behavior, but it looks to me like this case is handled gracefully today.

[subvert0r]

I Just found an edge case for this:

In case of using Microsoft-Windows-Security-Auditing which our trace session name should be EventLog-Security and we should be running as SYSTEM, even If my program doesn't crash, but I run it multiple times, after a few run, I get the following error when calling the start function of the user trace:

No more trace sessions available

EDIT: Nevermind it was a strange bug in my code that its hard to explain.