Hi there,

I get a panic when I try to call .stop() on a Kernel Trace. Basic code:

let provider_io = Provider::kernel(&kernel_providers::FILE_IO_PROVIDER)
    .build()
    .unwrap();

let mut trace = KernelTrace::new()
    .named(String::from("HijackWatcher"))
    .enable(provider_io)
    .start()
    .unwrap();

std::thread::sleep(Duration::new(3, 0));
trace.stop();

Strack Trace:

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', C:\Users\xxx\.cargo\registry\src\github.com-1ecc6299db9ec823\ferrisetw-0.1.1\src\trace.rs:112:30
stack backtrace:
   0:     0x7ff6de00a782 - std::backtrace_rs::backtrace::dbghelp::trace
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\..\..\backtrace\src\backtrace\dbghelp.rs:98
   1:     0x7ff6de00a782 - std::backtrace_rs::backtrace::trace_unsynchronized
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\..\..\backtrace\src\backtrace\mod.rs:66
   2:     0x7ff6de00a782 - std::sys_common::backtrace::_print_fmt
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\sys_common\backtrace.rs:66
   3:     0x7ff6de00a782 - std::sys_common::backtrace::_print::impl$0::fmt
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\sys_common\backtrace.rs:45

Windows version:

OS Name:                   Microsoft Windows 11 Pro
OS Version:                10.0.22621 N/A Build 22621

Closes #16

This is using the basic Rust action automatically suggested by GitHub. The stock https://github.com/BamPeers/rust-ci-github-actions-workflow you suggested seems to run on Ubuntu. I'm not sure forking and customizing it is worth it.

I think we'll always be able to add clippy, rustfmt, etc. later from this first step

ENABLE_TRACE_PARAMETERS has a pointer (A) to an array of EVENT_FILTER_DESCRIPTORs, which contains pointers (B) themselves. I cared about the lifetime of pointers A and B, but forgot about the lifetime of the array, which was actually dropped very soon :-(

Now this array is owned by EnableTraceParameters, which fixes this dangling pointer issue.

This bug could lead to failing enabling providers, with EtwNativeError(IoError(Os { code: 87, kind: InvalidInput, message: "The parameter is incorrect." }))

This PR depends on #63 and #65 , as its first commits come from them.

This makes it possible to use the turbofish operator for try_parse, which is slightly more convenient than the current solution. This improvement was already considered by @n4r1b quite a long time ago, since there was a // TODO: Find a way to use turbofish operator

1. Add a trace builder to clearly separate operations that are only valid at build-time vs. ones that can be performed on a live session
2. Remove the internal worker thread, preferring to expose that to end-users so that they may decide how to begin processing a trace. Also todo - expose start/end times from ProcessTrace in the API
3. Basic support for querying/setting trace information, and add an example of dumping all profile sources in the system

This PR depends on #63 , #65 , #66 and #68 (it does not depend on all of them feature-wise, but merging them first will avoid git conflicts, especially in the use ....; lines at the beginning of files)

This PR (or rather, its last 5 commits) reviews the visibility of many types and modules, so that the user-facing API and documentation only exposes what he will need.

• This makes it easier to read the doc
• This leaves us more room to do future changes that otherwise could be breaking (since breaking change in a public API requires a new major version. That's too bad for types that are not supposed to be used).

Maybe(?) some issues were pre-existing, but I think most of these too-widly-visible items were due to uncautious refactos of mine

This PR depends on #53 and #55 (as the first few commits are cherry-picked from these branches), that must be merged first.

This introduces a ProviderBuilder that must be used to create Providers. This way:

• setters can be removed from Provider, which will ensure it is not modified at runtime (this will help reviewing unsafe blocks and resolving #45 )
• the compiler now enforces GUID are set. No need to check it at runtime

Closes #46

@n4r1b , since this PR (and the few previous ones targetting master) add new items, without breaking back-compatibility. I think this could be a good time to release a 0.2 version, what do you think?

windows-rs version in ferrisetw's Cargo.toml is 0.39, but windows-rs version in my project is 0.42. This will cause the following error when compiling:

error[E0277]: the trait bound `Parser<'_>: TryParse<GUID>` is not satisfied
  --> src/main.rs:23:66
   |
23 |                     let guid: GUID = TryParse::<GUID>::try_parse(&mut parser, "Guid").unwrap();
   |                                      --------------------------- ^^^^^^^^^^^ the trait `TryParse<GUID>` is not implemented for `Parser<'_>`
   |                                      |
   |                                      required by a bound introduced by this call
   |
   = help: the following other types implement trait `TryParse<T>`:

My project can only be compiled by using windows-rs with the same version as ferrisetw.

Is there any good solution?

Hello, thanks for ferrisetw.

I've been experimenting with it for a few days now, and I'd like to extend and improve it (expect other merge requests soon :D ). To start with, I'm upgrading to a newer version of windows-rs. (tests are still passing of course. We may want to enable Github Actions on that repo though).

I've split into several commits for better review-ability, but only the last one actually compiles, so you'd probably want to squash them when merging.

Hi, I really like the work you've done here, good job!

For my purposes, I usually want to start a trace, and run it until I quit the program. In the current implementation Ferris spawns a new anonymous thread to do the processing, which means I need to either do a 'sleep forever' or 'wait for user input' hack.

Would it be possible to either:

• Run a trace in the same thread (e.g. 'blocking' mode); or
• Expose the spawned thread in the Trace struct, so I could do a .join on it

This MR brings back all the commits added to next_major_version in the course of the last months into master, because I feel like ferrisetw may be ready to release a newer version.

However, we could try releasing 0.1.2 first (from the current master, e.g. to check docs.rs succeeds at generating its doc)

Maybe ferrisetw could be used to list and control already existing traces.

See QueryAllTracesW : https://learn.microsoft.com/en-us/windows/win32/api/evntrace/nf-evntrace-queryalltracesw

Could it also stop them? Subscribe to them? etc.

Property::new() can return PropertyError::UnimplementedType, depending on the TDH property flags.

This would be good to support more types (e.g. PropertyFlags::PROPERTY_STRUCT, or PropertyFlags::PROPERTY_PARAM_LENGTH)

That's what is suggested by Clippy

warning: usage of `Box<Arc<CallbackData>>`
   --> src\trace.rs:173:20
    |
173 |     callback_data: Box<Arc<CallbackData>>,
    |                    ^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: `#[warn(clippy::redundant_allocation)]` on by default
    = note: `Arc<CallbackData>` is already on the heap, `Box<Arc<CallbackData>>` makes an extra allocation
    = help: consider using just `Box<CallbackData>` or `Arc<CallbackData>`
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#redundant_allocation

In our case, we do not only want the CallbackData to be on the heap, but the ref counter as well. https://github.com/rust-lang/rust/blob/96ddd32c4bfb1d78f0cd03eb068b1710a8cebeef/library/alloc/src/sync.rs#L352 suggests the ref counters (both atomic::usizes) really live on the heap, so this change should be sensible.

That's to avoid an allocation, on a struct that's only created a handful of times, this currently properly works that way, and it's a private implementation detail of the crate (so it can be changed at anytime without any trouble for the users), so I'm leaving this for later.

Since (a PR to come, probably #63), we're ignoring the very last ETW events that were still in the buffers when we called CloseTrace

We may want to process them, and drop the memory structures when we're sure every event is processed. See

/// TODO: it _might_ be possible to know whether we've processed the last buffered event, as
///       ControlTraceW(EVENT_TRACE_CONTROL_QUERY) _might_ tell us if the buffers are empty or not.
///       In case the trace is in ERROR_CTX_CLOSE_PENDING state, we could call this after every
///       callback so that we know when to actually free memory used by the (now useless) callback.
///       Maybe also setting the BufferCallback in EVENT_TRACE_LOGFILEW may help us.

Currently, we have

EventTraceProperties {
    etw_trace_properties,
    trace_name: [0; 1024],
    log_file_name: [0; 1024],
};

We could avoid using two arrays of 1024 bytes to store a string that's probably shorter than this. Maybe we could make EventTraceProperties generic on the name length, or really support dynamic allocation of the name