Debugging ASP.NET with the CLR Debugger
During the Troubleshooting ASP.NET series, I have done over quite a few different troubleshooting techniques using different tools. By now, you should have noticed a pattern; these techniques have all involved troubleshooting an ASP.NET application in a production environment. Why is that? Most ASP.NET developers will catch pervasive problems during the development or testing phase. The really nasty problems typically rear their head after an application has been moved to production. You can thank Murphy for that!
Last time, I showed you how to use Windbg and the SOS extension to debug a crash in the ASP.NET worker process. That�s a valuable skill to have, but let�s face it; oftentimes you just need to debug an application in a more user-friendly environment. In those cases, Visual Studio .NET is an excellent choice, assuming you are able to remotely debug or install it on the server. In cases where those are not viable options, you can still have all of the convenience and familiarity of Visual Studio .NET without the overhead by using the CLR Debugger.
The CLR Debugger is a debugger that comes with the .NET Framework SDK. You can download the SDK from the following Microsoft Web site:
If you�re used to debugging in Visual Studio .NET, the CLR Debugger will feel familiar to you.
After you�ve installed the .NET Framework SDK, you can find the CLR Debugger at the following location:
C:\Program Files\Microsoft.NET\SDK\v1.1\GuiDebug\DbgClr.exe
Debugging with the CLR Debugger is quite straightforward. However, in order for it to work, you will need to build your application in debug mode. You don�t need to have symbols available and you don�t need to have the Debug attribute in your web.config file set to
true. You will also need to install the CLR Debugger on the Web server. You cannot remotely debug with the CLR Debugger.
Once you�ve deployed an assembly built in debug mode, you�re ready to go. Here are the steps for debugging in detail.
- Make sure that the aspnet_wp.exe or w3wp.exe process is running.
When you debug using the CLR Debugger, you have to manually attach to the worker process. Therefore, you will need to make sure that the worker process is running before you can start debugging.
If you are not debugging the startup of your application, you can browse to the startup page of your application. Otherwise, you will need to browse to any ASP.NET page. If you�re running on IIS 6.0, you will need to browse to an ASP.NET page that is running inside of the same application pool as your application.
- Open your source files in the CLR Debugger.
If you are debugging more than one file, you will want to load all of the files that you are debugging. It�s important to note that these source files need not be on the Web server that is running your application.
- Attach to the ASP.NET worker process.
To attach to the worker process, select Processes from the Debug menu in the CLR Debugger. Select the worker process, and then click the Attach button. If you are debugging against IIS 6.0, you will need to check the Show system processes check box in order to see the w3wp.exe process.
After you�ve attached to the process, you can close the Processes dialog box.
- Set breakpoints.
To set your breakpoints, click in the margin in the code window, right-click the desired line, and click Insert Breakpoint, or click inside the desired line and press Ctrl-B. A red circle will appear in the margin on the line you�ve selected.
- Browse to your application.
The stage is now set to debug your application. Once you browse to your page, the breakpoints will be hit and you�ll have access to a host of powerful debugging tools.
The CLR Debugger offers many robust debugging features. In the image above, you can see that the CLR Debugger has stopped on a breakpoint. In this screenshot, you can see the disassembly, the locals, the source window, and the call stack. All of the other familiar debugging windows are also available.
The next time you have a need to debug an ASP.NET application and you�re not able to use Visual Studio .NET, consider trying the CLR Debugger.