Focus on Microsoft Technologies - Tutorials, Articles, Code Samples.

Thursday, September 21, 2006

Debugging remotely and locally in

Source :


Bugs are a fact of the programmer's life. This is the second of two articles examining how we may deal with them efficiently within .NET. In part I we looked at the process of collecting information about a programs execution (tracing). Tracing is really a part of the overall activity of debugging: finding and fixing errors in your program. In part II of this series we'll focus on debugging and in particular on the tools available to the programmer to simplify the task.


Debugging is the process of finding and fixing errors in your application. Without good tools this process can be time consuming. VS.NET comes with a large toolset in this area that we shall consider in this article. I should also point out at this point that the .NET framework ships with a GUI debugger located in \Program Files\Microsoft.NET\FrameworkSDK\GuiDebug\DbgCLR.exe which is rather similar to the VS.NET tool so all is not lost if you do not have a copy of VS.NET. Thus much of what is presented below applies equally to DbgCLR.exe though some of the interface detail may differ slightly. The VS.NET debugger does offer additional features however, as well as offering the advantage of being integrated with the rest of the IDE toolset.

Firstly we should differentiate between two types of errors:

  1. Compile time errors: these are largely syntactic errors which will be captured by the compiler. Note, that use of Option Explicit and Option Strict can reduce the likelihood of runtime errors via compile time identification of likely issues. See my article on Error Handling in ASP.NET for more information.
  2. Runtime errors: these are bugs – programs that compile successfully but do not behave as expected.

In part I of this article we have already come across setting of the configuration mode of the application in VS.NET and the ability to differentiate between Release and Debug modes, the latter being the default.

Debug mode may be set explicitly within the web.config file via the compilation element as follows:

<compilation debug="true" />

as well as at the Page level via the debug attribute of the Page directive.

Setting Breakpoints and Stepping Through Program Execution

Stepping is the step-by-step execution of a program. This allows the developer to track the logic of the program execution to see where it might be going wrong. As part of this facility you are able to monitor the state of application objects (e.g. variables, database table values, etc.) before and after each step to check whether the program is correctly affecting them.

The steps of the stepping process are definable by the developer. The debug menu of VS.NET provides three options for step execution:

Step Into: executes the code in step mode – if a method call is encountered the program execution steps into the code in step mode.

Step Over: will not execute the next method call in step mode, continuing to the next statement after the method call.

Step Out: if already in a method call will continue through the rest of the method without stepping, returning to step mode when control returns to the calling statement.

Debugging on exceptions

You can also control the way the VS.NET debugger behaves when it encounters a line of code that throws an exception. This is achieved via the Exceptions dialog box (Debug-Exceptions). This allows specification of the debugger's behaviour for each type of exception defined in the system, including programmer defined exceptions if you so desire. Behaviour is controllable on two levels:

  1. when the exception is thrown
  2. if the exception is not handled

Debugging a running process

Up until this point we have assumed that the application we are running is doing so within the VS.NET environment by starting them within this environment. VS.NET also allows you to debug processes running outside the debugging environment – handy for debugging already deployed applications, e.g. applications in staging environments. This kind of thing often proved problematic with previous versions of VS.

When a web page is served from the web server, the ASP.NET worker process (aspnet_wp.exe) serves the request. To debug a running page you need to attach the VS.NET debugger to the aspnet_wp.exe process running on the web server. Additionally, you need to open the corresponding source files in VS.NET and set your breakpoint at a suitable location. Now when you interact with the already running web page it will break into the debugger whenever the break point is hit.

The actual steps needed to achieve the above are:

  1. Launch the page in Internet Explorer.
  2. VS.NET Tools – Debug Processes. Change the name field to point to the web server specified in 1, making sure you check the 'Show system processes' option. In the available processes list you want to attach to aspnet_wp.exe. Selecting attach will bring up an 'attach to process' dialog box – select the CLR option and click OK.
  3. Open the corresponding source file in VS.NET.

A couple of important points:

  1. Don't debug on production servers – attaching a debugger to an aspnet_wp.exe on a production server will freeze the execution of all other applications / user application instances on that server.
  2. Similarly don't terminate the aspnet_wp.exe process after debugging is complete as it will affect all other applications / users on that server.

Debugging a remote process

This is similar to debugging a running process. The difference is you are effectively debugging on the remote machine. The extra step required is that prior to when selecting a running process from the Processes dialog box you must select the remote machine name from the name list.

Further, before you can debug remotely you must perform a one time configuration of the remote machine where the processes are running achievable via either installing VS.NET on the remote machine or installing the remote components setup on the remote machine (VS.NET setup disk 1).

This will ensure that the machine debug manager (mdm.exe) is on the remote computer. This runs as a background service providing debugging support. The logged in user at time of installation will also be added to the Debug users group – a further requirement for this to work. This process will also configure SQLServer for Stored Procedure debugging if SQLServer exists on the server.

For further information see 'setting up remote debugging' in VS.NET help

Debugging Code in DLL Files

The process of debugging a DLL file for which you have the source code is similar to debugging a web form with one main difference: the code in a DLL cannot be called directly so you need a client (web form) to call it. This makes the typical process as follows:

  1. Launch the web form that uses the members of the DLL.
  2. Launch VS.NET and attach the debugger to the web form. Set a breakpoint where the method in the DLL file is called. Continue with execution.
  3. Execution will break at the breakpoint and you can step into the DLL code from the Debug menu.

Debugging Client-side Scripts

Again this works similarly to web forms with the proviso that client-side debugging only works with IE. You have to enable script debugging in IE (Tools-Internet Options-Advanced and uncheck Disable script debugging in the browsing section).

You can then attach the debugger to the iexplore.exe process displaying the web form. This is only required if you are debugging an already running process. When attaching to the process in the Attach to Process dialog box you must make sure you select the script option.

Debugging SQLServer Stored Procedures

You can even perform debugging of stored procedures in the VS.NET environment and here is a brief overview of how to achieve this:

You need to enable SQLServer debugging for your solution. The option for this is located via Solution-Properties – Configuration properties – Debugging. I'll assume you have a project that uses stored procedures as the interface between data store and web form already. Set a breakpoint in your web form code before you call the stored procedure. In Server Explorer navigate to the stored procedure in question, right click and select edit. Insert a breakpoint in the first line of code.

Run the project; execution will break at the breakpoint in the web form. Select 'step into' until the stored procedure is called and you will be able to step through the stored procedure code as well. Investigate how you can still use the watch and locals windows to examine variables.

This ability is a boon to developers needing to debug complex stored procedures.

Post a Comment