VS 2003 Tip #14: What are the requirements to debug a managed application?


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

Comments (5)

  1. Ricky Dhatt says:

    How can you install the remote debugging components on a remote machine? The web server I’m working is on the other side of the country.

  2. Shaykat says:

    Hi Ricky – there are a couple of ways:

    a. Have someone insert the CD on the remote machine and install.

    b. Put the .NET Fwk on the machine. It should put a subset of the components, but enough to managed debug. In fact if you term serv to the machine, you can use DbgCLR as the managed debugger there.

    c. Lastly, the remote setup is an MSI that is referred to on the page when you click on the link for remote components on the 1,2,3 screen. If you can copy this Msi to the remote machine and run it with the commands given on the page, you should be ok.

    Hope that helps.

  3. Jacque says:

    How do I remove Remote Debugger? I am having problems and get the message "Error while trying to run project: Unable to start debugging on the Web server. You do not have permission to debut the application. The URL for this project is in the internet zone."

    I accidently installed Remote Debugger and I think that it is causing part of the problem.

    Thanks for any help,

    Jacque

  4. Dave Vespa says:

    Shaykat,

    Are there any plans to allow Remote Debugging when the user is just a member of the Debug Users group and while the process is still executing as ASPNET?

    Dave