New Document
ASP.NET Debugging Overview

Debugging allows the developers to watch how the code works in a step-by-step manner, how the values of the variables change, how the objects are created and destroyed etc.

Debugging a traditional ASP application generally involves placing Response.Write statements throughout your code to track variable values and execution paths. If you fail to remove debugging statements before you deploy your application, the statements are visible to users.


Application code can contain various types of errors, or bugs. Most syntax errors are caught during compilation. However, other types of errors require that you debug your code — that is, that you examine the code while it is running to validate that the execution path and data is as it should be.

This topic provides information about how to use the debugger in the Windows Software Development Kit (SDK) to help you find errors in ASP.NET Web pages.

ASP.NET makes Web application debugging much simpler to use. You can use tracing statements to debug your application in a way that is similar to using Response.Write statements. However, you can leave the tracing statements in your application, even after deployment.


Background

Application code can contain various types of errors, or bugs. Most syntax errors are caught during compilation. However, other types of errors require that you debug your code — that is, that you examine the code while it is running to validate that the execution path and data is as it should be. For more information, see Debugging, Tracing, and Profiling.

The Windows Software Development Kit (SDK) includes a tool called Visual Debugger that allows you to examine an application while it is running. This tool is located in %ProgramFiles%\Microsoft Visual Studio 8\SDK\v2.0\GuiDebug\DbgCLR.exe. Using the debugger, you can see exactly how your application is working by stepping through each statement as it executes and by viewing the data in each variable. To use Visual Debugger, open it and then attach it to the process that is running the pages of your ASP.NET application. In Internet Information Services (IIS) versions 5.0 and 5.1, and in IIS 6.0 running in IIS 5.0 application mode, the process to which you attach the debugger is the ASP.NET worker process (Aspnet_wp.exe). In IIS 6.0 running in worker process isolation mode, the process that you attach to is the thread pool process (W3wp.exe). When the debugger is attached to a process, you can view everything going on during that process, and the debugger maps the instructions being executed in the process back to your original code so that you can see each line of code being executed.


Visual Debugger

Visual Debugger allows you to examine code while it is running and includes features that help you debug applications, including the following:

Breakpoints Breakpoints are places in the code where the debugger will stop the application, allow you to view the current data state of the application, and then step through each line of code. For information, see Debugging Basics: Breakpoints.

Stepping Once you have stopped at a breakpoint, you can run the code line by line (known as stepping through the code). Visual Debugger includes a number of features to help you step through your code, such as iterators that allow you to specify how many times to step through a loop before stopping again. For more information, see Code Stepping Overview.

Data Viewing Visual Debugger gives you many different options for viewing and tracking data while the application is running. The debugger allows you to modify the data while the application is stopped in break mode and then continue to run the application with the modified data. For more information, see Viewing Data in the Debugger.


Configuring ASP.NET Web Applications for Debugging

To enable debugging for an ASP.NET Web application, you must configure the application to compile into a debug build. A debug build includes information that the debugger needs so that it can step through your code and display the contents of variables. You configure your Web application for debug builds in the Compilation section of your application's Web.config file. For more information, see compilation Element (ASP.NET Settings Schema). Alternatively, if you want to debug only single pages, you can add debug=true to the @ Page directive on the pages that you wish to debug. For more information, see How to: Enable Debugging for ASP.NET Applications.

Local and Remote Debugging


If you are running a Web server locally, such as IIS, you can debug applications running locally on your computer so that you can view your pages in a browser.

If you cannot run a page locally, because you cannot run a Web server or because the application is not available to you locally, you can debug an application running on another server. In order to debug remotely, you must install the Visual Studio remote debugging components on the remote server. For more information, see How to: Set Up Remote Debugging.


Permissions for Debugging

Debugging a process requires more privileges than running it. Therefore, in addition to configuring your application for debugging, you must also ensure that you have adequate permissions to attach to a process in order to debug it. Users have the permission to debug processes running under their own user local identity, but they cannot debug other user's processes. Administrators can debug any process.

To debug on a remote server, you need administrator privileges on the computer where the process to be debugged runs. For more information, see Prerequistes for Remote Debugging Web Applications.


Client-Side Script Debugging

In addition to server-side application debugging, Visual Debugger allows you to debug client script written in ECMAScript (JavaScript) or VBScript. Client-script debugging can be especially useful when you have Web server controls that use client-side script.

You can configure the Web application to allow tracing at either the page level or the application level, and you can easily turn it on and off. You can also control the destination of the tracing output to allow only certain users to see the debugging output


When the site is run for the first time, Visual Studio displays a prompt asking whether it should be enabled for debugging:

Debugging Info

When debugging is enabled, the following lines of codes are shown in the web.config:

<system.web>
		<compilation debug="true">
		<assemblies>
		..............
		</assemblies>
		</compilation>	
</system.web>

The Debug toolbar provides all the tools available for debugging:

Debugging toolbar
Breakpoints:

Breakpoints specifies the runtime to run a specific line of code and then stop execution so that the code could be examined and perform various debugging jobs like, changing the value of the variables, step through the codes, moving in and out of functions and methods etc.

To set a breakpoint, right click on the code and choose insert break point. A red dot appears on the left margin and the line of code is highlighted:

Breaking Highlighted

Next when you run the code, you can observe the behavior of the code:

Breaking Highlighted2

At this stage, you can step through the code, observe the execution flow and examine the value of the variables, properties, objects etc.

You can modify the properties of the breakpoint from the Properties menu obtained by right clicking the breakpoint glyph:

Breaking Dropdown

The location dialog box shows the location of the file, line number and the character number of the selected code. The condition menu item allows you to enter a valid expression, which is evaluated when the program execution reaches the breakpoint:

Breaking Condition

The Hit Count menu item displays a dialog box that shows the number of times the break point has been executed.

Breaking Point

Clicking on any option presented by the drop down list will open an edit field where a target hit count is entered. This is particularly helpful in analyzing loop constructs in code.

Breaking Point2

The Filter menu item allows setting a filter for specifying machines, processes or threads or any combination, for which the breakpoint will be effective.

Breaking Filters

The When Hit menu item allows you to specify what to do when the break point is hit.

Breaking Point3
The Debug Windows:

Visual Studio provides the following debug windows – each of which shows some program information. The following table lists the windows:

Window Description
ImmediateDisplays variables and expressions.
Autos Displays all variables in the current and previous statements.
LocalsDisplays all variables in the current context.
Watch Displays up to four different sets of variables.
Call StackDisplays all methods in the call stack.
ThreadsDisplays and control threads.


Previous                                                                                                                                                       Next

Back to Top