Run analysis tools from the Performance and Diagnostic page

You can analyze the performance, memory use, and energy consumption of Windows Store and Windows Phone apps by using the Visual Studio profilers and diagnostic tools. The Performance and Diagnostic hub makes it easy to select and run these tools, combine multiple tools in a single diagnostic run, and manage the reports they produce. You can run the tools on most deployment targets. For Windows Phone apps, use a phone or an emulator. For Windows Store apps, use the Visual Studio computer, the simulator, or a remote PC. After you have collected the data, the diagnostic report displays timeline graphs and detail views of the data. Performance and Diagnostic report filters and settings help you to focus on the critical parts of the data.

Tools in the Performance and Diagnostic hub

The Performance and Diagnostic hub shows you the tools that you can use on particular types of apps (XAML and C#/VB/C++ or HTML and JavaScript) and the tools that you can use in a single diagnostic run.

In this article

• Quick start: Collect diagnostic data

• Collect diagnostic data

  Add user marks to identify locations in your diagnostic data | Set the startup project | Set the analysis target | Choose the tools to run in the diagnostic session | Start and stop the diagnostic session

• Open a diagnostic session file

• The Performance and Diagnostic data page

• Troubleshooting

Quick start: Collect diagnostic data

1. Open the project in Visual Studio.

2. Set the deployment location.

   	Windows Phone apps can be deployed to a phone or one of the Visual Studio emulators.
   	Windows Store apps can be deployed to the Visual Studio computer, the Visual Studio simulator, or on a network-connected PC or tablet. Note: Running a diagnostic session on a remote PC or tablet requires that the Visual Studio Remote Tools be installed and running on the remote target. See Run Windows Store apps on a remote machine from Visual Studio.

   From the debug location list on the debugger toolbar, select the deployment location for your app. Here's the list for phone apps:

   

3. Open a Performance and Diagnostic session. On the Debug menu, choose Performance and Diagnosis (Shortcut key: Alt + F2).

4. In the Performance and Diagnostic hub, choose one or more tools to run in the session. Only the tools that are applicable to the project type and programming language are displayed. When you choose a diagnostic tool, the selections for tools that cannot be run in the same diagnostic session are disabled. Here's how your choices might look for a JavaScript app:

   

5. To start the diagnosis session, choose Start.

6. Run the scenarios that you want to collect data for.

   While you are running the session, some tools display graphs of real-time data on the Performance and Diagnosis page.

   

7. To end the diagnostic session, choose Stop collection.

Collect diagnostic data

Add user marks to identify locations in your diagnostic data | Set the startup project | Set the analysis target | Choose the tools to run in the diagnostic session | Start and stop the diagnostic session

Add user marks to identify locations in your diagnostic data

You can add user marks to your profiling data to help identify areas in the timeline ruler.

The mark appears as an orange triangle in the timeline at the time the method executed. The message and the time are displayed as a tooltip when you hover over the mark. If two or more user marks are close together, the marks are merged and the tooltip data is combined. You can zoom in on the timeline to separate the marks.

Add marks to C#, Visual Basic, C++ code

To add a user mark to C#, Visual Basic, C++ code, first create a Windows.Foundation.Diagnostics LoggingChannel object. Then insert calls to LoggingChannel.LogMessage methods at the points in your code that you want to mark. Use LoggingLevel.Information in the calls.

When the method executes, a user mark is added to the profiling data along with a message.

Notes

Adding logging channels to your code poses a couple of challenges:

Each open logging channel must have a unique name. Attempting to create a new logging channel with the same name as an open channel causes an exception.

One way to avoid duplicate names in your code is to use a static (Shared in VB) method to return a LoggingChannel with a name that is guaranteed to be unique. Here's an example that uses a Guid to provide uniqueness:

//using Windows.Foundation.Diagnostics
public static LoggingChannel GetLoggingChannel()
{
    var name = Guid.NewGuid().ToString();
    return new LoggingChannel(name);
}

'Imports Windows.Foundation.Diagnostics
Public Shared Function GetLoggingChannel() As LoggingChannel
    Dim Name = Guid.NewGuid().ToString()
    GetLoggingChannel = New LoggingChannel(Name)
End Function

//using namespace Windows::Foundation::Diagnostics;
static LoggingChannel^ MainPage::GetLoggingChannel()
{
    auto name = (ref new Guid())->ToString();
    auto channel = ref new LoggingChannel(name);
    return channel;
}

C# and VB: LoggingChannel objects should be disposed

Because LoggingChannel objects use system resources, the C# and VB projections of LoggingChannel derive from the System.IDisposable interface to enable you to release the resources before the object is destroyed by the CLR garbage collector. In C++ code, the LoggingChannel object is destroyed and resources are released as soon as the object goes out of scope. Here are examples of patterns that you can use to add user marks to a diagnostics session file:

void MyScenario()
{
    var logLevel = LoggingLevel.Information;
    using(var channel = Utils.GetLoggingChannel())
    {
        channel.LogMessage("MyScenario Start", logLevel);
        // scenario code
        channel.LogMessage("MyScenario End", logLevel);
    }
}

Sub MyScenario()
    Dim logLevel = LoggingLevel.Information
    Using channel As LoggingChannel = Utils.GetLoggingChannel()
        channel.LogMessage("MyScenario Start", logLevel)
        'scenario code
        channel.LogMessage("MyScenario End", logLevel)
    End Using
End Sub

// m_channel resources are released when containing 
// object goes out of scope
LoggingChannel^ m_channel = MainPage::GetLoggingChannel();
LoggingLevel m_logLevel = LoggingLevel::Information;

void MyScenario()
{
    m_channel->LogMessage(L"MyScenario Start", m_logLevel);
    //scenario code
    m_channel->LogMessage(L"MyScenario Start", m_logLevel);
}

Add marks to JavaScript code

To add user marks add the following code at the points in your code that you want to mark:

if (performance && performance.mark) {
    performance.mark(markDescription);
}

markDescription is a string that contains the message to display in the user mark tooltip.

Set the startup project

If your solution contains multiple app projects, make sure the one that you want to analyze is set as the startup project. In Solution Explorer, select the project and choose Set as Startup Project from the context menu.

Set the deployment location

You can run diagnostic sessions for phone apps on a Windows phone that is directly connected to the Visual Studio computer or in a Visual Studio phone emulator. You can run Windows Store apps on the Visual Studio computer, in the Visual Studio device simulator, or on a remote device that is connected to Visual Studio over a network or that is connected directly to the Visual Studio computer with an Ethernet to USB cable. You can set the deployment target on the Debug page of the project properties, or you can choose the target from the debug location list on the Visual Studio toolbar. Here's the deployment list for Windows Store apps:

The choice that you make on the debug location toolbar is saved to the project properties.

Set the analysis target

Besides starting your app from the Visual Studio project, you can also run diagnostic sessions on alternative targets. For example, you might want to diagnose performance issues on a version of your app that was installed from the Windows App Store.

Choose the tools to run in the diagnostic session

On the Performance and Diagnosis hub, choose one or more tools to run in the diagnostic session. Only the tools that are applicable to the project type and programming are displayed. When you choose a diagnostic tool, the selections for tools that cannot be run in the same diagnostic session are disabled. Here's how your choices might look for a JavaScript app:

Start and stop the diagnostic session

To start the diagnosis session, choose Start.

To end the diagnostic session and begin the data analysis, choose Stop collection at the bottom of the page.

Open a diagnostic session file

When you stop collecting data in a diagnostic session, the data is immediately analyzed and then displayed in the Performance and Diagnostic report.

You can also open saved .diagnosis session files from the recently opened list on the Performance and Diagnostic hub.

Choose the show or hide button at the top of the Performance and Diagnostic hub to expand or collapse the recently used file list.

The Performance and Diagnostic report

Troubleshooting

Diagnostic events dropped. Some information in the report may be missing or inaccurate

The data collector in performance and diagnostic tools can be memory and CPU intensive. When the data collector is unable to log all of the diagnostic events it displays the message in an information bar at the top of the Performance and diagnostic page. Some data in the report might be missing or invalid.

To resolve this issue, try these steps to free up resources on the machine and then rerun the diagnostic session:

1. Close other apps that are not part of the diagnostic session.

2. Simplify your scenario so that you are collecting less data.

3. Use fewer diagnostic tools in a single session.

See Also

Other Resources

Performance (Windows Store apps)

Windows SDK LoggingSession Sample