A Managed ETW Provider and the 15002 Error

I have been playing recently with the ETW (Event Tracing for Windows). One of my aims was to write a managed provider and try the ETW infrastructure in my application. Everything seemed to be well explained on the MSDN and was not very hard to implement (especially in my simple case). Unfortunately, not all things went smoothly and in this post, I’m going to show you an issue I run into as well as some general path when diagnosing broken ETW providers.

My provider was supposed to be as simple as is possible so my manifest file contained only the required fields:

<!--?xml version='1.0' encoding='utf-8' standalone='yes'?-->
<?xml version='1.0' encoding='utf-8' standalone='yes'?>
<instrumentationManifest xmlns="http://schemas.microsoft.com/win/2004/08/events">
  <instrumentation
      xmlns:win="http://manifests.microsoft.com/win/2004/08/windows/events"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <events xmlns="http://schemas.microsoft.com/win/2004/08/events">
      <provider guid="{369D265E-BE68-422B-A4DD-8778320F4D26}"
                name="TestAppChannelProvider"
                message="$(string.message.provider)"
                symbol="TestAppChannel"
                resourceFileName="C:\logs\etw\ApplicationChannelProvider.exe"
                messageFileName="C:\logs\etw\ApplicationChannelProvider.exe">

        <channels>
          <importChannel chid="appchnl" name="Application" />
        </channels>
        
        <events>
          <event value="101" 
                 message="$(string.message.event101)"
                 level="win:Informational"
                 channel="appchnl" />
        </events>
      </provider>
    </events>
  </instrumentation>
  <localization>
    <resources culture="en-US">
      <stringTable>
        <string id="message.event101" value="Test message" />
        <string id="message.provider" 
        value="Trace for application channel" />
      </stringTable>
    </resources>
  </localization>
</instrumentationManifest>

As you can see, it defines a provider that is emitting only one event (101) and this event is sent to the Application channel. By defining this kind of a provider, I wanted to see how this event will appear in the event viewer (what would be its source and XML data). After compiling the manifest, resources and application:

mc -cs ApplicationChannelProvider ApplicationChannel.man

rc ApplicationChannel.rc

csc /win32res:ApplicationChannel.res 
/debug+ /out:ApplicationChannelProvider.exe ApplicationChannel.cs Program.cs

I copied the binaries to the destination folder:

copy ApplicationChannelProvider.* c:\logs\etw

and installed the provider:

wevtutil im ApplicationChannel.man

The new provider appeared under the HKLM\Software\Microsoft\Windows\CurrentVersion\WINEVT registry:

A new key was also added to the HKLM\System\CurrentControlSet\Services\Eventlog\Application that defined the provider as an event source for the Application event log:

By comparing to other sources in the Application branch, we can see that there is a special key: ProviderGuid which links this event source to my provider. It means that the Windows Event Logging infrastructure is able to consume events from my provider and it should enable it. However, after I installed my provider and ran the application, I haven’t seen any new events in the Application log. So what was going wrong here?

I started looking for any trail of an error or any information in the system that might help me. Fortunately, I figured out that the ETW infrastructure is capable of logging itself actions and it even provides different channels for this purpose. After selecting “Show Analytic and Debug Logs” in the “View” menu in the Event Viewer window, I discovered two channels under the Microsoft-Windows-Eventlog subfolder:

Debug channel seems to be very detailed and provides some guids in the event data which, I suppose, bring some value only to the ETW developers. The Analytic channel on the other hand provides a more meaningful set of information and after enabling it, I found the error event I was looking for:

Detailed XML data:

<?xml version="1.0" encoding="UTF-8"?>
<Events>
   <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
         <Provider Name="Microsoft-Windows-Eventlog" 
         Guid="{fc65ddd8-d6ef-4962-83d5-6e5cfe9ce148}" />
         <EventID>102</EventID>
         <Version>0</Version>
         <Level>2</Level>
         <Task>101</Task>
         <Opcode>0</Opcode>
         <Keywords>0x800000000020000</Keywords>
         <TimeCreated SystemTime="2012-03-14T06:24:55.730708200Z" />
         <EventRecordID>6</EventRecordID>
         <Correlation />
         <Execution ProcessID="1052" ThreadID="4596" 
         ProcessorID="0" KernelTime="0" UserTime="0" />
         <Channel>Microsoft-Windows-EventLog/Analytic</Channel>
         <Computer>Sebastian-HP</Computer>
         <Security UserID="S-1-5-19" />
      </System>
      <UserData>
         <EventPublisherMetaDataFailure 
          xmlns="http://manifests.microsoft.com/win/2004/08/windows/eventlog" 
          xmlns:auto-ns3="http://schemas.microsoft.com/win/2004/08/events">
            <Error Code="15002" />
            <EventID>0</EventID>
            <PublisherName>TestAppChannelProvider</PublisherName>
            <PublisherGuid>{369D265E-BE68-422B-A4DD-8778320F4D26}</PublisherGuid>
            <ProcessID>0</ProcessID>
         </EventPublisherMetaDataFailure>
      </UserData>
   </Event>
</Events>

15002 is a Windows error code which (according to MSDN) signifies that “the publisher metadata cannot be found in the resource”. At least I had some clue where to start my searches. Unfortunately, there was again not much information about this error on the Internet. Finally, I stumbled upon Naveen’s blog with an excellent tutorial on writing a managed ETW provider. I followed the steps described there, changing only a channel to the Application one and to my surprise (and relief:)), the new event appeared in the Application log. So I started checking tag by tag which element of the manifest is missing in my case. I discovered that the problem lied in a missing template tag. After adding it (EMPTY one!) events started to appear in the Application log and no error logged. So my final manifest looked as follows (added lines are hightlighted):

<?xml version='1.0' encoding='utf-8' standalone='yes'?>
<instrumentationManifest xmlns="http://schemas.microsoft.com/win/2004/08/events">
  <instrumentation
      xmlns:win="http://manifests.microsoft.com/win/2004/08/windows/events"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <events xmlns="http://schemas.microsoft.com/win/2004/08/events">
      <provider guid="{369D265E-BE68-422B-A4DD-8778320F4D26}"
                name="TestAppChannelProvider"
                message="$(string.messageprovider)"
                symbol="TestAppChannel"
                resourceFileName="C:\logs\etw\ApplicationChannelProvider.exe"
                messageFileName="C:\logs\etw\ApplicationChannelProvider.exe">

        <channels>
          <importChannel chid="appchnl" name="Application" />
        </channels>
        
        <templates>
          <template tid="t1">
          </template>
        </templates>
        
        <events>
          <event value="101" 
                 message="$(string.messageevent101)"
                 level="win:Informational"
                 template="t1"
                 channel="appchnl" />
        </events>
      </provider>
    </events>
  </instrumentation>
  <localization>
    <resources culture="en-US">
      <stringTable>
        <string id="messageevent101" 
        value="Test message" />
        <string id="messageprovider" 
        value="Trace for application channel" />
      </stringTable>
    </resources>
  </localization>
</instrumentationManifest>

You may download the manifest and the application from my blog sample page.

As a general conclusion, if you ran into any problems while working with ETW, check the Microsoft-Windows-Eventlog/Analytic channel (sometimes maybe also Debug) and try to deduce the cause from the MSDN error description or search for it in the Internet. And remember to add templates for your events in your managed providers! :)

Filed under: CodeProject, ETW, Tracing