Historically we had an unnecessary divide between ETW events that were available asynchronously out-of-proc and ICorProfile API callbacks that were available synchronously in-proc. Some events were available via one source, some via the other, and some via both. Although it is technically possible to create profilers that register for both streams of events it is needlessly complex and it is impossible to make the async ETW events become synchronous again. To mitigate these issues we want to make all of the ETW events available synchronously via an ICorProfile callback. And because we are cross platform now, ETW events are better abstracted as EventPipe events so that this will work properly on non-Windows platforms too.

We already had a past effort at doing this in PR dotnet/coreclr#19157 and a little bit of discussion of it in #5638. The dotnet/coreclr#19157 attempt handled receiving the EventPipe events fine, but it didn't include a mechanism to enable the events. To use it, a profiler would need to configure the set of desired events via an out-of-band mechanism such as environment variables or managed EventListener APIs. Although this would work for some scenarios, I expected it would be onerous in the common case and it would be awkward to migrate from that form of API to one where ICorProfile also had direct control over the set of events it was receiving.

Work to do:

• Add multi-session support to EventPipe so that the ICorProfile client's event settings need not interfere with other EventPipe clients. Create the Concept of Multiple EventPipe Sessions #9388, Implement Session-based Filtering for EventSource #11435
• Add EventPipe event control APIs to ICorProfile so that the profiler can select which events it wants to receive
• Update/complete any work necessary in the EventPipe listening APIs implemented in PR Add support for writing EventPipeEvents to ProfAPI coreclr#19157