You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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:
While for manifest-based ETW this should uniquely identify an event, this is not the case for TraceLogging, as mentioned in the docs:
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 sameschema_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 theEVENT_RECORD
struct before calling toTdhGetEventInformation
, 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
The text was updated successfully, but these errors were encountered: