TraceEvent ETW Library published as a NuGet Package


I am happy to report that the TraceEvent Library Nuget Package and the TraceEvent Library Samples Nuget Package have been published at www.nuget.org.   If you look for them be sure to set the filtering to include ‘prerelease’ or you will not see them.    You can see this blog entry for the formal announcement of the library.   If you have feedback on the library, you can either contact me through nuget or leave a comment on that blog (or this one). 

 The library has the TraceEvent programmers guide that comes with it that tells you about the architecture of the overall package and other useful background information. (note that the previous link is a copy of this guide, the most up to date version is the one that comes with the Nuget package). 

The TraceEvent library for thosewho do not know is the library that makes PerfView possible.   The TraceEvent library makes controlling and parsing Event Tracing for Windows (ETW) logging easy to do from managed code.   For a while now we had the TraceEvent bcl.codeplex.com site, which also has a version of the code, but NuGet is significantly easier to use and we are transitioning the library there.    The code in the NuGet package is significantly newer then the codeplex site (that site is currently 9 months old), so it recommend that you go there.   The NuGet package has some breaking changes, however in the release notes you will find porting instructions.   To give you a feel, it took about 2 hours to port PerfView over, and it is probably the heaviest user of the library. 

The TraceEvent Samples are also a nice addition.   It makes it very easy to see some examples usage that you can cut and paste to get started.   The easiest way to use this samples is to create a new Console application and then install the Samples NuGet package into that project.  

As previously discussed on this blog, there is a companion library EventSource Library Nuget Package and the EventSource Library Samples Nuget Package.    EventSource as you now is the class that allows your .NET code to easily EMIT logging messages to ETW (or other places).    EventSource is part of the .NET V4.5 and you should use the framework version if you can.   However we have added features to the NuGet package that are not available (yet) in the .NET Framework Version.   Another valuable aspect of the EventSource Nuget package is that it gives you COMPILE TIME feedback if you make errors creating your EventSource.   This can avoid some frustration.   The samples package is great for learning about the API, whether you use the Framework or Nuget version.   See this blog entry for more.

 

Vance

P.S: Finally I should note that while you are more than welcome to build stuff with TraceEvent, if the functionality you want is closer to what PerfView already gives, you should consider simply writing a PerfView extension/ user command.   For more on this simply see the docs under help -> Extending PerfView.

_TraceEventProgrammersGuide.docx

Comments (17)

  1. Jace says:

    Is there any way Perfview.exe could be made to run on a system that only has .NET 3.5 installed? The most recent version seems to require .NET 4.0.

    Thanks

  2. vancem says:

    PerfView does have a V4.0 dependency because of its GUI which is WPF based.    IF you just need collection capabilities you can do that with WPA or XPerf and then view the file on another machine.  

  3. Jace says:

    Thanks. Will XPerf collect CPU Stacks like Perfview can? I'm trying to find code hotspots in w3wp.exe hosted code, Perview works wonderfully if I have .NET 4.0, but there are occasions where I cannot install .NET 4.0.

  4. vancem says:

    You should collect using WPR instead of XPERF (see my blog on this) it will collect CPU samples by default and PerfView can read these.

  5. Cameron Taggart says:

    Any chance you could post the TraceParserGen tool too? Or if it still isn't ready for general consumption, I'd be happy to receive it at cameron.taggart@gmail.com. I want to create write and read a custom event type. What is the easiest way to do that? EventSource.WriteEventCore + whatever TraceParserGen creates?

  6. Vance Morrison says:

    You can get a copy of the current TraceParserGen from my Skydrive  http://sdrv.ms/1cOyOZV.   Run it on a manifest and it generates a .CS file that parses the events that you can use with the TraceEvent library.   I should have a better version that I will publish more officially by the end of the year.  

    When you write events, simply use EventSource normally (typically calling 'WriteEvent'.     Note that you don't need a parser from TraceParserGen just to decode the events dynamically (see the blogs.msdn.com/…/TraceEventProgrammersGuide.docx for more).

  7. Peter Cabus says:

    Hi Vance,

    Is the TraceParserGen tool on your skydrive still the latest version?

  8. Peter Cabus says:

    Error from TraceParserGen when extracting from "Microsoft.Windows.ApplicationServer.Applications" (WCF)

    I tried the following:

    TraceParserGen.exe c:WindowsMicrosoft.NETFramework64v4.0.30319Microsoft.Windows.ApplicationServer.Applications.45.man

    I got error the following error:Error c:WindowsMicrosoft.NETFramework64v4.0.30319Microsoft.Windows.ApplicationServer.Applications.45.man(785): Undefined Id Allocate

    I also tried several other approaches like TraceParserGen /EventSource Microsoft.Windows.ApplicationServer.Applications.dll

    But that resulted in "Error: Required positional parameter ManifestFile not present"

    Any help much appreciated.  

  9. Eric Johnson says:

    Is the TraceParserGen source code available anywhere? I'd like to decorate the generated types with DataContract and DataMember attributes automatically.

  10. vancem says:

    There is a copy of TraceParserGen (binary and complete source code) on my OneDrive at  http://1drv.ms/1BGLMDT.   Note that that code is as is.    

  11. Eric Johnson says:

    Thank you–I failed to noticed what was right in front of me.

  12. Mihail Romanov says:

    Hello, Vance!

    Thank for TraceParserGen!!!

    Do you plan to publish TraceParserGen on some Source Code hosting? And provide it with TraceEvent Library (for example in nuget package)?

  13. My goal (assuming other priorities don't interfere), is to publish TraceEvent on GitHub before the end of summer along with PerfView.   TraceParserGen is a lower priority, but it should be easy, so I will add that to the list as well.

  14. Mihail Romanov says:

    Thank you for your answer.

    We explore the possibility of migration logging system to ETW. And one of the main points of such a solution-the ability to consistently analyze not only ours, but also system logs.

    However, the fact that there is no complete "official" tool chain for this task stops us.

  15. @Mihail   It is not clear what 'system logs' you are talking about.   What would a 'official tool chain' look like for you?    If it is just a mater of being able to decode existing ETW events, then I would say that your destiny CAN be in your hands (there is enough support out there).  If you need more information than current ETW events let you get at, then that is harder (at the least you need an updated OS, which is typically problematic in the short term).

  16. Dina Goldshtein says:

    TraceParserGen sounds really great!! I tried to use to it to create a parser for Microsoft-Windows-Winlogon but got an error:

    "Reading manifest file C:tempMicrosoft-Windows-Winlogon.manifest.xml

    Error: Error C:tempMicrosoft-Windows-Winlogon.manifest.xml(137): Undefined Id NotificationPended"

    Is there possible a more updated version you can share?

    P.S. I created the manifest using

    "PerfView /nogui userCommand DumpRegisteredManifest Microsoft-Windows-Winlogon"

  17. The code on http://1drv.ms/1NHA1HB is the most recent.   Not also that the source code for the TraceParserGen utility is also on that share.  It is really not a complex program, as it reads in XML and spits out C# code that mimics it.  

    However typically if you have problems with a particular manifest, you can fix it simply by 'fixing' the XML input (often you don't care about the offending event so you can simply delete it).  

    Indeed the reason why TraceParserGen has this kudgy support (a spot on my one-drive), is because there are a lot of 'bad' manifests out there that are not regular enough to 'just work'.  

    Finally I note that you also have the option of using the DynamicTraceEventParser (which now handles all registered providers as well).   Of course you don't get compile time support that way, and it is less efficient, but that may not matter for your scenario.