Wrong schema retrieval with TraceLogging events

Since querying the schema can be a demanding task, a cache is used in krabs::schema_locator to speed up schema retrieval for future events.

The cache key is calculated using the following event attributes:

• Provider ID
• Event ID
• Opcode
• Level
• Version

While for manifest-based ETW this should uniquely identify an event, this is not the case for TraceLogging, as mentioned in the docs:

For manifest-free ETW (i.e. TraceLogging), the Id field is usually not meaningful and will normally be set to 0. TraceLogging events are generally identified by their event name, not the event ID.

The result is that two events emitted by the same provider with the default level and opcode are considered to have the same schema, which is clearly wrong. Parsing the second event with the same trace_context (And hence the same schema_locator) will use the first event's schema, and will most probably fail if they don't share the same fields in the same order.

I would suggest adding the event name to the schema_key for TraceLogging events, but it is not available in the EVENT_RECORD struct before calling to TdhGetEventInformation, which is exactly the call we are trying to avoid.
Another option is to parse it from the relevant EVENT_HEADER_EXTENDED_DATA_ITEM struct, but is undocumented.

Would appreciate your help here - am I missing something?

Thanks

Start by reading the schema_locator and schema_key implementation, then trace how EVENT_RECORD data reaches TdhGetEventInformation and how TraceLogging metadata is represented by EVENT_HEADER_EXTENDED_DATA_ITEM. Confirm the cache collision with two same-provider TraceLogging events, and define a reliable distinction that preserves manifest-based retrieval before adding regression coverage.