Here is how to make a custom event source for ETW (Event Tracing for Windows) work on Windows 10 IoT Core. It’s not as simple as developers of business solutions are used to Microsoft's tooling to be, but it’s also not too complex or time-consuming to do. This article introduces a simple logging class and steps to make it work on Windows 10 IoT Core.

The source code here comes from my TemperatureStation IoT solution on GitHub.

Creating an ETW Event Source

Here is the class I’m using for logging to the ETW trace on a RaspberryPi. I’m using a custom ILogger interface to support more, different loggers.

[EventSource(Name = “TemperatureStationEventSource”)]
internal sealed class TemperatureStationEventSource : EventSource, ILogger
{
    [Event(1, Level = EventLevel.Verbose, Channel = EventChannel.Debug)]
    public void Debug(string message)
    {
        WriteEvent(1, message);
    }
    [Event(2, Level = EventLevel.Informational, Channel = EventChannel.Debug)]
    public void Info(string message)
    {
        WriteEvent(2, message);
    }

    [Event(3, Level = EventLevel.Warning, Channel = EventChannel.Debug)]
    public void Warn(string message)
    {
        WriteEvent(3, message);
    }

    [Event(4, Level = EventLevel.Error, Channel = EventChannel.Debug)]
    public void Error(string message)
    {
        WriteEvent(4, message);
    }

    [Event(5, Level = EventLevel.Critical, Channel = EventChannel.Debug)]
    public void Critical(string message)
    {
        WriteEvent(5, message);
    }
}

I wanted the trace logs from my IoT background service to be shown in the web interface of my RaspberryPi. But no matter what I tried, my traces just didn’t get there. Yes, I also tried the custom providers stuff by GUID, but still no luck. So I started looking for a way how to get my event source registered.

Registering the ETW Trace Provider

After some searching on the web, I found a working solution. There’s some tricking and hacking needed to get the new event source registered. Here are the steps.

1. Add a reference to the NuGet package Microsoft.Diagnostics.Tracing.EventSource.
2. Build the application, get the error, and take the failed command (with copy and paste) to a text editor. Remove all the other stuff besides the command that was run. It should look similar to this: 

“C:\Users\XXX\.nuget\packages\Microsoft.Diagnostics.Tracing.EventRegister\1.1.28\build\eventRegister.exe” -DumpRegDlls @”D:\Projects\TemperatureStation\TemperatureStation.IoT.Service\bin\ARM\Debug\

TemperatureStation.IoT.Service.eventRegister.rsp” “D:\Projects\TemperatureStation\TemperatureStation.IoT.Service\

bin\ARM\Debug\TemperatureStation.IoT.Service.winmdobj”




3. Remove the reference to Microsoft.Diagnostics.Tracing.EventSource. Your application builds now, but the package is still available on your machine.
4. Change the file name in the previously copied command from winmdobj to winmd (important!): 

“C:\Users\XXX\.nuget\packages\Microsoft.Diagnostics.Tracing.EventRegister\1.1.28\build\eventRegister.exe” -DumpRegDlls @”D:\Projects\TemperatureStation\TemperatureStation.IoT.Service\bin\ARM\Debug\

TemperatureStation.IoT.Service.eventRegister.rsp” “D:\Projects\TemperatureStation\TemperatureStation.IoT.Service\

bin\ARM\Debug\TemperatureStation.IoT.Service.winmd”

5. Take the command with copy-paste and run it on a command prompt.
6. Check if two new files were created in the bin folder of application. The names should be similar to ones I got with my TemperatureStation IoT service: TemperatureStation.IoT.Service.TemperatureStationEventSource.etwManifest.dll
TemperatureStation.IoT.Service.TemperatureStationEventSource.etwManifest.man
   
7. Copy the files to some folder on the Raspberry.
8. Log into the Raspberry using PowerShell. Move to the folder where you put those two files and run the following command (replace the placeholders with the real file names, of course):

wevtutil.exe im <EtwManifestManFile> /rf:”<EtwManifestDllFile>” /mf:”<EtwManifestDllFile>” 




9. Check your browser to see if your provider is listed in the ETW providers list.
10. If it’s not there, then restart Raspberry.

Supposing everything went fine the new event source should appear in providers dropdown on ETW traces page of RaspberryPi. But there’s one little gotcha.

Saving ETW Traces for Later Use

The previous solution works only when ETW traces are monitored through the browser, but the traces are not saved for later use. If trace logs must be saved, then log into the Raspberry Pi using PowerShell and run the following command (change MyEwtProvider to the provider name you are using): echo y | wevtutil.exe sl MyEwtProvider/Debug /e:true 

To get archived trace logs, use the following command on the Raspberry Pi when logged in using PowerShell: wevtutil.exe qe MyEwtProvider/Debug  

Saved logs should also be available on the ETW traces page of the Raspberry Pi.

Wrapping Up

ETW logging is not easy to understand and implement when doing it the first time. Manual registering of ETW event sources was a little bit of a surprise to me. Also, the fact that there is incompatible component that fails during the build was surprising. But in the end, I was able to get things working the way I needed. I hope it saves time for those who need ETW traces on a Raspberry Pi.