Trey Nash

Trey Nash treynash

Niner since 2014

Trey Nash has been developing software on the Windows platform for 20 years. Prior to coming to Microsoft, he was a Principal SDE at Macromedia/Adobe among other companies. Currently, he is a Platforms Escalation Engineer. Trey is the author of several articles including columns for DevProConnections as well as the author for the "Accelerated C# 20xx" titles published by Apress. In his spare time (what spare time?!?), he enjoys time with this family and plays ice hockey and piano



  • Defrag Tools #118 - PerfView Part 6


    This sounds like a job for WPA included in the Windows Performance Toolkit.  If you want to sort/pivot by process name/PID/thread, etc., then you need to make sure the information is in your trace to begin with.  You could add arguments to your events but that can be tedious and inefficient.  It would be easier to couple your events with events generated by the kernel provider.

    If you do so and you use WPA to view your events, you can drag the Generic Events graph into an analysis tab and use the tables to pivot things around nicely.  That way, you will get the fidelity you are after whereby you can filter by process name, PID, threadID, etc.

    You can even use the tables to pivot on arguments to your custom ETW events created by your EventSource derivatives.

    Vance wrote a related blog post here:

    These tools do have a learning curve, but once you get the hang of them, their power is virtually boundless.

    For example, if you know the GUID of your provider, you could start the trace as follows:
    xperf -on PROC_THREAD+LOADER -start MySession -on EF456B24-2DD3-4E9B-B619-18F96123EBC7:0xffffffffffffffff:0xff

    You would then stop the trace as follows:
    xperf -stop MySession -stop -d mytrace.etl

    You would then load mytrace.etl into WPA.exe and go to town.  The xperf command to start the trace starts two providers.  Yours and the kernel provider.  For the kernel provider, it is only asking for loader events (for symbols - if needed) and proc/thread events (so you can determine which thread was active when your event fired).  Be careful with those kernel flags!  If you enable too many, you'll create a fire hose of data.  The stop xperf command above stops both providers and merges the results into one ETL file.  There are many more options for xperf which allow you to control buffering, etc.

    Finally, if your start command looked like the following (note the 'stack' addition):
    xperf -on PROC_THREAD+LOADER -start MySession -on EF456B24-2DD3-4E9B-B619-18F96123EBC7:0xffffffffffffffff:0xff:'stack'

    Then you would also be able to see the call stacks at the point of your event firing. This is when PROC_THREAD information becomes essential.

    As a final point, if you have two ETL traces from two different providers captured at the same time, you can merge them into one ETL file using xperf -merge.