I had the chance to watch a first time profiler user go through a profiling scenario this morning.  We got everything humming but there was a learning curve and some less than helpful error messages along the way.   Here are the takeaways:

  • Permissions: Realize that non-admin limited user accounts need to be given permission to use the profiler.  Otherwise you might be all excited to use the profiler only to get slapped in the face with an access denied trying to access the driver.  Follow these instructions from the MSDN docs.
  • ASP.NET: For ASP.NET projects, consider starting with instrumentation.  Skip to the subheading What Profiling Mode Do I Need?  Sampling or Instrumentation? in this GrayCode blog post.  See also my  Beta 2 Whidbey ASP.NET Profiler HOWTO.  
  • Configuration: Invest the extra 30 minutes to get familiar with all the knobs and dials.  Learn how to configure a profiling session to serialize symbols, get .NET memory allocation information, .NET object lifetime profiling -- Ian's blog has great information on this with screenshots.  If you need Windows Symbols Packages or other symbols set them up in the debugger symbol settings (Tools->Options->Debugging->Symbols) so the profiler can find them. 
  • Unit Tests: If you use a unit test for profiling by right clicking on the unit test result and selecting the Create Performance Session option, make sure the unit test isn't also simultaneously set to collect code coverage information.  Code coverage and profiling are mutually exclusive modes of the same engine, so trying to do both from the same unit test won't work. 
  • View Source: The accuracy and availability of View Source option in function view can sometimes be linked to the characteristics of the code you are profiling and the collection mode you are using.  For example, we had a case with some ASP.NET code where in function view the user could right click on a function name and use View Source perfectly from instrumentation mode, but sampling mode didn't retrieve any line number information in this case because of the really high sampling interval and the point where the sampling occurred.
  • No Data?! If you get an error saying no data was collected, check to make sure that the code you want to profile appears under the "targets" section of the performance session.  Right click on the targets node to add new target projects and binaries.  In particular, creating a performance session from a unit test may require you to add additional targets like the ASP.NET project based on what you are attempting to profile.