Why my ETW provider is now showing up in logman?

[dceravigupta]

I'm trying to log events using System.Diagnostics.Tracing.EventSource APIs but for some reason my provider is now showing up when I query list of providers using following logman command.

logman query providers

I was going through the following ETW documentation which says that "A provider must register with ETW " but could find a way to register my provider with ETW in .NET 8.0. Any suggestions?

Here is my sample code:
using System.Diagnostics.Tracing;

namespace EventSourceDemo
{
    public static class Program
    {
        public static void Main(string[] args)
        {
            while (true)
            {
                DemoEventSource.Log.AppStarted("Hello World!", 12);
            }
        }
    }
    
    [EventSource(Name = "Demo")]
    class DemoEventSource : EventSource
    {
        public static DemoEventSource Log { get; } = new DemoEventSource();
    
        [Event(1, Channel = EventChannel.Operational)]
        public void AppStarted(string message, int favoriteNumber) => WriteEvent(1, message, favoriteNumber);
    }
}

[tommcdon]

Hi @dceravigupta! The preferred tool for viewing ETW events with .NET is Visual Studio or Perfview - please see https://learn.microsoft.com/en-us/dotnet/core/diagnostics/eventsource-collect-and-view-traces. With that said, logman can be used to query the event and collect ETW traces. Since logman will only "see" the GUID describing the event (not the name "Demo"), I suggest modifying the EventSourceAttribute to use a custom-defined GUID, for example:

    [EventSource(Name = "Demo", Guid = "3FA42183-C480-4E08-92B6-86217E9CA6D8")]
    class DemoEventSource : EventSource
    {
        public static DemoEventSource Log { get; } = new DemoEventSource();

From an admin cmd prompt, running logman against the app's running PID (in my case it was 299924) and then filtering on the GUID should show that the event is present:

C:\trace>logman query providers -pid 299924 | findstr /i 3FA42183-C480-4E08-92B6-86217E9CA6D8
{3FA42183-C480-4E08-92B6-86217E9CA6D8}   {3FA42183-C480-4E08-92B6-86217E9CA6D8}

The GUID (along with curly braces) as well as the EventKeyword and EventLevel can be used to generate an ETW trace with logman. Note that I used the 0xF keyword bit mask, which will include all events in the sample above. I also used EventLevel 0x5 which is Verbose. The name of the session is "clrevents" in the sample below, which will be used to stop the trace. Also note the location of the output - I used C:\trace\MyDotNetTrace1.etl, so feel free to change that to a different path.

C:\trace>logman create trace clrevents -p "{3FA42183-C480-4E08-92B6-86217E9CA6D8}" 0xF 0x5 -o "C:\trace\MyDotNetTrace1.etl" -ets

Now run the app and the above trace should collect the events. To stop the ETW session, just run:

logman stop clrevents -ets

Now it should be possible to open the trace in an ETL viewer, such as perfview or Visual Studio. For example, I was able to open the trace generated using logman with VS 2022:

It is noteworthy that there are two ETW event formats - self-describing and manifest-based formats. The event format does not affect event discoverability but does make a small difference in event payload overhead.

Please let me know if this resolves the issue you are seeing.

[dotnet-policy-service]

This issue has been marked needs-author-action and may be missing some important information.