ETW API pain points #937
Comments
|
Thanks Nicolas, great feedback. Some of this is on the win32 metadata and some may be possible for the |
|
Most of these issues stem from problems with the win32 metadata, so I'll transfer the issue to that repo for resolution. The question about null terminated string literals is interesting. I'll open a separate issue for that here. |
kennykerr
added
bug
mikebattista
added
usability
|
One additional more here. Etw unfortunately used TRACEHANDLE with two different apis that sound related but are not. StartTrace and ControlTrace use the same meaning of TRACEHANDLE, which is distinct from the handle of OpenTrace/ProcessTrace/CloseTrace. A projection would hopefully fix this. |
These things are MOF definitions for events, and are provided on MSDN for illustrative purposes only. You aren't supposed to hard-code those structures or values anywhere; use TDH to decode your events or use the lower-level WBEM APIs to query for the definitions and then parse the output per the MOF spec (but don't actually do this - use TDH). |
|
Windows.Win32.System.Diagnostics.Etw.Apis.StartTraceW : return...UInt32 => WIN32_ERROR |
|
Windows.Win32.System.Diagnostics.Etw.ITraceRelogger.AddLogfileTraceStream : TraceHandle...UInt64* => TRACEHANDLE* |
|
Windows.Win32.System.Diagnostics.Etw.Apis.ALPCGuid not found in 1st winmd |
|
Windows.Win32.System.Diagnostics.Etw.TRACEHANDLE not found in 2nd winmd |
|
@idigdoug please review the above diff. |
|
Looks good. |
|
Note that the Most or all of the remaining issues appear to be resolved and have made their way into the Rust project. |
|
Thanks. Will close this out then. |
I've been using the ETW API, and I found a few things that seem odd in the generated bindings. I'm not sure if these are windows-rs problems, or metadata problems. First:
windows::Win32::System::SystemServices::SE_SYSTEM_PROFILE_NAMEand other strings next to it are&str's, but the APIs that it's used with require a null terminator, so I had to manually add it (For exampleLookupPrivilegeValueA)windows::Win32::System::Diagnostics::Etw::KERNEL_LOGGER_NAMEAThat seemed like the biggest problem and the only thing I encountered that clearly looks wrong. Then there's some things that surprised me and could maybe be improved but that are not necessarily wrong:
windows::Win32::System::Diagnostics::Etw::TraceSetInformationreturns a u32. This is what it is documented as returning in https://docs.microsoft.com/en-us/windows/win32/api/evntrace/nf-evntrace-tracesetinformation but since the return value must be checked against ERROR_SUCCESS which in windows-rs is a separate WIN32_ERROR type, it makes things a bit awkwardwindows::Win32::System::Diagnostics::Etw::ControlTraceAandStartTraceAStartTraceAandControlTraceA. On msdn they're documented as using "TRACEHANDLE" which probably typedefs to that. I'm not sure if it'd be a good idea to add a TRACEHANDLE wrapper type (LikeHANDLE), but I'm mentioning in case that's desireable.EVENT_ENABLE_PROPERTY_STACK_TRACEshould be 32.ClientContextclock resolution constants from https://docs.microsoft.com/en-us/windows/win32/etw/wnode-header anywhere in windows-rs. I'm not sure they're even present in the headers.The text was updated successfully, but these errors were encountered: