UIforETW should use -capturestate correctly

[randomascii]

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.

[Zhentar]

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.

[randomascii]

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.