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
I'm using Lobster to monitor changes happening in the registry. I've encountered a scenario where i need to be in control of EVENT_FILTER_DESCRIPTOR before it is passed to EnableTraceEx2 via the ENABLE_TRACE_PARAMETERS struct. This is because there is undocumented behavior in the registry provider that allows gathering additional data when setting the EVENT_FILTER_DESCRIPTOR.Ptr value accordingly.
Are you aware of a way to control this value from lobster or is it possible to enable the provider myself and catch the callback via a lobster callback in the native layer?
I can also come up with a PR in case you want to include this ability in Lobster.
Thanks!
The text was updated successfully, but these errors were encountered:
Hi @ps1337, would you be able to share an example of using the undocumented functionality in EVENT_FILTER_DESCRIPTOR? Rather than exposing the pointer directly, I'm curious whether we can expose this capability in the library the same way we supported provider-based filtering here. Thanks!
Hello Krabs Team :)
I'm using Lobster to monitor changes happening in the registry. I've encountered a scenario where i need to be in control of EVENT_FILTER_DESCRIPTOR before it is passed to EnableTraceEx2 via the ENABLE_TRACE_PARAMETERS struct. This is because there is undocumented behavior in the registry provider that allows gathering additional data when setting the EVENT_FILTER_DESCRIPTOR.Ptr value accordingly.
Are you aware of a way to control this value from lobster or is it possible to enable the provider myself and catch the callback via a lobster callback in the native layer?
I can also come up with a PR in case you want to include this ability in Lobster.
Thanks!
The text was updated successfully, but these errors were encountered: