Join Walt Ritscher for an in-depth discussion in this video Understand the debugging vocabulary, part of Visual Studio 2015 Essential Training: 06 Debug and Troubleshoot Code.
- There are many terms that programmers use to describe their debugging and diagnostic tools. The most obvious terms are debug and debugging but there are more. Here's a list of those items. Code tracing, diagnostics, instrumentation, and profiling. I'll be talking about each one of these in more detail in this video. Here's the most common explanation of what it means to debug an application. The application has a programming error.
It's our job to track down and fix the error. This is a common task during development. A majority of bugs are fixed during the application development, testing, or QA phase. The term instrumentation refers to a broad set of tools that enable you to analyze the application while it is running. You take your app code and modify it in some way, usually by adding instrumentation code to your code base. Then when you compile the app, it contains the additional code. When you run the app on your test machines, you can observe the information produced from the instrumented application.
If you want, you can ship the app with some of the instrumentation still in the app. In many cases, the DevOps people in your company will look at this logged information coming from the app which means that the developer and IT admins both benefit from the instrumentation in the application. Instrumentation is a broad category. Here are some of the common tasks that can be done with it. Write trace information, diagnose errors, measure application performance, profile code constructs.
Let's look at each one of these items. Tracing is a specialized form of logging used to record information about a program's execution. This information is typically used by programmers for debugging purposes. Additionally, if the tracing code is included in the final release version the app, it can be useful for experienced system administrators or technical support personnel to diagnose common problems with the software. The trace output is created while the application runs.
The information itself is placed in a log location which can be in a file, on the deployed computer, into a computer event log, or other locations. It's rare for a programmer to write apps that can run flawlessly once deployed. You need to code the application so that it gracefully recovers from error situations. But even the best written apps can fail unexpectedly. Instrumenting your error handlers with tracing or logging code gives you the ability to know what happened in the app during the error handling process.
When an unhandled error is detected, the logger writes out the information. Now you have a way to look at the error history of the application. Profilers are one type of performance instrumentation. They are used to determine how fast sections of your code run, which helps you find bottlenecks in the code base. Once you profile your code, you get additional benefits. For example, you can find out whether a section of your code was run during the last test run. This is known as code coverage testing.
Profilers can monitor single lines of code or you can set them up to monitor at the class or method level. Visual Studio includes a profiler. Just turn it on and it does the rest. You don't have to write any instrumentation code. The other type of performance instrumentation is application performance. This is used to get general application trends. For example, you might need to know about disk reads or how much CPU the app is consuming. An example of this is available in Windows Applications.
Windows understands a set of performance counters. There are dozens of these built-in counters, ones for checking memory use, ones for counting the active threads in your applications, and many more. If you want to tap into this system, you write code, register your app with the performance subsystem. Windows monitors all the perf counters and shows them in the Performance Monitor tool. I'd like to show you an example of a Windows performance counter. To do that, I'll use an application that I've already written.
It's here in this Exercise File folder in chapter one. I'll need to run this application as an adminstrator because my application makes some changes to the registry. So I'll right click and choose Run as administrator. Next, I'll doc it to the right side of my screen. Now this is a simple application. All it does is monitor my mouse movement and show the position of the mouse on the screen. Also, I've written a Windows performance counter and put it in my code.
And that notifies the Windows Performance Monitor that I have some information that it could watch. To see that information, I'll start Performance Monitor. And then I'll doc it to the left side of my screen and then I'll click here where it says Performance Monitor. Next, I wanna add the Performance Monitor that's inside my application. To do that, I'll click on this green plus sign here. This shows the thousands of performance counters that are available on my machine.
The one I'm looking for is named DebugEssentialTraining. There it is. This is the category that I created in my application and I created one performance counter called Mouse moves / sec. So I'll click on this and then click on Add. And then click on OK. So now I have two performance counters. I have the % Processor being used and the Mouse moves / second. It's hard to see the difference because they're both drawing in red so I'll right click on this and choose Properties.
Then select a new color. And then click OK. Now what'll happen is as I move my mouse over my main window, you'll see the performance counter start registering in this window here. Now the counter is checking the number of times I move my mouse per second. So if I sit here idle and not do anything, it's zero. If I move it slowly, you'll see there's a small spike in the performance. And if I move it rapidly, you'll see there's a large spike.
Now there's other things I can do. I can change the scale. And come over here and choose Properties. Maybe make this a one tenths scale. Coming in off the left side of the screen, now you see that it doesn't peak at the very top of the window. Also, I can look at the performance counter in different ways. I can choose this drop-down and choose a bar graph. Or, I can choose the drop-drown and choose Report where I just get a text based information.
So that shows you how performance counters let you monitor application statistics after you've created the application, compiled it, and delivered it to your users. Now that I've discussed the key debugging phrases, let me share which topics I'll cover in the rest of this course. I'l give a complete tour of the Visual Studio debugging tools and debugging windows. I'll also cover some of the code profiling features. Most of the instrumentation topics, I will not discuss. You can use these feautures.
They are part of .NET and Windows RT so you can use them in your applications but they are not really Visual Studio topics. That means I won't be covering tracing, logging, or application performance. Next up, in the next video, I'll look at common debug scenarios.
- Understanding the debugging vocabulary
- Understanding the defect categories
- Stepping through code
- Working with DataTips and visualizers
- Traversing the call stack
- Attaching debuggers to running processes
- Using the Just-in-Time debugger