diff --git a/docs/_breadcrumb/toc.yml b/docs/_breadcrumb/toc.yml
index e67b18e3cd3..f09cb6e219f 100644
--- a/docs/_breadcrumb/toc.yml
+++ b/docs/_breadcrumb/toc.yml
@@ -53,14 +53,14 @@
topicHref: /visualstudio/modeling/analyze-and-model-your-architecture
- name: Debugging
tocHref: /visualstudio/debugger/
- topicHref: /visualstudio/debugger/debugging-in-visual-studio
+ topicHref: /visualstudio/debugger/index
items:
- name: DIA SDK
tocHref: /visualstudio/debugger/debug-interface-access/
topicHref: /visualstudio/debugger/debug-interface-access/debug-interface-access-sdk
- name: Profiling
tocHref: /visualstudio/profiling/
- topicHref: /visualstudio/profiling/profiling-tools
+ topicHref: /visualstudio/profiling/index
- name: Testing
tocHref: /visualstudio/test/
topicHref: /visualstudio/test/improve-code-quality
diff --git a/docs/debugger/debugger-feature-tour.md b/docs/debugger/debugger-feature-tour.md
index f01884d4868..17a05ac5a98 100644
--- a/docs/debugger/debugger-feature-tour.md
+++ b/docs/debugger/debugger-feature-tour.md
@@ -33,255 +33,201 @@ translation.priority.mt:
---
# Debugger feature tour
-This topic introduces the features of the Visual Studio debugger in an easy-to-follow walkthrough.
+This topic introduces the features of the Visual Studio debugger. If you want to follow along by opening your own app in Visual Studio, you can do that, or you can follow along with a sample app using the [step-by-step Beginner's Guide](../debugger/getting-started-with-the-debugger.md).
-You can either read along to see the features of the debugger or you can download the complete sample used in the feature tour and follow the step-by-step instructions yourself. To download the sample and follow along, go to [Photo Viewer Demo](https://code.msdn.microsoft.com/windowsdesktop/WPF-Photo-Viewer-Demo-be75662a).
+The features described here are applicable to C#, C++, Visual Basic, JavaScript, and other languages supported by Visual Studio (except where noted).
-Although the demo app is C#, the features are applicable to C++, Visual Basic, JavaScript, and other languages supported by Visual Studio (except where noted).
+## Set a breakpoint and start the debugger
-## Start the tour!
+To debug, you need to start your app with the debugger attached to the app process. F5 (**Debug / Start Debugging**) is the most common way to do that, but right now you may not have set any breakpoints to examine your app code, so we'll do that first and then start debugging.
-1. To follow along these steps in Visual Studio, download the sample [on this page](https://code.msdn.microsoft.com/windowsdesktop/WPF-Photo-Viewer-Demo-be75662a).
+With a project open in Solution Explorer and a file open in the code editor, set a breakpoint by clicking in the margin to the left of a line of code.
- > [!IMPORTANT]
- > You need to install Visual Studio with the .NET Desktop Development workload to run the app we're using in the demo.
+
-2. Unzip the project.
+Press F5 (**Debug / Start Debugging**) and the debugger runs to the first breakpoint that it encounters. If the app is not yet running, F5 starts the debugger and stops at the first breakpoint.
-3. Open Visual Studio and select the **File / Open** menu command, then choose **Project/Solution**, and then open the folder where you downloaded the project.
+Breakpoints are a really useful feature when you know the line of code or the section of code that you want to examine in detail.
- 
+## Navigate code in the debugger using step commands
-3. Open the WPF Photo Viewer Demo / C# folder, choose the photoapp.sln file, and select **Open**.
+We are showing the keyboard shortcuts for most commands because they make navigation of your app code quicker (equivalent commands such as menu commands are shown in parentheses).
- The project opens in Visual Studio. Solution Explorer in the right pane shows you all the project files.
+Press F11 (**Debug / Step Into**) to start your app with the debugger attached. F11 is the **Step Into** command and advances the app execution one statement at a time. When you start the app with F11, the debugger breaks on the first statement that gets executed.
- 
+
-4. Press F5 (**Debug / Start Debugging** or the **Start Debugging** button  in the Debug Toolbar).
+The yellow arrow represents the statement on which the debugger paused, which also suspends app execution at the same point (this statement has not yet executed).
- 
+F11 is a good way to examine the execution flow in the most detail. (To move faster through code, we will show you some other options as well.) By default, the debugger skips over non-user code (if you want more details, see [Just My Code](../debugger/just-my-code.md)).
- F5 starts the app with the debugger attached to the app process, but right now we haven't added any breakpoints or done anything special to examine the code. So the app just loads and you see the photo images.
+>[!NOTE]
+> In managed code, you will see a dialog box asking if you want to be notified when you automatically step over properties and operators (default behavior). If you want to change the setting later, disable **Step over properties and operators** setting in the **Tools / Options** menu under **Debugging**.
- In this tour, we'll take a closer look at this app using the debugger and get a look at the debugger features.
+## Step over code to skip functions
-5. Stop the debugger by pressing the red stop  button.
+When you are on a line of code that is a function or method call, you can press F10 (**Debug / Step Over**) instead of F11.
-## Start the debugger by stepping through code
+F10 advances the debugger without stepping into functions or methods in your app code (the code still executes). By pressing F10, you can skip over code that you're not interested in, so you can quickly get to code that you are more interested in.
-To debug, you need to start your app with the debugger attached to the app process.
-
-Mostly, we will use the keyboard shortcuts here, because it's the best way to get fast at executing your app in the debugger (equivalent commands such as menu commands are shown in parentheses).
-
-1. Press F11 (**Debug / Step Into**) to start the app with the debugger attached.
-
- 
-
- The yellow arrow represents the statement on which the debugger paused, which also suspends app execution at the same point (this statement has not yet executed).
-
- F11 is the **Step Into** command and advances the app execution one statement at a time. F11 is a good way to examine the execution flow in the most detail. (To move faster through code, we will show you some other options in later steps.) By default, the debugger skips over non-user code (if you want more details, see [Just My Code](../debugger/just-my-code.md)).
-
- >[!NOTE]
- > In managed code, you will see a dialog box asking if you want to be notified when you automatically step over properties and operators (default behavior). If you want to change the setting later, disable **Step over properties and operators** setting in the **Tools / Options** menu under **Debugging**.
-
-2. Press F10 (**Debug / Step Over**) a few times until the debugger stops on the first line of code in the **OnApplicationStartup** event handler.
-
- 
-
- F10 advances the debugger without stepping into functions or methods in your app code (the code still executes). By pressing F10 on the InitializeComponent method call (instead of F11), we skipped over the implementation code for InitializeComponent (which maybe we're not interested in right now).
-
-## Set a breakpoint
+## Step into a property
-1. Now, in the **OnApplicationStartup** event handler, set a breakpoint by clicking in the margin to the left of the last line of code.
+As mentioned earlier, by default the debugger skips over managed properties and fields, but the **Step Into Specific** command allows you to override this behavior.
- 
+Right-click on a property or field and choose **Step Into Specific**, then choose one of the available options.
-6. Press F5 (**Continue**) and the debugger runs to the line of code where you set the breakpoint.
+
- F5 either continues running the app to the next breakpoint or, if the app is not yet running, it starts the debugger and stops at the first breakpoint.
+In this example, **Step Into Specific** gets us to the code for `Path.set`.
- Breakpoints are a really useful feature when you know the line of code or the section of code that you want to examine in detail.
+
-## Restart your app quickly
+## Run to a point in your code quickly using the mouse
-1. Click the **Restart**  button in the Debug Toolbar (Ctrl + Shift +F5).
+While in the debugger, hover over a line of code until the **Run execution to here** button  appears on the left.
- When you press **Restart**, it saves time versus stopping the app and restarting the debugger. The debugger pauses at the first breakpoint that is hit by executing code, similar to pressing F5 (if the code isn't executed, you won't hit the breakpoint).
+
-## Step into a property
+> [!NOTE]
+> The **Run execution to here** button is new in [!include[vs_dev15](../misc/includes/vs_dev15_md.md)].
-1. With the debugger paused on this line of code:
+Click the **Run execution to here** button. The debugger advances to the line of code where you clicked.
- ````
- mainWindow.Photos.Path = Environment.CurrentDirectory + "\\images";
- ````
+Using this button is similar to setting a temporary breakpoint, which is also handy for getting around quickly within a visible region of app code (you can click in any open file).
- Right-click on the line of code and choose **Step Into Specific**, then **SDKSamples.ImageSample.PhotoCollection.Path.set**
+## Advance the debugger out of the current function
- 
+Sometime, you might want to continue your debugging session but advance the debugger all the way through the current function.
- As mentioned earlier, by default the debugger skips over managed properties and fields, but the **Step Into Specific** command allows you to override this behavior. For now, we want to look what happens when the `Path.set` property setter runs. **Step Into Specific** gets us to the `Path.set` code here.
+Press Shift + F11 (or **Debug / Step Out**).
- 
+This resumes app execution (and advances the debugger) until the current function returns.
- The `Update` method in this code looks like it could be interesting, so lets use the debugger to examine that code up close.
+## Run to cursor
-5. Hover over the `Update` method until the green **Run execution to here** button appears on the left.
+Stop the debugger by pressing the **Stop Debugging** red button  or Shift + F5.
- 
+Right-click a line of code in your app and choose **Run to Cursor**. This command starts debugging and sets a temporary breakpoint on the current line of code.
- > [!NOTE]
- > The **Run execution to here** button is new in [!include[vs_dev15](../misc/includes/vs_dev15_md.md)]. If you don't see the green arrow button, use F11 instead to advance the debugger.
+
-6. Click the green arrow  button.
+If you have set breakpoints, the debugger will pause on the first breakpoint that it hits.
- Using the green arrow button is similar to setting a temporary breakpoint, which is also handy for getting around quickly within a visible region of app code (you can click in any open file).
+Press F5 until you reach the line of code where you selected **Run to Cursor**.
- The debugger advances to the `Update` method implementation.
+This command is useful when you are editing code and want to quickly set a temporary breakpoint and start the debugger.
-7. Press F11 to step into the `Update` method.
+## Restart your app quickly
- 
+Click the **Restart**  button in the Debug Toolbar (Ctrl + Shift +F5).
- Here, we find some more code that looks interesting; it appears the app is getting all *.jpg files residing in a particular directory, and then creating a new Photo object for each file. This gives us a good opportunity to start inspecting your app state (variables) with the debugger.
+When you press **Restart**, it saves time versus stopping the app and restarting the debugger. The debugger pauses at the first breakpoint that is hit by executing code, similar to pressing F5 (if the code isn't executed, you won't hit the breakpoint).
- Features that allow you to inspect variables are one of the most useful features of the debugger, and there are different ways to do it. Often, when trying to debug an issue, you will be attempting to find out whether variables are storing the values that you expect them to have at a particular point of execution.
+If you do want to stop the debugger and get back into the code editor, you can press the red stop  button instead of **Restart**.
## Inspect variables with data tips
-1. Click the green  button again to pause the debugger on the `Add` method call.
+Now that you know your way around a little, you have a good opportunity to start inspecting your app state (variables) with the debugger. Features that allow you to inspect variables are some of the most useful features of the debugger, and there are different ways to do it. Often, when trying to debug an issue, you will be attempting to find out whether variables are storing the values that you expect them to have at a particular point of execution.
-2. Now, hover over the File object (`f`) and you will see its default property value, the file name `market 031.jpg`.
+While paused in the debugger, hover over an object with the mouse and you will see its default property value (in this example, the file name `market 031.jpg` is the default property value).
- 
+
-3. Expland the object to see all its properties, such as the `FullName` property.
+Expland the object to see all its properties (such as the `FullPath` property in this example).
- Often, when debugging, you will want a quick way to check property values on objects, and the data tips are a good way to do it.
+Often, when debugging, you will want a quick way to check property values on objects, and the data tips are a good way to do it.
- > [!TIP]
- > In most supported languages, you can edit code in the middle of a debugger session if you find something you want to change. For more info, see [Edit and Continue](../debugger/edit-and-continue.md). To use that feature in this app, we would first need to update the app's version of the .NET Framework.
+> [!TIP]
+> In most supported languages, you can edit code in the middle of a debugging session if you find something you want to change. For more info, see [Edit and Continue](../debugger/edit-and-continue.md).
## Inspect variables with the Autos and Locals windows
-1. Take a look at the **Autos** window at the bottom of the code editor.
+While debugging, take a look at the **Autos** window at the bottom of the code editor.
- 
+
- In the **Autos** window, you see variables and their current value. The **Autos** window shows all variables used on the current line or the preceding line (In C++, the window shows variables in the preceding three lines of code. Check documentation for language-specific behavior).
+In the **Autos** window, you see variables along with their current value and their type. The **Autos** window shows all variables used on the current line or the preceding line (In C++, the window shows variables in the preceding three lines of code. Check documentation for language-specific behavior).
-2. Next, take a look at the **Locals** window.
+> [!NOTE]
+> In JavaScript, the **Locals** window is supported but not the **Autos** window.
- The **Locals** window shows you the variables that are in the current scope.
+Next, take a look at the **Locals** window. The **Locals** window shows you the variables that are currently in scope.
- 
+
- Currently, the `this` object and the File object (`f`) are in the current scope. For more info, see [Inspect Variables in the Autos and Locals Windows](../debugger/autos-and-locals-windows.md).
+In this example, the `this` object and the object `f` are in scope. For more info, see [Inspect Variables in the Autos and Locals Windows](../debugger/autos-and-locals-windows.md).
## Set a watch
-1. In the main code editor window, right-click the File object (`f`) and choose **Add Watch**.
+You can use a **Watch** window to specify a variable (or an expression) that you want to keep an eye on.
- You can use a **Watch** window to specify a variable (or an expression) that you want to keep an eye on.
+While debugging, right-click an object and choose **Add Watch**.
- Now, you have a watch set on the `File` object, and you can see it's value change as you move through the debugger. Unlike the other variable windows, the **Watch** window always shows the variables that you are watching (they're grayed out when out of scope).
-
- > [!TIP]
- > If you need to track the value of the variable even when it's out of scope, in C# you can right-click in the **Watch** windows and choose **Create an Object ID**.
-
-2. On the `Add` method, click the green  button again (or press F11 a few times) to advance through the `foreach` loop.
-
- 
+
- You might also see the first picture get added to the main window of the running sample app, but this happens on the UI thread, so images may not be visible yet.
+In this example, you have a watch set on the `File` object, and you can see it's value change as you move through the debugger. Unlike the other variable windows, the **Watch** windows always show the variables that you are watching (they're grayed out when out of scope).
+
+> [!TIP]
+> If you need to track the value of the variable even when it's out of scope, in C# you can right-click in the **Watch** windows and choose [Create an Object ID](https://docs.microsoft.com/en-us/visualstudio/debugger/watch-and-quickwatch-windows.md#bkmk_objectIds).
- For more info, see [Set a Watch using the Watch and QuickWatch Windows](../debugger/watch-and-quickwatch-windows.md)
+For more info, see [Set a Watch using the Watch and QuickWatch Windows](../debugger/watch-and-quickwatch-windows.md)
## Examine the call stack
-1. Click the **Call Stack** window, which is by default open in the lower right pane.
-
- 
+Click the **Call Stack** window while you are debugging, which is by default open in the lower right pane.
- The **Call Stack** window shows the order in which methods and functions are getting called. The top line shows the current function (the `Update` method in the tour app). The second line shows that `Update` was called from the `Path.set` property, and so on.
+
- > [!NOTE]
- > The **Call Stack** window is similar to the Debug perspective in some IDEs like Eclipse.
+The **Call Stack** window shows the order in which methods and functions are getting called. The top line shows the current function (the `Update` method in the this example). The second line shows that `Update` was called from the `Path.set` property, and so on. The call stack is a good way to examine and understand the execution flow of an app.
- The call stack is a good way to examine and understand the execution flow of an app.
+> [!NOTE]
+> The **Call Stack** window is similar to the Debug perspective in some IDEs like Eclipse.
- You can use right-click menus from the **Call Stack** window to do things like insert breakpoints into specified functions, restart your app using **Run to Cursor**, and to go examine source code. See [How to: Examine the Call Stack](../debugger/how-to-use-the-call-stack-window.md)
+You can double-click a line of code to go look at that source code (without advancing the debugger) and that also changes the current scope being inspected by the debugger.
- You can double-click a line of code to go look at that source code (without advancing the debugger) and that also changes the current scope being inspected by the debugger.
+You can also use right-click menus from the **Call Stack** window to do things like insert breakpoints into specified functions, restart your app using **Run to Cursor**, and to go examine source code. See [How to: Examine the Call Stack](../debugger/how-to-use-the-call-stack-window.md)
## Change the execution flow
-1. With the debugger paused on the `Add` method call, use the mouse to grab the yellow arrow pointer on the left and move the yellow arrow pointer up one line to the `foreach` loop.
+With the debugger paused on a line of code, use the mouse to grab the yellow arrow pointer on the left and move the yellow arrow pointer to a different point in the code execution path. Then you use F5 or a step command to continue running the app.
- 
+
- By changing the execution flow, you can do things like test different code execution paths or simply re-run code without restarting the debugger.
+By changing the execution flow, you can do things like test different code execution paths or simply re-run code without restarting the debugger.
-2. Now, press F5.
+> [!WARNING]
+> Often you need to be careful with this feature, and you see a warning in the tooltip. You may see other warnings, too. Moving the pointer does not undo any changes to the state of your application.
- You can see the images added to the app window. Because you are re-running code in the `foreach` loop, some of the images have been added twice!
-
- > [!WARNING]
- > Sometimes you need to be careful with this feature, and you see a warning in the tooltip. You may see other warnings, too. This does not undo any changes to the state of your application.
-
-## Run to cursor
-
-1. Choose the **Stop Debugging** red button  or Shift + F5.
-
-2. In the `Update` method, right-click the `Add` method call and choose **Run to Cursor**. This command starts debugging and sets a temporary breakpoint on the current line of code.
-
- 
-
- You should be paused on the breakpoint in `OnApplicationStartup` (since that is the first breakpoint.
-
-3. Press F5 to advance to the `Add` method where you selected **Run to Cursor**.
-
- This command is useful when you are editing code and want to quickly set a temporary breakpoint and start the debugger.
-
-## Step out
-
-Let's say that you are done examining the `Update` method in Data.cs, then you might want to step out of the function using the **Step Out** command.
-
-1. Press Shift + F11 (or **Debug / Step Out**).
-
- This resumes app execution (and advances the debugger) until the current function returns.
-
- You should be back in the `Update` method call in Data.cs.
-
-2. Press Shift + F11 again, and the debugger goes up the call stack back to the `OnApplicationStartup` event handler.
+## Examine an exception
-3. Press F5 to continue.
+When your app throws an exception, the debugger takes you to the line of code that threw the exception.
+
+
-## Examine an exception
+In this example, the **Exception Helper** shows you a `System.Argument` exception and an error message that says that the path is not a legal form. So, we know the error occurred on a method or function argument.
-1. In the running app window, delete the text in the **Path** input box and select the **Change** button.
+In this example, the `DirectoryInfo` call gave the error on the empty string stored in the `value` variable.
- 
+The Exception Helper is a great feature that can help you debug errors. You can also do things like view error details and add a watch from the Exception Helper. Or, if needed, you can change conditions for throwing the particular exception.
- The app throws an exception, and the debugger takes you to the line of code that threw the exception.
-
- 
+> [!NOTE]
+> The Exception Helper replaces the Exception Assistant in [!include[vs_dev15](../misc/includes/vs_dev15_md.md)].
- Here, the **Exception Helper** shows you a `System.Argument` exception and an error message that says that the path is not a legal form. So, we know the error occurred on a method or function argument.
+Expand the **Exception Settings** node to see more options on how to handle this exception type, but you don't need to change anything for this tour!
- In this example, the `DirectoryInfo` call gave the error on the empty string stored in the `value` variable. (Hover over `value` to see the empty string.)
+## More features to look at
- The Exception Helper is a great feature that can help you debug errors. You can also do things like view error details and add a watch from the Exception Helper. Or, if needed, you can change conditions for throwing the particular exception.
+- [Edit and Continue](../debugger/edit-and-continue.md) For a subset of languages (C#, C++, Visual Basic), the Edit and Continue feature allows you to edit code in the middle of a debugging session if you find something you want to change.
- > [!NOTE]
- > The Exception Helper replaces the Exception Assistant in [!include[vs_dev15](../misc/includes/vs_dev15_md.md)].
+- [Debug Multithreaded Applications](../debugger/debug-multithreaded-applications-in-visual-studio.md) Describes how to debug multithreaded applications.
-2. Expand the **Exception Settings** node to see more options on how to handle this exception type, but you don't need to change anything for this tour!
+- [Remote Debugging](../debugger/remote-debugging.md) Describes how to debug apps running on other machines or devices.
+
+- [IntelliTrace](../debugger/intellitrace.md) Describes the IntelliTrace feature in Visual Studio Enterprise. You can use it to record and trace your code's execution history.
-3. Press F5 to continue the app.
+- [Network Usage](../profiling/network-usage.md) Describes a profiling tool that you can use to debug web services and other network resources in Universal Windows Apps (UWP). Use the tool to examine payloads.
- Congratulations on completing the tour of the debugger! We hope you learned a lot about some of its main features!
+- [Debug Interface Access SDK](../debugger/debug-interface-access/debug-interface-access-sdk.md) Describes the Microsoft Debug Interface Access Software Development Kit (DIA SDK). The DIA SDK provides access to debug information stored in program database (.pdb) files generated by Microsoft postcompiler tools.
## See Also
[Debugging in Visual Studio](../debugger/debugging-in-visual-studio.md)
\ No newline at end of file
diff --git a/docs/debugger/first-look-at-the-debugger.md b/docs/debugger/first-look-at-the-debugger.md
new file mode 100644
index 00000000000..86f5b7fb6fe
--- /dev/null
+++ b/docs/debugger/first-look-at-the-debugger.md
@@ -0,0 +1,102 @@
+---
+title: "Get Started with the Debugger in Visual Studio | Microsoft Docs"
+ms.custom: "H1Hack27Feb2017"
+ms.date: "02/07/2017"
+ms.reviewer: ""
+ms.suite: ""
+ms.technology:
+ - "vs-ide-debug"
+ms.tgt_pltfrm: ""
+ms.topic: "get-started-article"
+ms.assetid: 0b3138c4-b840-446a-a15c-10ed8e2dd050
+caps.latest.revision: 5
+author: "mikejo5000"
+ms.author: "mikejo"
+manager: "ghogen"
+translation.priority.ht:
+ - "cs-cz"
+ - "de-de"
+ - "es-es"
+ - "fr-fr"
+ - "it-it"
+ - "ja-jp"
+ - "ko-kr"
+ - "pl-pl"
+ - "pt-br"
+ - "ru-ru"
+ - "tr-tr"
+ - "zh-cn"
+ - "zh-tw"
+---
+# Get Started with the Visual Studio Debugger
+The Visual Studio debugger is easy to use in any language. Here we’ll show how to debug a simple C# program, but you can apply the same steps to code in other languages such as C++ and JavaScript.
+
+To watch a video showing similar features, see [Getting Started with the Debugger](https://www.youtube.com/watch?v=FtGCi5j30YU&list=PLReL099Y5nRfw6VNvzMkv0sabT2crbSpK&index=6).
+
+## Debug a Basic C# Project
+ Let’s start with a simple C# console application (**File / New / Project**, then select **Visual C#** and then **Console Application**). If you’ve never worked with Visual Studio before, see [Walkthrough: Create a Simple Application](../ide/walkthrough-create-a-simple-application-with-visual-csharp-or-visual-basic.md). The **Main** method just adds 1 to an integer variable 10 times and prints the result to the console:
+
+```CSharp
+static void Main(string[] args)
+{
+ int testInt = 0;
+ for (int i = 1; i <= 10; i++)
+ {
+ testInt += 1;
+ }
+ Console.WriteLine(testInt);
+}
+```
+
+ Build this code in the **Debug** configuration. This configuration is set by default. For more information about configurations, see [Understanding Build Configurations](../ide/understanding-build-configurations.md).
+
+ Run this code in the debugger by clicking **Debug / Start Debugging** (or **Start** on the toolbar, or **F5**). The application should exit almost immediately, so you can’t actually tell whether anything was printed in the Console window.
+
+ You can stop the execution long enough to see the Console window by setting a breakpoint and then stepping ahead. To set a breakpoint, put your cursor in the `Console.WriteLine` line and click **Debug / New Breakpoint / Function Breakpoint**, or just click in the left margin at the same line. The breakpoint should look like this:
+
+ 
+
+ For more information about breakpoints, see [Using Breakpoints](../debugger/using-breakpoints.md).
+
+## Inspect Variables
+ Debugging often involves finding variables that don't contain the values you expect at a particular point. We will show some of the ways that you can inspect variables.
+
+ Start debugging again. Execution stops before the `Console.WriteLine` code executes. You can cause it to execute by stepping ahead (click **Debug / Step Over** or **F10**). In this case you could have chosen **Step Into** (**F11**) and gotten the same result; we’ll explain the difference later on. The line with the last curly brace of the method should have turned yellow. Look at the Console window. You should see **10**.
+
+ You can hover over the **testInt** variable to view the current value in a data tip.
+
+ 
+
+ Just below the code window you should see the **Autos**, **Locals**, and **Watch** windows. These windows show the current values of variables at the time of execution. Both the **Autos** and the **Locals** windows show **testInt** with a value of **10**.
+
+ 
+
+ For more information about these windows, see [Autos and Locals Windows](../debugger/autos-and-locals-windows.md).
+
+ Let’s see how the variable value changes as we walk through the program. Set a breakpoint on the `testInt += 1;` line, and restart debugging. You should see that **testInt** in the **Locals** and **Autos** windows is **0**, and **i** is **1**. When you continue debugging (**Debug / Continue**, or **Continue** on the toolbar, or **F5**), you can see that the value of **testInt** changes to **1**, then **2**, and so on. When you get tired of looking at these changes, remove the breakpoint (**Debug / Toggle Breakpoint**, or click on it in the margin), and continue debugging. If you want to remove all the breakpoints, click **Debug / Delete All Breakpoints**, or **CTRL+SHIFT+F9**, and click **Yes** on the dialog box that asks **Do you want to remove all breakpoints?**.
+
+## Stepping Into and Over Function Calls
+ You can execute code in the debugger statement-by-statement (**Step Into**) or you can execute code while the debugger skips functions (**Step Over**) to quickly get to code that you're more interested in (function code is still executed). You can switch between both methods in the same debugging session.
+
+ To see the difference between **Step Into** and **Step Over**, we need to add a method that is called by another method. Add a method to the C# application and call it from the Main method. The code should look something like this:
+
+```CSharp
+static void Main(string[] args)
+{
+ Method1();
+ Console.WriteLine("end");
+}
+
+private static void Method1()
+{
+ Console.WriteLine("in Method1");
+}
+```
+
+ Set a breakpoint on the `Method1();` call in the Main method and start debugging. When execution breaks, click **Debug / Step Into** (or **Step Into** on the toolbar, or **F11**). Execution breaks again at the first curly brace in Method1():
+
+ 
+
+ Stop debugging and start again, and when execution breaks at the breakpoint, click **Debug / Step Over** (or **Step Over** on the toolbar, or **F10**). Execution breaks again at `Console.WriteLine("end");`.
+
+ If you want to know more about navigating code with the debugger, see [Navigating through Code with the Debugger](../debugger/navigating-through-code-with-the-debugger.md).
\ No newline at end of file
diff --git a/docs/debugger/getting-started-with-the-debugger.md b/docs/debugger/getting-started-with-the-debugger.md
index 31d0f06e132..15d9db3b14b 100644
--- a/docs/debugger/getting-started-with-the-debugger.md
+++ b/docs/debugger/getting-started-with-the-debugger.md
@@ -1,102 +1,292 @@
---
-title: "Get Started with the Debugger in Visual Studio | Microsoft Docs"
-ms.custom: "H1Hack27Feb2017"
-ms.date: "02/07/2017"
+title: "Debugger Feature Tour | Microsoft Docs"
+ms.custom: ""
+ms.date: "03/04/2017"
ms.reviewer: ""
ms.suite: ""
ms.technology:
- "vs-ide-debug"
ms.tgt_pltfrm: ""
ms.topic: "get-started-article"
+helpviewer_keywords:
+ - "debugger"
ms.assetid: 62734c0d-a75a-4576-8f73-0e97c19280e1
-caps.latest.revision: 5
+caps.latest.revision: 1
author: "mikejo5000"
ms.author: "mikejo"
manager: "ghogen"
translation.priority.ht:
- - "cs-cz"
- "de-de"
- "es-es"
- "fr-fr"
- "it-it"
- "ja-jp"
- "ko-kr"
- - "pl-pl"
- - "pt-br"
- "ru-ru"
- - "tr-tr"
- "zh-cn"
- "zh-tw"
+translation.priority.mt:
+ - "cs-cz"
+ - "pl-pl"
+ - "pt-br"
+ - "tr-tr"
---
-# Get Started with the Visual Studio Debugger
-The Visual Studio debugger is easy to use in any language. Here we’ll show how to debug a simple C# program, but you can apply the same steps to code in other languages such as C++ and JavaScript.
-
-To watch a video showing similar features, see [Getting Started with the Debugger](https://www.youtube.com/watch?v=FtGCi5j30YU&list=PLReL099Y5nRfw6VNvzMkv0sabT2crbSpK&index=6).
-
-## Debug a Basic C# Project
- Let’s start with a simple C# console application (**File / New / Project**, then select **Visual C#** and then **Console Application**). If you’ve never worked with Visual Studio before, see [Walkthrough: Create a Simple Application](../ide/walkthrough-create-a-simple-application-with-visual-csharp-or-visual-basic.md). The **Main** method just adds 1 to an integer variable 10 times and prints the result to the console:
-
-```CSharp
-static void Main(string[] args)
-{
- int testInt = 0;
- for (int i = 1; i <= 10; i++)
- {
- testInt += 1;
- }
- Console.WriteLine(testInt);
-}
-```
-
- Build this code in the **Debug** configuration. This configuration is set by default. For more information about configurations, see [Understanding Build Configurations](../ide/understanding-build-configurations.md).
-
- Run this code in the debugger by clicking **Debug / Start Debugging** (or **Start** on the toolbar, or **F5**). The application should exit almost immediately, so you can’t actually tell whether anything was printed in the Console window.
-
- You can stop the execution long enough to see the Console window by setting a breakpoint and then stepping ahead. To set a breakpoint, put your cursor in the `Console.WriteLine` line and click **Debug / New Breakpoint / Function Breakpoint**, or just click in the left margin at the same line. The breakpoint should look like this:
-
- 
-
- For more information about breakpoints, see [Using Breakpoints](../debugger/using-breakpoints.md).
-
-## Inspect Variables
- Debugging often involves finding variables that don't contain the values you expect at a particular point. We will show some of the ways that you can inspect variables.
-
- Start debugging again. Execution stops before the `Console.WriteLine` code executes. You can cause it to execute by stepping ahead (click **Debug / Step Over** or **F10**). In this case you could have chosen **Step Into** (**F11**) and gotten the same result; we’ll explain the difference later on. The line with the last curly brace of the method should have turned yellow. Look at the Console window. You should see **10**.
-
- You can hover over the **testInt** variable to view the current value in a data tip.
-
- 
-
- Just below the code window you should see the **Autos**, **Locals**, and **Watch** windows. These windows show the current values of variables at the time of execution. Both the **Autos** and the **Locals** windows show **testInt** with a value of **10**.
-
- 
-
- For more information about these windows, see [Autos and Locals Windows](../debugger/autos-and-locals-windows.md).
-
- Let’s see how the variable value changes as we walk through the program. Set a breakpoint on the `testInt += 1;` line, and restart debugging. You should see that **testInt** in the **Locals** and **Autos** windows is **0**, and **i** is **1**. When you continue debugging (**Debug / Continue**, or **Continue** on the toolbar, or **F5**), you can see that the value of **testInt** changes to **1**, then **2**, and so on. When you get tired of looking at these changes, remove the breakpoint (**Debug / Toggle Breakpoint**, or click on it in the margin), and continue debugging. If you want to remove all the breakpoints, click **Debug / Delete All Breakpoints**, or **CTRL+SHIFT+F9**, and click **Yes** on the dialog box that asks **Do you want to remove all breakpoints?**.
-
-## Stepping Into and Over Function Calls
- You can execute code in the debugger statement-by-statement (**Step Into**) or you can execute code while the debugger skips functions (**Step Over**) to quickly get to code that you're more interested in (function code is still executed). You can switch between both methods in the same debugging session.
-
- To see the difference between **Step Into** and **Step Over**, we need to add a method that is called by another method. Add a method to the C# application and call it from the Main method. The code should look something like this:
-
-```CSharp
-static void Main(string[] args)
-{
- Method1();
- Console.WriteLine("end");
-}
-
-private static void Method1()
-{
- Console.WriteLine("in Method1");
-}
-```
-
- Set a breakpoint on the `Method1();` call in the Main method and start debugging. When execution breaks, click **Debug / Step Into** (or **Step Into** on the toolbar, or **F11**). Execution breaks again at the first curly brace in Method1():
-
- 
-
- Stop debugging and start again, and when execution breaks at the breakpoint, click **Debug / Step Over** (or **Step Over** on the toolbar, or **F10**). Execution breaks again at `Console.WriteLine("end");`.
-
- If you want to know more about navigating code with the debugger, see [Navigating through Code with the Debugger](../debugger/navigating-through-code-with-the-debugger.md).
\ No newline at end of file
+# Debugger feature tour
+
+This topic introduces the features of the Visual Studio debugger in an step-by-step walkthrough. If you want a higher-level view of the debugger features, see [Debugger Feature Tour](../debugger/debugger-feature-tour.md).
+
+You can either read along to see the features of the debugger or you can download the complete sample used in the feature tour and follow the step-by-step instructions yourself. To download the sample and follow along, go to [Photo Viewer Demo](https://code.msdn.microsoft.com/windowsdesktop/WPF-Photo-Viewer-Demo-be75662a).
+
+Although the demo app is C#, the features are applicable to C++, Visual Basic, JavaScript, and other languages supported by Visual Studio (except where noted).
+
+## Start the tour!
+
+1. To follow along these steps in Visual Studio, download the sample [on this page](https://code.msdn.microsoft.com/windowsdesktop/WPF-Photo-Viewer-Demo-be75662a).
+
+ > [!IMPORTANT]
+ > You need to install Visual Studio with the .NET Desktop Development workload to run the app we're using in the demo.
+
+2. Unzip the project.
+
+3. Open Visual Studio and select the **File / Open** menu command, then choose **Project/Solution**, and then open the folder where you downloaded the project.
+
+ 
+
+3. Open the WPF Photo Viewer Demo / C# folder, choose the photoapp.sln file, and select **Open**.
+
+ The project opens in Visual Studio. Solution Explorer in the right pane shows you all the project files.
+
+ 
+
+4. Press F5 (**Debug / Start Debugging** or the **Start Debugging** button  in the Debug Toolbar).
+
+ 
+
+ F5 starts the app with the debugger attached to the app process, but right now we haven't added any breakpoints or done anything special to examine the code. So the app just loads and you see the photo images.
+
+ In this tour, we'll take a closer look at this app using the debugger and get a look at the debugger features.
+
+5. Stop the debugger by pressing the red stop  button.
+
+## Set a breakpoint and start the debugger
+
+To debug, you need to start your app with the debugger attached to the app process.
+
+1. In the `MainWindow` constructor of MainWindow.xaml.cs, set a breakpoint by clicking in the margin to the left of the first line of code.
+
+ 
+
+6. Press F5 or the **Start Debugging** button, the app starts, and the debugger runs to the line of code where you set the breakpoint.
+
+ The yellow arrow represents the statement on which the debugger paused, which also suspends app execution at the same point (this statement has not yet executed).
+
+ F5 either continues running the app to the next breakpoint or, if the app is not yet running, it starts the debugger and stops at the first breakpoint.
+
+ Breakpoints are a really useful feature when you know the line of code or the section of code that you want to examine in detail.
+
+## Restart your app quickly
+
+1. Click the **Restart**  button in the Debug Toolbar (Ctrl + Shift +F5).
+
+ When you press **Restart**, it saves time versus stopping the app and restarting the debugger. The debugger pauses at the first breakpoint that is hit by executing code, similar to pressing F5 (if the code isn't executed, you won't hit the breakpoint).
+
+ The debugger will stop again at the breakpoint you just set, in the `MainWindow` constructor.
+
+## Navigate code in the debugger using step commands
+
+Mostly, we will use the keyboard shortcuts here, because it's a good way to get fast at executing your app in the debugger (equivalent commands such as menu commands are shown in parentheses).
+
+1. Press F11 (**Debug / Step Into**) twice to advance the execution of the app to the `InitializeComponent()` function.
+
+ 
+
+ F11 is the **Step Into** command and advances the app execution one statement at a time. F11 is a good way to examine the execution flow in the most detail. (To move faster through code, we will show you some other options also.) By default, the debugger skips over non-user code (if you want more details, see [Just My Code](../debugger/just-my-code.md)).
+
+ >[!NOTE]
+ > In managed code, you will see a dialog box asking if you want to be notified when you automatically step over properties and operators (default behavior). If you want to change the setting later, disable **Step over properties and operators** setting in the **Tools / Options** menu under **Debugging**.
+
+2. Press F10 (**Debug / Step Over**) a few times until the debugger stops on the first line of code in the `OnApplicationStartup` event handler.
+
+ 
+
+ F10 advances the debugger without stepping into functions or methods in your app code (the code still executes). By pressing F10 on the `InitializeComponent` method call (instead of F11), we skipped over the implementation code for `InitializeComponent` (which maybe we're not interested in right now).
+
+## Step into a property
+
+1. With the debugger paused on this line of code:
+
+ ````
+ mainWindow.Photos.Path = Environment.CurrentDirectory + "\\images";
+ ````
+
+ Right-click on the line of code and choose **Step Into Specific**, then **SDKSamples.ImageSample.PhotoCollection.Path.set**
+
+ 
+
+ As mentioned earlier, by default the debugger skips over managed properties and fields, but the **Step Into Specific** command allows you to override this behavior. For now, we want to look what happens when the `Path.set` property setter runs. **Step Into Specific** gets us to the `Path.set` code here.
+
+ 
+
+ The `Update` method in this code looks like it could be interesting, so lets use the debugger to examine that code up close.
+
+5. Hover over the `Update` method until the green **Run execution to here** button  appears on the left.
+
+ 
+
+ > [!NOTE]
+ > The **Run execution to here** button is new in [!include[vs_dev15](../misc/includes/vs_dev15_md.md)]. If you don't see the green arrow button, use F11 in this example instead to advance the debugger.
+
+6. Click the **Run execution to here** button .
+
+ Using this button is similar to setting a temporary breakpoint, which is also handy for getting around quickly within a visible region of app code (you can click in any open file).
+
+ The debugger advances to the `Update` method implementation.
+
+7. Press F11 to step into the `Update` method.
+
+ 
+
+ Here, we find some more code that looks interesting; it appears the app is getting all *.jpg files residing in a particular directory, and then creating a new Photo object for each file. This gives us a good opportunity to start inspecting your app state (variables) with the debugger.
+
+ Features that allow you to inspect variables are one of the most useful features of the debugger, and there are different ways to do it. Often, when trying to debug an issue, you will be attempting to find out whether variables are storing the values that you expect them to have at a particular point of execution.
+
+## Inspect variables with data tips
+
+1. Hover over the `Add` method call and click the **Run execution to here** button  to pause the debugger on the `Add` method call.
+
+2. Now, hover over the File object (`f`) and you will see its default property value, the file name `market 031.jpg`.
+
+ 
+
+3. Expland the object to see all its properties, such as the `FullPath` property.
+
+ Often, when debugging, you will want a quick way to check property values on objects, and the data tips are a good way to do it.
+
+ > [!TIP]
+ > In most supported languages, you can edit code in the middle of a debugger session if you find something you want to change. For more info, see [Edit and Continue](../debugger/edit-and-continue.md). To use that feature in this app, we would first need to update the app's version of the .NET Framework.
+
+## Inspect variables with the Autos and Locals windows
+
+1. Take a look at the **Autos** window at the bottom of the code editor.
+
+ 
+
+ In the **Autos** window, you see variables and their current value. The **Autos** window shows all variables used on the current line or the preceding line (In C++, the window shows variables in the preceding three lines of code. Check documentation for language-specific behavior).
+
+ > [!NOTE]
+ > In JavaScript, the **Locals** window is supported but not the **Autos** window.
+
+2. Next, take a look at the **Locals** window.
+
+ The **Locals** window shows you the variables that are in the current scope.
+
+ 
+
+ Currently, the `this` object and the File object (`f`) are in the current scope. For more info, see [Inspect Variables in the Autos and Locals Windows](../debugger/autos-and-locals-windows.md).
+
+## Set a watch
+
+1. In the main code editor window, right-click the File object (`f`) and choose **Add Watch**.
+
+ You can use a **Watch** window to specify a variable (or an expression) that you want to keep an eye on.
+
+ Now, you have a watch set on the `File` object, and you can see it's value change as you move through the debugger. Unlike the other variable windows, the **Watch** window always shows the variables that you are watching (they're grayed out when out of scope).
+
+ > [!TIP]
+ > If you need to track the value of the variable even when it's out of scope, in C# you can right-click in the **Watch** windows and choose [Create an Object ID](../debugger/watch-and-quickwatch-windows#bkmk_objectIds).
+
+2. On the `Add` method, click the green  button again (or press F11 a few times) to advance through the `foreach` loop.
+
+ 
+
+ You might also see the first picture get added to the main window of the running sample app, but this happens on the UI thread, so images may not be visible yet.
+
+ For more info, see [Set a Watch using the Watch and QuickWatch Windows](../debugger/watch-and-quickwatch-windows.md)
+
+## Examine the call stack
+
+1. Click the **Call Stack** window, which is by default open in the lower right pane.
+
+ 
+
+ The **Call Stack** window shows the order in which methods and functions are getting called. The top line shows the current function (the `Update` method in the tour app). The second line shows that `Update` was called from the `Path.set` property, and so on.
+
+ > [!NOTE]
+ > The **Call Stack** window is similar to the Debug perspective in some IDEs like Eclipse.
+
+ The call stack is a good way to examine and understand the execution flow of an app.
+
+ You can double-click a line of code to go look at that source code (without advancing the debugger) and that also changes the current scope being inspected by the debugger.
+
+ You can also use right-click menus from the **Call Stack** window to do things like insert breakpoints into specified functions, restart your app using **Run to Cursor**, and to go examine source code. See [How to: Examine the Call Stack](../debugger/how-to-use-the-call-stack-window.md)
+
+## Change the execution flow
+
+1. With the debugger paused on the `Add` method call, use the mouse to grab the yellow arrow pointer on the left and move the yellow arrow pointer up one line to the `foreach` loop.
+
+ 
+
+ By changing the execution flow, you can do things like test different code execution paths or simply re-run code without restarting the debugger.
+
+2. Now, press F5.
+
+ You can see the images added to the app window. Because you are re-running code in the `foreach` loop, some of the images have been added twice!
+
+ > [!WARNING]
+ > Often you need to be careful with this feature, and you see a warning in the tooltip. You may see other warnings, too. Moving the pointer does not undo any changes to the state of your application.
+
+## Run to cursor
+
+1. Choose the **Stop Debugging** red button  or Shift + F5.
+
+2. In the `Update` method, right-click the `Add` method call and choose **Run to Cursor**. This command starts debugging and sets a temporary breakpoint on the current line of code.
+
+ 
+
+ You should be paused on the breakpoint in `OnApplicationStartup` (since that is the first breakpoint.
+
+3. Press F5 to advance to the `Add` method where you selected **Run to Cursor**.
+
+ This command is useful when you are editing code and want to quickly set a temporary breakpoint and start the debugger.
+
+## Step out
+
+Let's say that you are done examining the `Update` method in Data.cs, then you might want to step out of the function using the **Step Out** command.
+
+1. Press Shift + F11 (or **Debug / Step Out**).
+
+ This resumes app execution (and advances the debugger) until the current function returns.
+
+ You should be back in the `Update` method call in Data.cs.
+
+2. Press Shift + F11 again, and the debugger goes up the call stack back to the `OnApplicationStartup` event handler.
+
+3. Press F5 to continue.
+
+## Examine an exception
+
+1. In the running app window, delete the text in the **Path** input box and select the **Change** button.
+
+ 
+
+ The app throws an exception, and the debugger takes you to the line of code that threw the exception.
+
+ 
+
+ Here, the **Exception Helper** shows you a `System.Argument` exception and an error message that says that the path is not a legal form. So, we know the error occurred on a method or function argument.
+
+ In this example, the `DirectoryInfo` call gave the error on the empty string stored in the `value` variable. (Hover over `value` to see the empty string.)
+
+ The Exception Helper is a great feature that can help you debug errors. You can also do things like view error details and add a watch from the Exception Helper. Or, if needed, you can change conditions for throwing the particular exception.
+
+ > [!NOTE]
+ > The Exception Helper replaces the Exception Assistant in [!include[vs_dev15](../misc/includes/vs_dev15_md.md)].
+
+2. Expand the **Exception Settings** node to see more options on how to handle this exception type, but you don't need to change anything for this tour!
+
+3. Press F5 to continue the app.
+
+ Congratulations on completing the tour of the debugger! We hope you learned a lot about some of its main features!
+
+## See Also
+ [Debugging in Visual Studio](../debugger/debugging-in-visual-studio.md)
\ No newline at end of file
diff --git a/docs/debugger/media/dbg-tour-f11-start.png b/docs/debugger/media/dbg-tour-f11-start.png
deleted file mode 100644
index cf51398d455..00000000000
Binary files a/docs/debugger/media/dbg-tour-f11-start.png and /dev/null differ
diff --git a/docs/debugger/media/dbg-tour-f11.png b/docs/debugger/media/dbg-tour-f11.png
new file mode 100644
index 00000000000..9ed0eec7639
Binary files /dev/null and b/docs/debugger/media/dbg-tour-f11.png differ
diff --git a/docs/debugger/media/dbg-tour-run-to-click.png b/docs/debugger/media/dbg-tour-run-to-click.png
index 759ccf979e5..59118c5b832 100644
Binary files a/docs/debugger/media/dbg-tour-run-to-click.png and b/docs/debugger/media/dbg-tour-run-to-click.png differ
diff --git a/docs/debugger/media/dbg-tour-set-a-breakpoint.gif b/docs/debugger/media/dbg-tour-set-a-breakpoint.gif
index 02304d91e1c..99faa5d86a7 100644
Binary files a/docs/debugger/media/dbg-tour-set-a-breakpoint.gif and b/docs/debugger/media/dbg-tour-set-a-breakpoint.gif differ
diff --git a/docs/profiling/profiling-feature-tour.md b/docs/profiling/profiling-feature-tour.md
index aa54af76ebf..5fa7f08e851 100644
--- a/docs/profiling/profiling-feature-tour.md
+++ b/docs/profiling/profiling-feature-tour.md
@@ -35,13 +35,13 @@ translation.priority.mt:
Visual Studio provides a variety of profiling tools to help you diagnose different kinds of performance issues depending on your app type.
-The profiling tools that you can access during a debugging session are available in the Diagnostics Tools window. The Diagnostic Tools window appears automatically unless you have turned it off. To bring up the window, click **Debug / Windows / Show Diagnostic Tools**. With the window open, you can select tools for which you want to collect data.
+The profiling tools that you can access during a debugging session are available in the Diagnostic Tools window. The Diagnostic Tools window appears automatically unless you have turned it off. To bring up the window, click **Debug / Windows / Show Diagnostic Tools**. With the window open, you can select tools for which you want to collect data.
-
+
While you are debugging, you can use the **Diagnostic Tools** window to analyze CPU and memory usage, and you can view events that show performance-related information.
-
+
The **Diagnostic Tools** window is often the preferred way to profile apps, but you can also do a post-mortem analysis of your app instead. If you want more information on different approaches, see [Running Profiling Tools With or Without the Debugger](../profiling/running-profiling-tools-with-or-without-the-debugger.md).
@@ -51,17 +51,17 @@ The CPU Usage tool is a good place to start analyzing your app's performance. It
From the **Summary** view of the Diagnostic Tools, choose **Enable CPU Profiling** (you must be in a debugging session).
-
+
To use the tool most effectively, set two breakpoints in your code, one at the beginning and one at the end of the function or the region of code you want to analyze. Examine the profiling data when you are paused at the second breakpoint.
The **CPU Usage** view shows you a list of functions ordered by longest running, with the longest running function at the top. This can help guide you to functions where performance bottlenecks are happening.
-
+
-Double-click on a function that you are interested in, and you will see a more detailed three-pane view, with the selected function in the middle of the window, the calling function on the left, and called functions on the right. The **Function Body** section shows the total amount of time (and the percentage of time) spent in the function body excluding time spent in calling and called functions. This data can help you evaluate whether the function itself is a performance bottleneck.
+Double-click on a function that you are interested in, and you will see a more detailed three-pane "butterfly" view, with the selected function in the middle of the window, the calling function on the left, and called functions on the right. The **Function Body** section shows the total amount of time (and the percentage of time) spent in the function body excluding time spent in calling and called functions. This data can help you evaluate whether the function itself is a performance bottleneck.
-
+
## Analyze Memory Usage
@@ -69,11 +69,11 @@ The Diagnostic Tools window also allows you to evaluate memory usage in your app
To analyze memory usage, you need to take at least one memory snapshot while you are debugging. Often, the best way to analyze memory is to take two snapshots; the first right before a suspected memory issue, and the second snapshot right after a suspected memory issue occurs. Then you can view a diff of the two snapshots and see exactly what changed.
-
+
When you select one of the arrow links, you are given a differential view of the heap (a red up arrow  shows an increasing object count (left) or an increasing heap size (right)). If you click the right link, you get a differential heap view ordered by objects that increased the most in heap size. This can help you pinpoint memory problems. For example, in the illustration below, the bytes used by `ClassHandlersStore` objects increased by 3,492 bytes in the second snapshot.
-
+
If you click the link on the left instead in the **Memory Usage** view, the heap view is organized by object count; the objects of a particular type that increased the most in number are shown at the top (sorted by **Count Diff** column).
@@ -81,12 +81,12 @@ If you click the link on the left instead in the **Memory Usage** view, the heap
The **Events** view in the Diagnostic Tools shows you different events that occur while you are debugging, such as the setting of a breakpoint or a code stepping operation. You can check information such as the duration of the event (measured from when the debugger was last paused, or when the app started). For example, if you step through code (F10, F11), the **Events** view shows you the app runtime duration from the previous step operation to the current step.
-
+
> [!NOTE]
> If you have Visual Studio Enterprise, you can also see [IntelliTrace events](../debugger/intellitrace.md) in this tab.
-The same events also show up in the Code Editor, which you can view as PerfTips.
+The same events also show up in the code editor, which you can view as PerfTips.
@@ -94,7 +94,7 @@ The same events also show up in the Code Editor, which you can view as PerfTips.
In your UWP apps, you can enable **UI Analysis** in the Diagnostic Tools window. The tool searches for common performance or accessibility issues and displays them in the **Events** view while you are debugging. The event descriptions provide information that can help resolve issues.
-
+
## Profile Release Builds without the Debugger
@@ -112,7 +112,7 @@ In XAML apps, such as Windows desktop WPF apps and Windows Store apps, you can a
Low framerates in the **Visual throughput** graph may correspond to visual problems that you see when running your app. Similarly, high numbers in the **UI thread utilization** graph may also correspond to UI responsiveness issues. In the report, you can select a time period with a suspected performance issue, and then examine the detailed UI thread activities in the Timeline details view (lower pane).
-
+
In the Timeline details view, you can find information such as the type of activitiy (or the UI element involved) along with the duration of the activity. For example, in the illustration, a **Layout** event for a Grid control takes 57.53 ms.
@@ -124,7 +124,7 @@ In Direct3D apps (Direct3D components must be in C++), you can examine activity
When you select a time period in the graphs and choose **view details**, a detailed view appears in the lower pane. In the detailed view, you can examine how much activity is happening on each CPU and GPU. Select events in the lowest pane to get popups in the timeline. For example, select the **Present** event to view **Present** call popups. (The light gray vertical Vsync lines can be used as a reference to understand whether certain **Present** calls missed Vsync. There must be one **Present** call between every two Vsyncs in order for the app to steadily hit 60 FPS.)
-
+
You can also use the graphs to determine whether there are CPU bound or GPU bound performance bottlenecks.
@@ -134,21 +134,21 @@ For Windows Universal HTML apps, you can use the JavaScript Memory tool and the
The JavaScript Memory tool is similar to the Memory Usage tool available for other app types. You can use this tool to understand memory usage and find memory leaks in your app. For more details about the tool, see [JavaScript Memory](../profiling/javascript-memory.md).
-
+
To diagnose UI responsiveness, slow loading time, and slow visual updates in Windows Universal HTML apps, use the HTML UI Responsiveness tool. Usage is similar to the Application Timeline tool for other app types. For more information, see [HTML UI responsiveness](../profiling/html-ui-responsiveness.md).
-
+
## Analyze Network Usage (UWP)
In UWP apps, you can analyze network operations performed using the `Windows.Web.Http` API.This tool may help you to resolve issues like access and authentication problems, incorrect cache-use, and poor display and download performance. To use the tool, choose **Network** in the Performance Profiler, and then choose **Start**. In your app, go through the scenario that uses `Windows.Web.Http`, and then choose **Stop collection** to generate the report.
-
+
Select an operation in the summary view to view more details.
-
+
For more information, see [Network Usage](../profiling/network-usage.md).
@@ -156,7 +156,7 @@ For more information, see [Network Usage](../profiling/network-usage.md).
If you need features such as instrumentation that are not currently present in CPU Usage or Memory Usage tools, and you are running desktop or ASP.NET apps, you can use the Performance Explorer for profiling. (Not supported in UWP apps). For more info, see [Performance Explorer](../profiling/performance-explorer.md)
-
+
## Which Tool Should I Use?
Here is a table that lists the different tools Visual Studio offers and the different project types you can use them with: