ASP.NET Debugging Overview
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.
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 <PAVEOVER> 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 <PAVEOVER> 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.
Note
The Edit and Continue feature of Visual Studio 2005 is not available for Web applications.
For more information, see Using the Debugger with Web Pages.
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.
Note
An application compiled into a debug build will perform considerably more slowly than if it is compiled into a retail build. Be sure you have debug mode turned off before you deploy your application. Additionally, in debug mode, more information is exposed in the stack when an error occurs and can be a potential security issue.
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 Set Up the Remote Tools on the Device.
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.
See Also
Tasks
How to: Enable Debugging for ASP.NET Applications
How to: Debug Web Applications
Reference
What’s New for the Debugger in Visual Studio 2013
Prerequistes for Remote Debugging Web Applications