I use netsh trace start/convert on a provider and get some results. But most of the lines in the converted file indicate that they cannot be decoded.
Is it because MS leaves some TMF info in public symbol files but full set is only available in private PDBs.
Are ETWs closely gaurded or MS wants to give developers access.
An ETL file can contain multiple flavors of traces:
Each has their own requirements to “decode” the trace.
ETW events are decoded through a manifest that’s usually shipped with the OS. Most ETW events aren’t “secret”. If you get errors decoding an ETW event, the most likely cause is that you’re trying to decode the events on a different OS than they were captured on.
We generally try to maintain backwards compatibility with ETW events, so if you’re running OS version N+1, you can usually decode events from OS version N. But mistakes happen, so this isn’t always 100% perfect. Also, sometimes the manifests can be removed by the featureset of the OS. E.g., if you are collecting Hyper-V traces, you might need to install Hyper-V on your OS in order to decode its traces.
WPP events are decoded through a TMF, which is typically bundled into a PDB. WPP traces have historically been considered “secret”, so by default our toolchain strips them out of PDBs before we publish the PDBs. A small handful of platform components (like NDIS) do the extra work to re-enable WPP traces in the public PDBs. A few other components ship the raw TMF files. But in general, you can’t decode most WPP traces. You’ll get messages like Unknown( ##): GUID=### (No Format Information found). when this happens.
TraceLogging events don’t really need a decode phase; they’re just JSON. You can extract the event payload as text and run it through your favorite JSON reader. Although some tools can do a nicer job of formatting, e.g., timestamps and other standard metadata.