Every now and then we get a question about debugging managed code with Visual Studio. It is a little confusing so I thought I'd shed some light on it in this post. A canonical example to use here is where you have a web server on some remote machine running ASP.NET code. Something goes wrong on it and you want to debug it.

To debug using Visual Studio 2003, you need to put remote debugging components on the web server. Insert the main VS disc and on the screen that says 1,2,3- at the bottom is a link for remote component install. Click that and install the managed remote debugging components.

Now when you go to attach to the aspnet_wp.exe process on the remote machine to managed debug it, there are two things that need to happen before you can do so.

The first: Visual Studio uses a service to do debugging called the MDM or Machine Debug Manager. This is one of the components installed by the remote debugging components. This is needed only by Visual Studio - so if you have the framework on your machine, or cordbg you this doesnt apply. The MDM is the first gatekeeper - only two people are allowed to talk to it. Admins on the machine + members of the Debugger Users group (a group created on the machine when the mdm installs). The Debugger Users group is often misunderstood. It serves one function only - its members are allowed access to the MDM. It gives no other permission or privelige to you.

So lets say you add yourself to the Debugger users group and you are'nt an admin on the machine. Now comes the second test - the runtime rule for managed debugging. The rule is simple - if the managed process is running as you, or you are an admin on the machine, you can managed debug it. So now the debugger tries to attached to aspnet_wp.exe (which almost always runs as ASPNET user). You are'nt an admin so that check fails. You arent ASPNET so that check fails too and you cant attach. The trick is to get Admin on the machine, or change the config file for aspnet_wp.exe to run as you. Both have security implications so be careful when you do this.

I hope that helps you better understand what it takes to managed debug an application. For other remote ASP.NET debugging pains, Min keeps an excellent troubleshooting document at http://weblogs.asp.net/mkpark/articles/86872.aspx