Open randomascii opened 4 years ago
I do think that in most cases -capturestate is only needed for circular buffer traces, but that is definitely not the case for Microsoft-Windows-DxgKrnl
- it does not emit state when it is enabled and so requires a capturestate call. I'm also pretty sure I've seen EventSource providers fail to emit their manifest without a capturestate command.
It also seems like capturestate command responses tend to be pretty cheap so I'd recommend erring on the side of doing unnecessary -capturestate commands.
Thanks for the feedback. I recently (August 20th, 410fc6e) found that the Microsoft-Windows-Win32k provider needs a -capturestate command in order to reliably get window focus information. That is, if you don't change focus and don't do a -capturestate for it then the window-in-focus graph will be blank. This explains problems that I had many years ago.
With my new and improving understanding of this I think that the existing usage should be retained (it is needed for some providers) and an additional invocation just before recording circular-memory buffers should be added.
And I'll add enough comments to serve as documentation, since the existing documentation seems to be insufficient.
The -capturestate option's behavior/intent/etc. is only lightly documented, however it appears that UIforETW is probably using it incorrectly. The documentation suggests that it is only needed for circular-buffer tracing whereas UIforETW always uses it:
https://docs.microsoft.com/en-us/windows-hardware/test/wpt/start
This comment suggests that -capturestate is best used just before recording the circular buffers, in order to get the EventSource to dump its manifest into the trace. https://blogs.msdn.microsoft.com/vancem/2014/04/10/more-on-using-eventsources-with-xperf-or-wpr/#comment-3903
So, probably UIforETW should be doing -capturestate just before recording circular buffer traces, and nowhere else.