Common Profiling Issues

Profiling is a complex topic, and not without a few pitfalls to catch the unwary. This section documents a number of common issues you might encounter as you profile your applications.

Debugging symbols

When you review your profiling reports, you may notice that some function calls resolve to unhelpful entries such as [ntdll.dll]. This occurs because the application has used code for which it cannot find debugging symbols, so instead of the function name you get the name of the containing binary.

Debugging symbols, files with the .pdb extension (for "program database"), include the details that debuggers and profilers use to discover information about executing code. Microsoft Symbol Server enables you to use a web connection to dynamically obtain symbol files for binaries as needed. Direct Visual Studio to use this server by choosing Tools Options, and then expand the Debugging section and choose Symbols. Create a new symbol file location, entering the value http://www.msdl.microsoft.com/download/symbols. Because symbols are downloaded, you will also need to choose a local directory to serve as a storage area. Now close and reopen a report; the new symbols will be used to resolve function names.

Note

The first time you render a report with symbols set to download from Microsoft Symbol Server, it will take significantly longer to complete.

If, perhaps due to security restrictions, your profiling system does not have Internet access, you can download and install the symbol packages for Windows from the Windows Hardware Developer Center. At the time of writing, this is http://www.microsoft.com/whdc/devtools/debugging/symbols.mspx. Select the package appropriate for your processor and operating system, and install the symbols.

Instrumentation and code coverage

When running an instrumentation profile, be certain that you are not profiling a target for which you have previously enabled code coverage. Code coverage, described in Chapter 14, uses another form of instrumentation that observes which lines of code are accessed as tests are executed. Unfortunately, this instrumentation can interfere with the instrumentation required by the profiler.

If your solution has a test project and you have previously used code coverage, open your Test Run Configuration, under Test Edit Test Run Configurations, and select the Code Coverage page. Ensure that the binaries you are profiling do not have code coverage enabled. If they do, uncheck them and rebuild your solution. You should then be able to use instrumentation profiling without conflict.

Virtual machines

If you are running your application from within a virtual machine, such as with Virtual PC, VMWare, or Virtual Server, you will not be able to profile that application. Profiling relies upon a number of performance counters that are very close to the system hardware. Some of these counters are unavailable through a virtual instance of an operating system.

ASP.NET profiling

Team System does support the profiling of ASP.NET applications, but they must be based on ASP.NET version 2.0. Version 1.x ASP.NET applications cannot be profiled.

In addition, the ASP.NET application being profiled must be hosted on the same machine that is executing the profiling session. Profiling of remote ASP.NET applications is not supported in this release. Remember that you can also use the command-line tools to execute performance sessions. For an introduction to the command-line tools, see the "Command-line Execution" section earlier in this chapter.