Defrag Tools #116 - PerfView Part 4

Sign in to queue

Description

In this episode of Defrag Tools, Vance Morrison joins Andrew Richards and Chad Beeder to discuss his performance analysis tool, PerfView. In part 4 of this series, we focus on using PerfView as a diagnostics tool.

Resources:
Download PerfView from Microsoft Download Center
PerfView Tutorial on Channel 9

 

Embed

Download

The Discussion

  • User profile image
    mgrzeg

    Wow, 'Provider Browser' is a super-cool feature, thanks!!! Vance, could you add another super feature 'Generate c# EventTrace class' for selected provider (along to the 'View Manifest' button) - something that you've done already in your TraceParserGen tool...

    Another great show! :)

  • User profile image
    tinhkhucvang

    Hello, I come from Vietnam. How you halfway around the world. Hopefully things will be better again. I speak English quite ready yet. Sorry!

  • User profile image
    philippecp

    Great talk overall however I have some questions regarding source code visualization. The concern about PDBs was glossed over in this talk but I'm still not clear how we configure them. I interpret Vance's comments that you don't need any configuration for Microsoft  code since it will automatically get it from the web. What I'm not clear is how do we get source code and relevant debug information for our own code. Do we need to have PDBs side by side with dlls on production server? Can we configure a PDB source path? Assuming we have a TFS source server, how do we configure PerfView to use it in order to retrieve right version of source for version deployed in production environment?

  • User profile image
    Randhir

    @philippecp, for retrieving symbols and sources, standard environment variables _NT_SYMBOL_PATH and _NT_SOURCE_PATH should work fine. If the assemblies were built on a machine with the same source folder structure as the one where you are investigating, then also it should pick up the sources from there.

    As for indexing your binaries to create your own symbol server (at your company-wide accessible location), the Debugging Tools for Windows includes tools for you to achieve it. Look for usage of symstore.exe (indexing) and symsrv.dll (the symbol server). Check this url: https://msdn.microsoft.com/en-us/library/windows/desktop/ms681416(v=vs.85).aspx

  • User profile image
    vlad

    Hope to hear the story from you someday why and how the GUI subsystem uses access violations to communicate with itself :)

  • User profile image
    vlad

    Is there events related to C++ exceptions?

  • User profile image
    Vancem

    @philipecp:  To make PerfView find your own source code you simply need tell PerfView where to find the PDBs and the root of the source code.   You can do this with the _NT_SYMBOL_PATH and _NT_SOURCE_PATH that you may be familiar with, but you can also add these paths using the GUI in the 'set Symbol path' and 'set source path' menu entries in the stack view (PerfView remembers these options from one invocation to the next).   To make it work with the TFS you need to follow the instructions with setting up a source server (out of scope).  

    @vlad: Unfortunately the operating system does not raise any events when the 'RaiseException' or C++ exceptions are raised.    You can however do this yourself in your own code by using ETW APIs, but that is extra work.   

     

  • User profile image
    Josh

    First I'd like to say I admire your enthusiasm and passion that you've imbued into PerfView as well as the same into the presentations you offer on it.

    Second I noticed a AdoNetAndPerfView folder in the structure below your example. I was curious if that may imply there might be an ADO.NET overview somewhere? :)

    Regards,
    Josh

Add Your 2 Cents