The Microsoft .

NET Framework SDK Debugger

No matter how skilled a programmer you are, you are bound to make mistakes
once in a while. Tracking down problems in your code can be baffling without the
appropriate tool. Fortunately, the compiled nature of ASP.NET means that
debugging Web applications is no different than debugging any other managed
applications, and the .NET Framework SDK includes a lightweight debugger that
is perfectly suited for this task.

This section describes the steps required to debug ASP.NET Framework

applications using the debugger provided in this SDK. The debugger supports
manual-attach debugging of processes on a local development computer. The
debugger documentation included in this SDK is your best resource for
information about specific features.

Enabling Debug Mode for ASP.NET Applications

Because many parts of an ASP.NET Framework application are dynamically

compiled at runtime (.aspx and .asmx files, for example), you must configure
the ASP.NET runtime to compile the application with symbolic information before
the application can be debugged. Symbols (.pdb files) tell the debugger how to
find the original source files for a binary, and how to map breakpoints in code to
lines in those source files. To configure an application to compile with symbols,
include a debug attribute on the compilation section within the system.web
group of the Web.config file at the application's root directory, as follows:
<configuration>
<compilation debug="true"/>
</configuration>
Important: You should only enable this setting when you are debugging an
application, because it can significantly affect application performance.

Debugging ASP.NET Applications

When you have enabled debugging for the application, you should issue a
request to the page you want to debug. This ensures that the ASP.NET runtime
process (Aspnet_wp.exe) is created and the application is loaded into memory.

To begin debugging:

1. Launch the .NET Framework debugger, DbgClr.exe.

2. Use the File...Miscellaneous Files...Open File menu to open the
source file for the page you want to debug.
3. From the Tools menu, choose Debug Processes. The screen in the
figure following these instructions will appear.
4. Check the Show system processes checkbox, if it is not checked.
5. Find the Aspnet_wp.exe process and double-click it to bring up the
Attach to Process dialog.
6. Make sure your application appears in the list of running
applications, and select OK to attach.
7. Close the Programs dialog.
Important: When you attach to the Aspnet_wp.exe process, all threads in that
process are frozen. Under no circumstances should you attempt to debug a live
production application, because client requests can not execute normally until
the debugger is detached.

Setting Breakpoints

To set a breakpoint in your page, click the left-hand margin on a line containing
an executable statement or function/method signature. A red dot appears where
the breakpoint is set. Move the mouse over the breakpoint to ensure that it is
appropriately mapped to the correct application instance in the Aspnet_wp.exe
process.

Reissue the request to the page from your browser. The debugger will stop at
the breakpoint and gain the current window focus. From this point, you can
step, set variable watches, view locals, stack information, disassembly, and so
on. You can see the intrinsic objects on the page, like Request, Response, and
Session by using this (C#) or Me (VB) in the watch window.

Section Summary

1. The debugger described in this section supports manual-attach

debugging of processes on a local development computer.
2. Debugging allows the ASP.NET runtime to dynamically compile with
symbolic information. Enable this by setting <compilation
debug="true"/> in the Web.config file located in the application's root
directory. The debugger setting should only be enabled when you are
debugging an application, because it degrades application performance.
3. To debug an application, issue a request to a page, attach the
debugger to the Aspnet_wp.exe process, set breakpoints, and reissue the
page request.
4. When attached to the Aspnet_wp.exe process, all threads in that
process are frozen. Under no circumstances should you debug a live
production application, since client requests can not execute normally
until the debugger is detached.
5. To debug pre-compiled components, such as business objects or
code-behind files, you must compile with symbolic information prior to
debugging.