Article ID: 893657
Article Last Modified on 5/18/2007
APPLIES TO
- Microsoft ASP.NET 1.0
- Microsoft ASP.NET 1.1
ASP.NET Support Voice Column
Debugging ASP.NET with the CLR Debugger
To customize this column to your needs, we want to invite you to submit your ideas about topics that interest you and issues that you want to see addressed in future Knowledge Base articles and Support Voice columns. You can submit your ideas and feedback using the Ask For It form. There's also a link to the form at the bottom of this column.
Welcome back! I'm Jim Cheshire, a support engineer here at Microsoft supporting ASP.NET. I've shared several tips in the past few months and this month we are going to discuss debugging ASP.NET with the CLR debugger, and as always, send us your suggestions for future columns.
So please, pull up a chair, kick off your shoes, and read through our column all about debugging ASP.NET, and remember, you can submit your ideas to us using the "ASK FOR IT" link included in every column we publish.
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.
[GRAPHIC: Microsoft CLR Debugger in design mode]
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.
[GRAPHIC: CLR Debugger Hitting a Breakpoint]
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.
I've been working with Microsoft for six years on the FrontPage, VB, and ASP.NET teams. During that time, I have written for the Office Developer Center on MSDN, and am the author of a book on FrontPage, Special Edition Using Microsoft Office FrontPage 2003. I also have a Web site where I provide free add-ins for FrontPage to enable Web developers to make the most out of Microsoft products. Here is that Web site address:
As always, feel free to submit ideas on topics you want addressed in future columns or in the Knowledge Base using the Ask For It form.
Jim Cheshire
Support Engineer
Microsoft Developer Support
Keywords: kbgraphxlink kbhowto kbasp KB893657
![[GRAPHIC: Microsoft CLR Debugger in design mode]](/wiki/index.php?title=Special:Upload&wpDestFile=890327a.gif){kind=link}
![[GRAPHIC: CLR Debugger Hitting a Breakpoint]](/wiki/index.php?title=Special:Upload&wpDestFile=890327b.gif){kind=link}