Advanced instrumenting with the VSTS profiler 101: /start

          When you are working with the Visual Studio profiler in instrumentation mode you often want to be able to limit the amount of data that you are seeing. I posted an earlier TechNote (from an Angry Richard blog article) that described (in 40,000 foot terms) some of the various functions in the Microsoft.VisualStudio.Profiler namespace that you can use to limit data captured during instrumentation profiling. This blog series on advanced instrumentation will look at some of the more interesting ways to use the instrumentation API (in MS.VS.profiler) and the command line instrumentation options to help prune your trace data.


            As I’ve shown in my earlier TechNote, it can be very easy to trim your analysis to just a specific function by using the Microsoft.VisualStudio.Profiler.DataCollection classes. But what if I’ve already built my binary and I don’t want to have to re-compile it? Luckily we have command line instrumentation options for just this type of scenario. To just instrument the function A(), we’ll use the /start option for the VSInstr tool. The /start option will allow us to instrument a specific function with a start / stop profiling pair at its entry and exit points. But before we can use /start we need to find the name of the function that we are interested in. To see the function names in an assembly in a format that VSInstr accepts just use the /dumpfuncs command on vsinstr.


>VSInstr /dumpfuncs ConsoleApplication1.exe

Microsoft (R) VSInstr Post-Link Instrumentation 8.0.60117 x86 (Debug)

Copyright (C) Microsoft Corp. All rights reserved.

Functions contained in C:\Test\ManInstr\ConsoleApplication1.exe:

NOTE: No instrumentation will be performed







      For this example I wanted to just instrument the function FirstFunction. This function calls SeeMe a bunch of times, while Main and SecondFunction both call DontSeeMe. So in our results we will know if we are getting correct information if we only see FirstFunction and calls to SeeMe. Also, I need to specify the control level of the start profiling and stop profiling commands that I will be instrumenting into the code. Since I’m running this application all by itself I’m setting them up to be global commands with the /control option. Now we will actually instrument ConsoleApplication1 with the /start option (if you are wondering, the output path command switch that I used just places the instrumented binary in a separate folder):


>VSInstr /outputpath:C:\Test\ManInstr\instr /control:global /start:inside,ConsoleApplication1.Program::FirstFunction ConsoleApplication1.exe

      Now we need to start up our monitor and actually run our profiling scenario on the instrumented ConsoleApplication1.exe. Also, after we start up the monitor we will disable global profiling. This is because we automatically start up profiling when we start profiling so we would be collecting data from the beginning of the run up until the start / stop profiling pair instrumented into FirstFunction. Since we don’t want to collect all the information up until FirstFunction is called, we need to shut off profiling globally before we run our scenario.


>VSPerfClrEnv /traceon //enable trace profiling of managed apps

>VSPerfCmd /start:trace /output:FirstOnly.vsp
>VSPerfCmd /globaloff
>VSPerfCmd /shutdown

      You now have a vsp file that you can open up in the IDE for analysis or analyze using the VSPerfReport command line tool. And this vsp only contains trace data captured inside FirstFunction or one of its subfunctions. Next entry I’ll take a look at using advanced instrumentation options to skip the first 20 times a function is executed in analysis.