Tutorials VB.NET 2005 Debugging Windows Applications In Visual Studio.NET 2005 Debugging Windows Applications In Visual Studio.NET 2005 - Page 2 Debugging Windows Applications In Visual Studio.NET 2005 - Page 3In this tutorial you will learn how to Debug a Windows Application, Step through Program Execution, Stop Debugging or Stop Execution, Stepping Through Code, Setting BreakPoints, Analyzing Program State to Resolve Errors, Debugging on Errors, Exception Assistant, Debugging a Running Process, Debugging the Code in DLL files and Debugging a Remote Process.
To debug a .NET Framework application, the compiler and runtime environment must be configured to enable a debugger to attach to the application and to produce both symbols and line maps, if possible, for the application and its corresponding Microsoft Intermediate Language (MSIL). Once a managed application is debugged, it can be profiled to boost performance. Profiling evaluates and describes the lines of source code that generate the most frequently executed code, and how much time it takes to execute them.
The .NET Framework applications are easily debugged using Visual Studio, which handles many of the configuration details. If Visual Studio is not installed, you can examine and improve the performance of .NET Framework applications in several alternative ways using the following:
The .NET Framework namespace System.Diagnostics includes the Trace and Debug classes for tracing execution flow, and the Process, EventLog, and PerformanceCounter classes for profiling code. The Cordbg.exe command-line debugger can be used to debug managed code from the command-line interpreter. DbgCLR.exe is a debugger with the familiar Windows interface for debugging managed code. It is located in the Microsoft.NET/FrameworkSDK/GuiDebug folder.
The Visual Studio debugger provides powerful commands for controlling the execution of the application.
Starting execution is one of the most basic debugging functions.
To start debugging
1. From the Debug menu, choose Start,Step Into, or Step Over.
-or-
2. In a source window, right-click on a line of executable code and choose Run to Cursor from the shortcut menu.
If you choose Start, the application starts up and runs until it reaches a breakpoint. The execution can be broken up at any time to examine values, modify variables, and otherwise examine the state of the program. For
If Step Into or Step Over are chosen, the application starts and executes then breaks on the first line.
If Run to Cursor is selected, the application starts and runs until it reaches a breakpoint or the cursor location, whichever comes first. The cursor location can be set in a source window. In some cases, a break does not occur. This means that execution never reached the code where the cursor is set.
The solution may contain more than one project. In that case, the startup project can be selected for launching using the Debug menu execution commands. Alternately, selected project can be started from Solution Explorer.
The Start can be used without debugging command (on the Debug menu) to start execution of a project without the debugger. Please note that the ability to debug may be limited by whether the code was built with debug information, whether the debugger has access to the source code, and whether the common language runtime JIT compiler is tracking debug information. If the Visual Studio debugger does not find debug information for the program, it usually reports "no matching symbolic information found". In some cases it omits the message and treats a Start command as "Start without debugging". Debug information is generated by default when the debug configuration of your program is built. If the debugger cannot find symbols, a symbol path will be specified. To aid in debugging system calls, install system debug symbols.
One of the most common debugging procedures is stepping — executing code one line at a time.
Stopping debugging means terminating the debugging session. Stopping execution means terminating the process being debugged and ending the debugging session. It should not be confused with breaking execution, which temporarily halts execution of the process being debugged but leaves the debugging session active.
Stop Debugging terminates the process being debugged if the program was launched from Visual Studio. If the process is attached, instead of launching it from Visual Studio, the process continues running. If attached processes are to be terminated, a single process can be terminated from the Processes window or all attached process can be terminated with the Terminate All command.
If the current run is to be stopped and a new run began, the Restart command has to be used.
Restart stops the current debugging session and restarts the startup project.
Debugging will stop automatically if the application being debugged is exited. (If multiple programs are being debugged, the debugging will continue until the last program is exited.) If a project hosted by another application is being debugged, such as a web project hosted by Internet Explorer, debugging stops if the host application is exited(such as Microsoft Internet Explorer).
In Visual Basic and C#, if you are debugging a Web service and the client application that uses that service is terminated, debugging of the Web service stops.
When an application with the Visual Studio debugger is being debugged, the application is either running (executing) or it is in break mode. Most debugger features, such as evaluating expressions in the Watch window, are available only in break mode.
The debugger breaks execution of the program when execution reaches a breakpoint or when an exception occurs. The execution can be broken manually at any time. If the break is set while executing code without corresponding source, the user will be able to debug in the Disassembly window.
The debugger stops execution of all programs running under the debugger. The programs do not exit and execution can be resumed at any time. The debugger and your application are now in break mode.
If multiple programs are being debugged, a breakpoint or Break All command affects all programs being debugged by default. This can be changed by default if only the current program is to be broken.
Stepping Through Code
The Debug menu provides three commands for stepping through code:
Step Into and Step Over differ in only one respect — the way they handle function calls. Either command instructs the debugger to execute the next line of code. If the line contains a function call, Step Into executes only the call itself, then halts at the first line of code inside the function. Step Over executes the entire function, then, halts at the first line outside the function. Use Step Into if you want to look inside the function call. Use Step Over if stepping into functions are to be avoided.
On a nested function call, Step Into steps into the most deeply nested function. If Step Into is to be used on a call like Func1(Func2()), the debugger steps into the function Func2.
In native code, if a specific nested function is to be stepped into, use the Step Into Specific command from the shortcut menu. (If managed code is being debugged, this command is disabled.)
Use Step Out inside a function call and return to the calling function. Step Out resumes execution of the code until the function returns, then breaks at the return point in the calling function.
Breakpoints are still a great way to stop the execution of the program at predefined points in the code. Applying the breakpoints is an easy task. Simply open a section of code and click on the far left of the design window in the gray area, as in the example below.
Right-click over the breakpoint indicator to display a menu of additional options.
Outlining is a tool for organizing code into a more readable format. Highlight a portion of code, then right-click and select the Outlining submenu. Hide Selection will collapse the marked selection of code and put an indicator (+ . . .) to be used to expand it again as needed. Also the hidden code can be quickly viewed without expanding by simply performing a mouse-over of the collapsed code indicator.
The Breakpoints window is a practical dialog that will display all of the marked breakpoints and certain settings associated with each. To open this window, select the Debug menu, Windows then Breakpoints, or press CTRL+ALT+B. The window contains a toolbar and a list of breakpoints:
Next Page: Debugging Windows Applications In Visual Studio.NET 2005 - Page 2
