Data sent by the Microsoft-Windows-DotNETRuntime ETW provider doesn't match event description from the docs
We are trying to read events from the Microsoft-Windows-DotNETRuntime ETW provider via ETW sessions in the following way:
tracerpt "session.etl" -o "result.xml".And we receive the following event:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-DotNETRuntime" Guid="{e13c0d23-ccbc-4e12-931b-d9cc2eee27e4}" />
<EventID>152</EventID>
<Version>2</Version>
<Level>4</Level>
<Task>10</Task>
<Opcode>33</Opcode>
<Keywords>0x20000008</Keywords>
<TimeCreated SystemTime="2020-12-18T10:12:53.537830900+00:00" />
<Correlation ActivityID="{00000000-0000-0000-0000-000000000000}" />
<Execution ProcessID="6920" ThreadID="6612" ProcessorID="0" KernelTime="15" UserTime="15" />
<Channel />
<Computer />
</System>
<UserData>
<ModuleLoadUnload_V2 xmlns='myNs'><ModuleID>0x7FF833711000</ModuleID><AssemblyID>0x1AA03BE0</AssemblyID><ModuleFlags>11</ModuleFlags><ModuleILPath>0</ModuleILPath><ModuleNativePath>C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.Management.Infrastructure\v4.0_1.0.0.0__31bf3856ad364e35\Microsoft.Management.Infrastructure.dll</ModuleNativePath><ClrInstanceID>C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\Microsoft.Mf49f6405#\568c843a2159d22391f14ec8680868a6\Microsoft.Management.Infrastructure.ni.dll</ClrInstanceID><ManagedPdbSignature>37</ManagedPdbSignature><ManagedPdbAge>{ae53edfa-f525-412e-b901-1895653e435a}</ManagedPdbAge><ManagedPdbBuildPath>1</ManagedPdbBuildPath><NativePdbSignature>Microsoft.Management.Infrastructure.pdb</NativePdbSignature><NativePdbAge>{568c843a-2159-d223-91f1-4ec8680868a6}</NativePdbAge><NativePdbBuildPath>1</NativePdbBuildPath></ModuleLoadUnload_V2>
</UserData>
<RenderingInfo Culture="ru-RU">
<Level>Information </Level>
<Opcode>ModuleLoad </Opcode>
<Keywords>
<Keyword>Loader </Keyword>
<Keyword>PerfTrack </Keyword>
</Keywords>
<Task>Loader </Task>
<Message>ModuleID=0x7FF833711000;
AssemblyID=0x1AA03BE0;
ModuleFlags=DomainNeutral |Native |Manifest ;
ModuleILPath=0;
ModuleNativePath=C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.Management.Infrastructure\v4.0_1.0.0.0__31bf3856ad364e35\Microsoft.Management.Infrastructure.dll;
ClrInstanceID=C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\Microsoft.Mf49f6405#\568c843a2159d22391f14ec8680868a6\Microsoft.Management.Infrastructure.ni.dll;
ManagedPdbSignature=37;
ManagedPdbAge={ae53edfa-f525-412e-b901-1895653e435a};
ManagedPdbBuildPath=1;
NativePdbSignature=Microsoft.Management.Infrastructure.pdb;
NativePdbAge={568c843a-2159-d223-91f1-4ec8680868a6};
NativePdbBuildPath=1 </Message>
</RenderingInfo>
</Event>
As you can see, fields have the wrong type, e.g., NativePdbAge and ManagedPdbAge have win:GUID type, but in the docs, it has win:UInt32 type. Other fields have the wrong type too.
But we can read these events via Windows API with our library https://github.com/bi-zone/etw.
Properties from the same event, but parsed via TdhFormatProperty function:
{
"AssemblyID": "0x1AA03BE0",
"ClrInstanceID": "37",
"ManagedPdbAge": "1",
"ManagedPdbBuildPath": "Microsoft.Management.Infrastructure.pdb",
"ManagedPdbSignature": "{ae53edfa-f525-412e-b901-1895653e435a}",
"ModuleFlags": "DomainNeutral |Native |Manifest ",
"ModuleID": "0x7FF833711000",
"ModuleILPath": "C:\\WINDOWS\\Microsoft.Net\\assembly\\GAC_MSIL\\Microsoft.Management.Infrastructure\\v4.0_1.0.0.0__31bf3856ad364e35\\Microsoft.Management.Infrastructure.dll",
"ModuleNativePath": "C:\\WINDOWS\\assembly\\NativeImages_v4.0.30319_64\\Microsoft.Mf49f6405#\\568c843a2159d22391f14ec8680868a6\\Microsoft.Management.Infrastructure.ni.dll",
"NativePdbAge": "1",
"NativePdbBuildPath": "Microsoft.Management.Infrastructure.ni.pdb",
"NativePdbSignature": "{568c843a-2159-d223-91f1-4ec8680868a6}",
"Reserved1": "0"
}
And we see that all properties have the correct type.
The question is: why the windows utilities can't read events from the Microsoft-Windows-DotNETRuntime ETW provider in the right format? Whom should we believe? :)
BTW, It reproduces in different windows hosts: win10 1903, win10 1909, win10 1809.
I've attached the etl file from which the example was parsed.
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
@sywhang Do you know who could answer this question about the correct types for NativePdbAge and ManagedPdbAge?
@gewarren that would be me.
@MashaSamoylova First of all thanks for reporting this issue - NativePdbAge is indeed a UInt32 type. The .NET runtime emits it as a UInt32 type. For reference on .NET ETW event payload types, the docs have the latest up-to-date info as the runtime team is directly updating it as we add/modify events. The ground truth is of course the source that generates these events - the runtime generates the code that emits them at compile-time using this XML manifest file - I will be updating the docs page when events are modified or added so that you don't have to view this all the time but when there is doubt, you can refer to this : )
The TraceEvent library is our current recommendation for parsing .NET ETW events and it is what we use to test our events, so you shouldn't see any discrepancies between the doc and what you see from TraceEvent.
To answer your other question on why the Windows utilities is messing up the type - I'm actually not sure why that's happening. But looking at the payload you reported, it seems like there is some kind of offset error happening from tracerpt side. I will find out which team within Microsoft is in charge of tracerpt and report the issue - thank you.
Most helpful comment
@gewarren that would be me.
@MashaSamoylova First of all thanks for reporting this issue - NativePdbAge is indeed a UInt32 type. The .NET runtime emits it as a UInt32 type. For reference on .NET ETW event payload types, the docs have the latest up-to-date info as the runtime team is directly updating it as we add/modify events. The ground truth is of course the source that generates these events - the runtime generates the code that emits them at compile-time using this XML manifest file - I will be updating the docs page when events are modified or added so that you don't have to view this all the time but when there is doubt, you can refer to this : )
The TraceEvent library is our current recommendation for parsing .NET ETW events and it is what we use to test our events, so you shouldn't see any discrepancies between the doc and what you see from TraceEvent.
To answer your other question on why the Windows utilities is messing up the type - I'm actually not sure why that's happening. But looking at the payload you reported, it seems like there is some kind of offset error happening from tracerpt side. I will find out which team within Microsoft is in charge of tracerpt and report the issue - thank you.