TraceEvent - don't use undocumented APIs

[idigdoug]

Stop using ETWControl and ETWParsing from OSExtensions.dll. Replace them with implementations that use Microsoft-supported APIs.

• Use TraceSetInformation for configuring profile interval (no change from existing behavior other than using supported API).
• Use TraceSetInformation for configuring stack caching (same behavior, except that the new API is only supported on Windows 10 19582+).
• Use TdhEnumerateManifestProviderEvents for reading manifest data (works perfectly for manifests, but doesn't work for MOF).

Still using OSExtensions.dll for KernelTraceControl stuff, but that's supported by Microsoft. So perhaps the KernelTraceControl stuff could move into TraceEvent and then OSExtensions.dll would no longer be needed at all.

[pharring]

@brianrob code LGTM, but over to you to decide if this is moving the right direction vis-a-vis OSExtensions.dll (and possible support for downlevel OSes)

[brianrob]

Thanks for reviewing @pharring. I am in the process of testing this to see how it impacts existing scenarios.

[pharring]

The PerfCollect unit tests are failing due to a leaking SafeTraceHandle. Implying that we forgot to Dispose a SafeTraceHandle.

[idigdoug]

This is puzzling to me because my change does not create or dispose any handles.

[pharring]

Are you able to run unit tests locally in VS?

I'm taking more than a passing interest in this because I introduced the SafeTraceHandle quite recently. There could certainly be a bug there or there could be legitimate cases where leaking a SafeTraceHandle is necessary or unavoidable.
If you click through the "Details" of the failing build and then through to the build log (assuming you have access), you can get more details, but personally, I can't determine exactly which test failed. The leak is reported as a debug assert, but it looks like that doesn't result in a specific test failure. Of course, finalizers can run any time, and most likely (long) after the culpable test has completed. I think XUnit calls GC.Collect and WaitForPendingFinalizers, but I'm not certain it's after every test case. All you can know is that it's at least one of the tests prior to the Debug.Assert.

[pharring]

Good job fixing the leak, @idigdoug Thank you!

[brianrob]

Thanks @idigdoug! I did some testing with this and all looks good.