Select the product you need help with

Recap of debugging permissions in ASP.NET

Article ID: 893658 - View products that this article applies to.

ASP.NET Support Voice column

Recap of debugging permissions in ASP.NET

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 by using the Ask For It
(http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p2=&p3=&p4=)
form. There's also a link to the form at the bottom of this column.

Expand all | Collapse all

Welcome back! This is Mike Clay again with the Microsoft ASP.NET Developer Support team. I have authored Support Voice columns in the past. This month, I want to wrap up some of the previous debugging topics I covered and touch on a few issues that we still see pretty frequently in PSS. I wanted to discuss the basic configuration and permissions required for debugging in Visual Studio .NET and provide a few more helpful resources that can be difficult to find. We have lots of debugging information and documents available, which can be a bit overwhelming sometimes, especially if you are new to ASP.NET debugging. I thought it would be helpful to put the core debugging requirements in one place and let this be a starting point for common errors that developers frequently run into. The purpose here is not to go into too much detail, but simply to provide developers with a quick checklist before you try to debug ASP.NET applications.

Back to the top | Give Feedback

Recap of debugging permissions in ASP.NET

Let me first mention that for all scenarios discussed below, I am referring to automatic debugging. Automatic debugging is when you either push the blue Start button or press the F5 key in Visual Studio .NET. This automatically attaches to the aspnet_wp.exe or w3wp.exe worker process for you. Manual debugging is when you manually attach to the appropriate process through the Debug menu. With either method, there are some key concepts to keep in mind. For more information manual debugging, click the following article number to view the article in the Microsoft Knowledge Base:

817034

(http://support.microsoft.com/kb/817034/ )

PRB: "Unable to start debugging on the Web server" error message while you debug ASP.NET applications

Local or remote debugging?

This is very important in terms of the debugging configuration because local debugging has fewer requirements than remote debugging. Usually, local debugging in Visual Studio .NET works right out the box, assuming the developer is a local administrator.

Permissions

As mentioned before, not much configuration is required for local debugging. However, remote debugging has the following main requirements:

The Remote Components are installed on the Web server. The Remote Components are installed from the Visual Studio .NET Setup disks.
The client workstation and the remote Web server must be in the same domain.
Integrated Windows Authentication must be enabled in IIS.
The debugging user must be in the Administrators group on the server OR the debugging user must “own” the process and be in the Debugger Users group or the Administrators group. When I say “own” the process, this means that the identity of the ASP.NET worker process must be the same as the debugging user’s credentials. This is done with the <processIdentity> section of the machine.config in Windows XP and in Windows 2000 or with the AppPool identity in Windows Server 2003. Also, this is the only way to let a developer perform remote debugging without having administrative credentials on the remote Web server. The following KB article explains this as well. This particular article states the minimum permissions for debugging in Visual Studio .NET. However, this article is often overlooked when trying to troubleshoot debugging problems.
329282
(http://support.microsoft.com/kb/329282/ )
Minimum permissions for debugging applications in Visual Studio .NET

Keep in mind that prior to IIS 6.0, only one user could debug at a time. Once a user has attached to the aspnet_wp.exe process and a debugging session has been initiated, that worker process cannot serve any other request until the debugging session has ended. Multi-user debugging is only possible with IIS 6.0. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

817265

(http://support.microsoft.com/kb/817265/ )

How to set up multiple user debugging in Internet Information Services

Troubleshooting

Once you have the correct configuration and minimum permissions in place, there are still some common errors you can run into. We have touched on troubleshooting steps and resources in the following Support Voice column:

891027

(http://support.microsoft.com/kb/891027/ )

Finding answers to ASP.NET debugging issues

Back to the top | Give Feedback

I hope you found this information helpful in easing some of the initial confusion involved with ASP.NET debugging. Remember, the Support Voice columns are for the YOU! As always, feel free to submit ideas about topics that you want addressed in future columns or in the Knowledge Base by using the Ask For It

(http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p2=&p3=&p4=)

form.

Back to the top | Give Feedback