Shown figure the call the top the stack the current call

Using the Watch Window

Using the Call Stack Window

The Call Stack window answers the question of how the application got to the current point of exe-cution. Every time the application makes a call, CLR adds the call to the call stack. When the call returns, CLR removes it from the call stack. In short, the Call Stack window shows you a list of pend-ing calls, which tells you how the application accessed the current function, as shown in Figure 17.19.

The entry begins by telling you the name of the DLL, hpvr_og5.dll. You won’t recognize the name of this DLL because Visual Web Developer generates it for you when you compile the applica-tion. The Default_aspx Web page appears within the DLL, which contains the btnVisit_Click() method. This method requires two input arguments. Notice that the call stack tells you the input argument type, name, and default value. For example, sender is an object type that has a default Text property value of Call Methods. The entry ends with the location of the btnVisit_Click() method within the source file and the number of bytes that this method requires.

Sometimes it’s not enough to look at the Call Stack window. Fortunately, double-clicking an entry takes you to that method within the source code. Viewing the code doesn’t alter the call stack, nor does it change the order of execution, but it does help you understand the program flow better.

Managing Breakpoints

Knowing how to use the windows isn’t helpful until you know how to stop the application at precise points of execution. One way to stop application execution is to click Break All on the Debug toolbar shown in Figure 17.8. However, this method isn’t very precise. Breakpoints address the need for preci-sion. Whenever your application is running in debug mode and it encounters a breakpoint, the debug-ger stops the application so you can examine the values and single step through the order of execution.