Back in 2012, we posted an explanation of why this occurs and provided some manual steps on how you can generate PDB files for these images in order to be able to resolve symbols for them.

We recognized at the time that this wasn't an ideal solution and began working on improving this experience. That's why in Visual Studio 2013, when using the CPU Sampling tool from the Performance and Diagnostics hub (or the new CPU Usage tool that was released in VS 2013 Update 2), we automatically generate these PDBs after your profiling session.

PDBs generated this way contain function names and some other basic information about the symbols in the corresponding images, but don't contain detailed information such as source line numbers for functions. This is because we perform the PDB generation using only the native images themselves as input rather than requiring additional information like the original PDBs that were created with the .NET assemblies (which may not be available). Thus, you won't be able to use the navigate-to-source functionality for functions in your profiling reports which come from NGEN'd modules. If this is important to you, the solution is to continue generating PDBs manually for NGEN'd images using the instructions mentioned in the blog post (be sure to follow the steps under the "If you do need to get back to source" section).

If you're not on VS 2013 or above, or are not using either the CPU Sampling or CPU Usage tool in the Performance and Diagnostics hub, you won't be able to benefit from automatic NGEN PDB generation. Profiling sessions started via the Performance Wizard or Performance Explorer will continue to require manual PDB generation for NGEN'd images, if desired. Here's a tip, though: John Robbins has a PowerShell script that will enumerate the GAC and generate PDBs for all the .NET Framework NGEN'd binaries (or all NGEN'd binaries if desired). Find out more by reading John's blog post about it.

This behavior is the result of changes that occurred in Windows 8.1 to the underlying system in Windows that the profiler uses to identify binaries during a profiling session. Because of this, in versions of Visual Studio before 2012 Update 4, the profiler is unable to store information in reports that makes it possible to determine where the matching symbol information (PDB) is for each binary, and whether any given PDB matches a binary that was present at collection time. Visual Studio 2012 Update 4 (and any newer version of Visual Studio) includes modifications to the profiler which make it compatible with the changes in Windows 8.1. Once you update Visual Studio, the profiler will once again be able to locate and read PDB files to resolve symbols in your profiling data.

Posting on behalf of Aditya Mandaleeka

You may have noticed that the last entry on this blog was posted in 2012. We just wanted to let you know that we haven't stopped working hard to bring you performance and diagnostics capabilities in Visual Studio or blogging about them. We’ve just been blogging in a new location; you can find our most recent posts on the diagnostic tools channel on the Visual Studio ALM blog.

If you haven’t been following the ALM blog so far, here are a few of the Profiler team’s posts you may have missed:

• Diagnosing Mobile Website Issues on Windows Phone 8.1 with Visual Studio (April 2014)
• Performance Profiling on Windows Phone 8.1 with Visual Studio (April 2014)
• Diagnosing memory issues with the new Memory Usage Tool in Visual Studio (April 2014)
• New CPU Usage tool in the Performance and Diagnostics hub in Visual Studio 2013 (February 2014)
• Combining Tools in the Performance and Diagnostics Hub in Visual Studio 2013 (February 2014)
• Performance and Diagnostics Hub in Visual Studio 2013 (July 2013)
• How to profile a XAML Windows Store App (February 2013)
• Creating NGEN PDBs for Profiling Reports (December 2012)

You can also follow us on Twitter (@VSProfiler) for the latest news and updates from the team.

Note: The changes discussed in this post are only applicable when running Visual Studio on Windows 8, there are no changes to functionality on Windows 7.

Background

In order to understand why profiling functionality is different on Windows 8, I need to start with a brief overview of the profiler’s implementation. Once you understand how the profiler was implemented in Visual Studio 2010, the behavior differences on Windows 8 should make more sense.

All versions of Visual Studio through 2010 rely on a kernel mode driver to collect data. The driver was originally developed for CPU sampling so it can register for a callback based on CPU clock cycles (the default is 10 million cycles) in order to sample at a regular interval. Data collection for .NET Memory Allocation, and Concurrency profiling were then also integrated into the driver. Instrumentation profiling is a bit different because it does not rely on the driver for the instrumentation data, but it does use the driver to calculate application time (you’ll see why this is relevant below).

The changes

The profiling driver was registering for the callback in a way that interfered with a Windows kernel operation; and Windows 8 added a security feature that detects when non-operating system code modifies kernel memory (the callback was registered by changing kernel memory). When this condition is detected, Windows does a bug check that results in a blue screen since the operating system can no longer trust the integrity of the kernel. However the supported way to register for the CPU cycle callback does not allow the callback handler to inspect information about user processes due to security concerns.

Since the driver was now at odds with the enhanced security model we needed to move away from the driver to the new capabilities of Windows added since the driver was first created for Visual Studio 2005.

Impact on Visual Studio 2010 and prior versions

Unfortunately, given the need to rewrite the collection and analysis components we were not able to release an update to Visual Studio 2010 to fix the issue. Since customers don’t want to blue screen their operating system, Windows 8 added logic to prevent all incompatible versions of the profiling driver from starting (2010, 2008, and 2005).

This means that when you try to start profiling with an incompatible version you will receive the message “Error VSP1398: The monitor was unable to start the VS performance driver. Access is denied. Consider using the /Admin:Driver,Start and /Admin:Security options of VSPerfCmd from an elevated environment.”

Which will result in the following behavior when running Visual Studio 2010 (or earlier) on Windows 8.

• CPU Sampling, .NET Memory Allocation, and Concurrency profiling will fail to start on Windows 8. The only workaround on Windows 8 is to use Visual Studio 2012 Professional or higher, or to profile on Windows 7.
• Instrumentation profiling can be launched, but the application and elapsed times will be exactly the same (this should have little impact on your ability to analyze the report, just note the elapsed time on the title bar of the summary page may not match the length of your profiling trace).

Impact on Visual Studio 2012

In Visual Studio 2012, we had to stop using the now incompatible driver for CPU sampling and instead use ETW (Event Tracing for Windows). However the move to ETW required a complete rewrite of the collection and analysis components for sampling, which unfortunately due to resource constraints meant we did not have time to add all of the existing sampling functionality to the new implementation. This has the following impact when profiling on Windows 8:

• Tier Interaction Profiling (TIP) data cannot be collected in conjunction with CPU sampling data (this continues to work with instrumentation profiling, and on Windows 7).
• The “Sampling” performance session properties cannot be configured, instead you will see the message “These settings are not supported for CPU sampling on this version of Windows” on the property page. It is important to note that CPU sampling works as expected with the default settings, it just does not allow for changing the advanced settings. The workaround to be able to use the advanced settings is to profile on Windows 7.
• Windows performance counters cannot be collected while CPU sampling. The workaround is to use Windows 7 if you need to collect this information while sampling.     
  
• CPU samples for all functions executing inside NGEN’d modules will appear in the report as [NI module name], instead of the actual function name showing due to the way ETW reports the data (to resolve this see my blog post on Creating NGEN PDBs for Profiling Reports).
• vsperfcmd.exe cannot be used to collect CPU sampling data from the command line and will fail with either the error code “VSP1535” or “VSP1336” and the message “To collect sampling data on this version of Windows, use vsperf.exe”). The correct way to collect CPU sampling data from the command line is to use vsperf.exe instead.

Hope this information is useful to some of you and please let me know if you have any questions.

Example Program

Here’s a very simple program I’ll use in this post.

using System;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            Foo();
        }

        private static void Foo()
        {
            double d = 0;
            for (int i = 0; i < 100000000; ++i)
            {
                d += Math.Sqrt(i);
            }
            Console.WriteLine(d);
        }
    }
}

Why ‘Just My Code’?

Typically when profiling you are most interested in optimizing code that you either wrote or you have control over. Sure, sometimes there will be issues in the frameworks that you are using or in other binaries, but even then you often control the calls into those frameworks.  Just My Code or JMC is intended to filter the data that is displayed in profiler reports so that more of the code you control shows up in the reports and the reports are more manageable.

For example, the Call Tree after collecting sampling data for the simple program above, with JMC off, is shown below:

With the default JMC options, this reduces down to:

What is ‘My Code’?

There are two conditions for code being considered ‘My Code’ by the profiler and they are both at the Module level (Module Name column in the screenshots above). In the example above, this means the checks are made against the clr.dll, mscoreee.dll, mscoreei.dll and ConsoleApplication1.exe binaries.

Modules considered ‘My Code’:

1. the copyright string for the module does not contain ‘Microsoft’, OR:
2. the module name is the same as the module name generated by building any project in the currently open Solution in Visual Studio.
   

How do I turn JMC on or off?

You can temporarily toggle JMC on or off on the profiler Summary Page in the Notifications area using ‘Show All Code’ or ‘Hide All Code’ (shown in red below):

The default setting may be configured as discussed in the following section.

How do I configure JMC?

Use Tools –> Options –> Performance Tools –> General and set options in the ‘Just My Code’ section:

The default has JMC on, showing one level of non-user callee functions. In the example above with JMC on, this is why we see the call to COMDouble::Sqrt(dobule) showing up in the call tree.

It is also possible to show one-level of non-user code calling user code, which in the example above would add one level of the non-user code that calls main, as shown below:

Why is ‘Just My Code’ only available for sampling?

When you instrument binaries for profiling, you have already performed some level of JMC. Only binaries that you instrument and first-level calls into other binaries will show up in the instrumentation report, so JMC is not really necessary.

[Colin Thomsen]

While IIS Express support shipped in Visual Studio 2010 SP1, unfortunately profiling code running in IIS Express does not just work out of the box.  The issue is that the profiler does not “know” how to setup and launch the IIS Express process to enable the various profiling methods.  If this is a blocking issue for you, fortunately this can be manually worked around to profile IIS Express.

The instructions for how to do this, vary depending on the method of profiling you would like to use, and the target framework

CPU Sampling:

• If you’re profiling .NET 4.0 after you’ve launched your site in IIS Express, manually attach to the IISExpress.exe process (Analyze -> Profiler -> Attach/Detach…) and you will be collecting CPU sampling data
• · If you’re profiling .NET <= 3.5:
  • From a Visual Studio command prompt, type:
    • vsperfclrenv /sampleon
    • devenv
  • From the instance of Visual Studio that launches, launch your site in IIS Express and manually attach as in the step for profiling .NET 4.0

.NET Memory Profiling (Sampling)

• From a Visual Studio command prompt, type:
  • vsperfclrenv /<memory option you want—see vsperfclrenv documentation for options>
  • devenv
• From the instance of Visual Studio that launches, launch your site in IIS Express and manually attach as in the CPU sampling scenarios

Instrumentation (including .NET memory instrumentation)

• From a Visual Studio command prompt, type:
  • For method timing: vsperfclrenv /traceon
    if you want memory, see vsperfclrenv documentation for options
  • devenv
  • vsinstr <your binaries that will run inside IIS Express>
  • vsperfcmd /start:trace /output:<report name>
• From the instance of Visual Studio that launches, launch your website in IIS Express and run your scenario
• From the command prompt type: vsperfcmd /shutdown
• Close IIS Express
• Open the resulting .vsp file in Visual Studio

Resource Contention Profiling

• Launch your website in IIS Express
• From a Visual Studio Command Prompt:
  • vsperfcmd /start:concurrency,resourceonly /output:<report.vsp>
  • vsperfcmd /attach:<IISExpress.exe’s PID>
  • Run your scenario
  • vsperfcmd /shutdown
  • close IIS Express
• Open the resulting .vsp file in Visual Studio

then you end up with an error like that:

The rationale behind usage of local drives is that VS Profiler attempts to make logging to the file fast, while usage of network drives might introduce logging delays (up to blocking your application execution in some cases).

However, if you absolutely have to use your network drives for that purpose, you can achieve that through usage of Symbolic Links. A symbolic link can be easily created with mklink utility. For example,

mklink /D C:\Foo \\MyNetwork\MyValut

After that you can use C:\Foo as a location for profiling reports. Keep in mind, though, that your network access can be slower than a local drive access, and it can impact your profiling session.

[Maxim Goldin]

To profile both Silverlight and ASP.NET at the same time:

1. Launch your CPU sampling session against your ASP.NET application from Visual Studio
2. In the Performance Explorer window click “Attach/Detach”
   
   
   
3. Select the Internet Explorer process that is running your Silverlight application—if you only have one instance of Internet Explorer open with a single tab, the process will be the “iexplore” process without a Window Title. 
   
   
   
   • If you have multiple instances of Internet Explorer open, or multiple tabs inside internet explorer, you can either:
     • Try looking at the CPU consumption of your iexplore.exe processes in Task Manager to see which one is most active
     • Use Process Explorer
       • Find –>  “Find Handle or DLL…” (ctrl + F)
       • Search for “coreclr.dll”
       • The “iexplore.exe” process with this dll loaded is the PID you want to attach to
         
         
         
4. You are now profiling ASP.NET and Silverlight at the same time

If you install recently published VS2010 SP1 Beta, you can discover that VS Profiler team enriched Silverlight profiling user experience. Previously I published few posts about VS2010 usage for those purposes, either through VS Profiler command line tools or VS2010 UI. Both approaches led you to the final results or figuring out the bottlenecks of your Silverlight application, but they require number of manual steps to be done.

In VS2010 SP1 however Silverlight projects are fully recognized by VS Profiler, and you can conduct your performance investigations much easier.

For example, you might use the Silverlight Text Editor Sample, and open this project in VS2010 SP1:

Now, if you wish to create a performance session for this project, you can do it in a usual way through Performance Wizard:

You will see your project in the list of possible targets (it was not there before the final integration of Silverlight projects and VS Profiler), and you can select it there and proceed with the Wizard that creates and starts a performance session for you:

When you close your application – the session is over and profiling results are presented so you can analyze the data:

Enjoy!

[Maxim Goldin]

> VSPerfASPNetCmd.exe https://localhost
Microsoft (R) VSPerf ASP.NET Command, Version 10.0.0.0
Copyright (C) Microsoft Corporation. All rights reserved.

Error
VSP 7008: ASP.net exception: "The website metabase contains unexpected information or you do not have permission to access the metabase.  You must be a member of the Administrators group on the local computer to access the IIS metabase. Therefore, you cannot create or open a local IIS Web site.  If you have Read, Write, and Modify Permissions for the folder where the files are located, you can create a file system web site that points to the folder in order to proceed."

The information in the error is correct and it is worth checking to make sure that you are running from an elevated command prompt, but it does miss a common configuration issue. In order to query for information from the IIS metabase, certain IIS components need to be installed.

To check this in Windows 7:

1. Open ‘Control Panel\Programs\Programs and Features’ (or run ‘appwiz.cpl’).
2. Choose ‘Turn Windows features on or off’.
3. In the ‘Internet Information Services’ section, make sure that the following options are selected.

The non-default options include:

• IIS 6 Scripting Tools
• IIS 6 WMI Compatibility
• IIS Metabase and IIS 6 configuration compatibility
• ASP.NET,
• Windows Authentication

[Colin Thomsen]