1. Introduction

In this article, we will see various debugging windows and its use. You can download the example at the bottom of this article. The example will perform the summation of the prime numbers. We will explore various debugging windows using this sample application. You can read the debugging basics before learning the debugging windows. The below picture shows the sample:

2. Call Stack Window

The Call Stack Debugging Window helps to see the order in which function calls occurred from the application start-up to the place where you hit the Breakpoint. Before we explore more about it, we will follow the steps below to bring this window.

1. Open the Attached application and put a break-point in the function ‘ IsPrime’ as shown below.
   

   Breakpoint location in code window

2. Run the sample application and enter the input as 24 then press the button Get Prime Sum. This will get us to the break-point.
3. Now we bring the Call Stack Debugging Window by navigating menus in the order Debug, Windows, Call Stack. The below picture shows the Call Stack Window.

   

   1. 1. 1. Call-Stack

         Window

In the above Call Stack window, the first line in the top shows that the application is paused in the function ‘

IsPrime

’ which takes an input parameter ‘

theNumber

’. The value stored in it is 3.

Now, look at the second line. The function ‘

SumIfPrime

’ receives the parameter ‘

theNumber

’ with value 24 from the function ‘

btnGetResult_Click

’. From this Call Stack Window we know the function ‘

SumIfPrime

’ calls ‘

IsPrime

’ where we kept the Breakpoint to halt the application for debugging. We can also note the call stack is program entry point

Main()

stays in the bottom of the Call-Stack.

One can move to the function shown in the call stack by double clicking an entry in the Call Stack Window. It will be useful when you are working on a big project where function call can happen between different DLLs.

Youtube: Call Stack Window

3. Debugging Windows – Autos & Locals

Before exploring about these debugging windows, we will add a function to learn the difference between Autos and Locals Debugging Windows. The function added to the form is shown below:

We call this function from the the constructor:

Now we will put a Breakpoint on the function in the statement

b=20

and run the sample with the input number 24. Once the Breakpoint is hit, open the “Autos and Locals Debugging Windows”. You can reach these windows by navigating Debug=>Windows. If it is not available, bring it from the tools=>customize option. The below picture shows the Autos Debugging Window:

The Breakpoint is at

b=20

, and Autos Window displays the variable that changed or involved in the previous statement. Also, it shows variables that involved in the execution of the current statement. This why we see variable

a

and

b

in the window. The Autos Debugging Window shows the changed variable value in red color. Note, we do not recognize this in the above picture because of the highlight of the row. Now, one can step over the statement to move the control to the next statement

c=30

and see how the Autos window changes.

The Locals Debugging Window shows the variables local to the current execution block’s scope. Here, in our case, if the execution point is at

d=40

for example, the Locals Window shows all the variables involved in between the curly braces. Below is screen-shot of the Locals Window:

Youtube: Auto and local debugging windows

4. The Output Debugging Window

We can display any diagnostic message to the Output Debugging Window from our source code. The

System.Diagnostic.Debug

name-space offers a utility methods which we can use to push messages to output window. These messages are useful when we are debugging the loops. Write the following piece of code (Line 10,11) in the function ‘

SumIfPrime

’ as shown below:

Now, the above code will write the string specified in the Output Window. Just, imagine how do you write something on the Console Output Window. We can do it in the same way. Remove all the breakpoints and run the sample with the input 24 again and look at the Output Debugging Window. Before we click the button on the form, we have to right-click the Output Window and have to select clear all from the context menu. This will help us see what we wrote to the Output Window. If Output Window is not displayed, one can bring it from Debug=>Windows or from the customize option. The below picture shows the Output Debugging Window content after running the application:

Youtube: Output Debugging Window

5. Immediate Debugging Window

The Immediate Debugging Window allows examining the variables. It can also compute the expressions on the fly. Put a break-point in the statement

e=50

in the ‘

autolocals

’ function. Run the sample with the input value of 24. Once the break-point hit, bring up the Immediate Window.

Now write the following in the immediate window and hit enter:
?c

The above command retrieves the value of c and displays it on the next line. One may think, I can hover my mouse on the variable c to see what value it has and what makes an immediate window something special. To know the real use, type the following and hit enter and you can see how immediate window become useful.
?(aa) + (2ab) + (bb)
900
Most developers frame their string manipulation expression in the Immediate Window and that in their source code. The below screen shot shows immediate window in action:

Youtube: How to Use Immediate Window

6. Closing Notes

Note: The sample was created in VS2005. If you have the latest IDE, Say yes to the conversion UI displayed.

Source Code: Debugging Windows Example from Google Drive

• Fixed MFC SDI Window Using CREATESTRUCT & PreCreateWindow
• Change Windows System Menu Using MFC’s GetSystemMenu

Categories: C#

Tags: C# Autos Window, C# Debugging Output Window, C# Debugging Windows, C# Immediate Window, C# Locals Window

This site uses Akismet to reduce spam. Learn how your comment data is processed.