Support .NET Native Interop events for CCW ref-counting views.

[vancem]

There is an EventSource in .NET Ntaive

C4AC552A-E1EB-4FA2-A651-B200EFD7AA91", Name = "System.Runtime.InteropServices.InteropEventProvider

internal sealed class InteropEventProvider

Which I believe provide events when CCW refcounts change. Make it so that PerfView 'ccf refcount' view works with them (For release project N builds).

Currently this functionality only works on Debug (coreCLR) builds of .NET Native.

[vancem]

I can help with details if anyone wishes to do this.

[0xGeorgii]

Hi, @vancem is it issue still actual? if yes, I'd like to grab it and ask you to provide the details, kindly mentioned above.

[vancem]

@GeorgePlotnikov. Sorry for the delay. Yes, this is still an issue. However please note that this something that will require some 'filling in the details' on your part. As a first step of this be clear that you care about this (that is you want to track down COM object lifetime problems in .NET Native). If not you are very unlikely to push through to create a working feature.

Assuming you want to continue you can generate events using the following PerfView command

PerfView /providers=c4ac552a-e1eb-4fa2-a651-b200efd7aa91:@enableStacks=true 

You can run any .NET Native app you like (I choose the built in Photos app since it is available on any win10 box). In theory you can also use CoreRT apps (you can see the source code for this provider and where these events are fired in the CoreRT tree (e.g. https://github.com/dotnet/corert/blob/master/src/System.Private.Interop/src/System/Runtime/InteropServices/InteropEventProvider.cs)).

Opening the resulting data file, you will find in the 'events' view

Event Name                                                            	Time MSec
System.Runtime.InteropServices.InteropEventProvider/TaskRCWRefCountInc	2,553.505
System.Runtime.InteropServices.InteropEventProvider/TaskCCWRefCountDec	2,553.752

These are the interesting events.

There is already a view called 'CCW Ref Count'. Its code lives in PerfViewData.cs (around line 4122, search for CCW). you can see that it is simple, simply logging the stack at the location with a positive or negative value (depending on whether the count is going up or down). The view will naturally keep track of the sum and thus the outstanding count.

Basically your job is to make this work with these new events. You can actually use the same view and code since there is no ambiguity since a process can't both had the CLR CCW events and the native ones.

To keep things simple, we are not going to declare a static C# type for these events but use the 'on the fly' capabilities of TraceEvent. Thus you drop the 'ByEventType' but then had to test event to confirm it the event you wish to filter on (check the ProviderGuid and the EventName). The rest should be straightforward.

I have not probably explained things enough but this should get you started, and you can ask questions as you get stumped. But before you start, you should have a clear idea of what you are building and that you WANT to build it (again feel free to discuss with me).

[0xGeorgii]

@vancem thank you very much for your detailed explanation. I'll do that.

[0xGeorgii]

@vancem, sorry for the long response. I want to confirm if I'm on the right way. I dumped the event TaskRCWRefCountInc and realised that is use ProviderGuid="c4ac552a-e1eb-4fa2-a651-b200efd7aa91" which I couldn't find at the parsers. So I think to add the new parser/provider and add to it the new events. Am I right?

[vancem]

@GeorgePlotnikov - There are two possibilities for parsing. The first is to use the dynamic parser. In this technique you would use the 'reflection' style APIs on the TraceEvent base class to filter by string name, and use the PayloadByName and casts to get fields. You can see an example of this in PerfViewdata.cs in the code for parsing MethodCallLogger events.

However this technique is not a good idea for events where you care about efficiency and/or have a bunch of fields to fetch (you can see that it is rather verbose to fetch a field. The way to avoid this is to use statically compiled defintions of the events. You do this by

1. Getting the Manifest for the EventSource (You can do this by executing the command

perfVIew usercommand DumpEventSourceManifests DataFile.etl

On a data file that has events from the EventSource you care about. This produces a number of *.manifest.xml files (one for each EventSource in the ETL file).
2. Creating the C# code to parse the events. This is what the 'traceParserGen.exe (it is one of the projects you build in PerfView). on the XML file you care about.

I happened to have done this for the InteropEventProvider and here is the result. (The file below has a txt suffix to make GitHub happy, you need to remove that when you add it to the project).

System.Runtime.InteropServices.InteropEventProvider.cs.txt

Basically you should put this code into the 'parsers' directory and then you can attach it your source to get parsed events. You can look at the IisTraceEventParser as a template of how to do this. Note that the class name of the parser is typically not good (too long) change SystemRuntimeInteropServicesInteropEventProviderTraceEventParser to simply InteropTraceEventParser.

I would recommend you use the static approach.

[0xGeorgii]

@vancem I added PR please review the idea.

[0xGeorgii]

Hello, @vancem I've updated PR.

[brianrob]

Fixed via #447.