Chapter 12: Debugging with Visual Studio 2005
Chapter 12: Debugging with Visual Studio 2005
Overview
Microsoft Visual Studio is a popular development environment that has an effective debugger to help developers quickly diagnose and correct application problems. The Visual Studio debugger is a multipurpose tool that includes an assortment of tools, features, and windows to help developers quickly ascertain and correct problems. Use the Visual Studio debugger to inspect the values of variables, view the call stack, determine thread status, dump memory, set various types of breakpoints, and much more. Visual Studio 2005 introduces new features such as visualizers, tracepoints, crash dumps (opening directly), and the Exception Assistant. One benefit of the Visual Studio debugger is the familiar user interface. Developers experienced with the Visual Studio environment should be comfortable with the look and feel of the debugger.
Visual Studio debugging is extensible. Developers can customize many aspects of the debugger, including extending many of the types related to debugging. For example, developers can create user-defined visualizers and trace listeners. Visual Studio debugging is adaptable to specific problems, objectives, and goals.
In a debugging session, developers control how an application executes. A developer can start, interrupt, or stop a debugging session. These are the controls explained in Table 12-1.
|
Control |
Description |
|---|---|
|
Start Execution |
From the Debug menu, there are various commands to start a debugging session. If you use the Start Debugging, Step Into, or Step Over menu command, the application is in running mode. Alternatively, the Start Without Debugging menu command starts an application without attaching the Visual Studio debugger. You can also start a debugging session with the Run To Cursor command. In the source editor, position the cursor on the target source code. Open the shortcut menu and select the Run To Cursor menu command. This command starts an application in debug mode, but breaks when a breakpoint or the cursor is reached. If neither occurs, the application runs uninterrupted. |
|
Break Execution |
You can break into an application running in a debug session, which is most commonly accomplished by setting breakpoints. Developers can forcibly break into an application using the Break All menu command from the Debug menu. The command interrupts all applications currently being debugged by the Visual Studio debugger. After breaking into the application, the user is transferred to the source code being executed when the break occurred. If source code is not available, the user is transferred to the disassembly. When execution is interrupted, the application is in break mode. |
|
Stop Execution |
Developers can choose to end a debugging session. From the Debug menu, select the Stop Debugging command to end a debugging session. You can terminate an attached process in the Processes window. In that window, select the process and choose the Terminate Process menu command from the context menu. A debug session can be stopped and restarted again. On the Debug menu, the Restart menu command restarts a debugging session. |
Applications in a debugging session are either in a running mode or a break mode. In running mode, an application is executing. In break mode, an application is interrupted, which is when a developer commonly diagnoses an application. Certain features are applicable only in break mode, such as the Threads and Call Stack windows. While debugging, an application can transition between running and break modes. The following actions can transfer an application from running to break mode:
-
A breakpoint is hit.
-
A tracepoint is hit.
-
The cursor is hit with a Run To Cursor command.
-
The Break All command is executed.
-
An unhandled exception is raised.
-
Stepping through an application.
You can transition from break mode to running mode by starting execution again, which is defined in Table 12-1.
