Fixing ‘You do not have permissions to debug the server’ errors


First, some background. The way we start ASP.NET debugging is to send a special request to ASP.NET over HTTP/HTTPS. The verb for this request is ‘DEBUG’. If everything goes as planned, this allows VS to know what process to attach to.


Displaying error messages for this is really hard. We aren’t a web browser, so we can’t show you the HTML that the server might send back. We use WinInet, which is great for IE, but it has proved to be a huge pain for us. In Whidbey, we switched to the System.NET APIs instead.


Anyway, so the debugger will return ‘You do not have permissions to debug the server’ if we get an HTTP status code of 401 (Unauthorized).


The first problem with this error is that HTTP 401 has nothing to do with permissions, so the text is never right. What we should have said was — NTLM authentication isn’t working. Check IIS and IE settings, because it is probably disabled.


Some of the possible causes:



  1. If you mess with the ‘zone’ settings in IE, you can put the web site in the wrong zone. I have seen this happen when someone put the target site in the ‘Restricted sites’ zone.

  2. In Server 2003, there is the new ‘Internet Explorer Enhanced Security Configuration’, which sometimes causes NTLM to not work, even after the site has been added to the ‘trusted sites’ group. Try uninstalling this.

  3. You can disable NTLM in IIS. Open up IIS manager, go to ‘Directory Security’, and click ‘Edit’ under ‘Authentication and Access Control’. Make sure that ‘Integrated Windows Authentication’ is enabled.

  4. NTLM could just not be working between the machines. Make sure that you can open up a file share. You might also want to check the event log on the server.

Hope this helps.


 


Comments (10)

  1. Kiliman says:

    I wrote CassiniEx[1], an extended version of Cassini, to host multiple web applications. One of the things I wan’t able to figure out is how to get VS.NET to attach to CassiniEx when you select Debug | Start.

    I understand that you send the DEBUG verb, but what are the magic steps needed to get VS.NET to attach to my process.

    Currently, I have to manually attach using Debug | Processes…

    I tried creating a macro using DTE Process.Attach() method. Although it "works", it doesn’t allow me to specify that I only want to debug Managed Code (it includes Native Code… which takes a long time). Also, I can’t detach from the process. Ending the debug session kills the external process.

    Anyway, any hints or tips that will point me in the right directly would be greatly appreciated.

    Kiliman

    [1] CassiniEx http://www.systemex.net/CassiniEx/

  2. Gregg Miskelly says:

    The easiest way is to create a VC exe project. http://blogs.msdn.com/greggm/archive/2004/03/18/92491.aspx

  3. Kiliman says:

    Gregg, sorry I guess I wasn’t clear.

    I’m not trying to debug CassiniEx. I’m trying to debug a Web application hosted by CassiniEx.

    CassiniEx hosts the ASP.NET runtime just like Cassini (Web Matrix Server) and IIS ASPNET_WP.exe

    I’ve traced a debug session between VS.NET and IIS. When I press F5 in VS.NET, this is sent to IIS.

    DEBUG /Forums/default.aspx HTTP/1.1

    DebugSessionID=version=7.0;

    autoattachclsid=%7B70F65411-FE8C-4248-BCFF-701C8B2F4529%7D;

    session=%7BC76CC96B-74C0-4E58-815B-627EE02EC1B1%7D;

    EngineFilter=%7B449EC4CC-30D2-4032-9256-EE18EB41B62B%7D;

    StartPageUrl=x104x116x116x112x58x47x47x118x97x100…

    Besides the Integrated Windows authentication handshake, I’m not sure how IIS tells VS.NET how to attach to the worker process. The autoattachclsid refers to the Machine Debug Manager. I’m just trying to figure out the process that IIS uses to hook up with VS.NET so I can modify CassiniEx to support the same auto-attach functionality as IIS.

    Hopefully this clarifies what I’m trying to do.

    Kiliman

  4. Gregg Miskelly says:

    I would strongly recomend that you don’t try and process the debug verb. Take a look at the blog I had about using Cassini in VS7.1. The debug verb is used for IIS debugging because we don’t have hooks into IIS to get process creation notifications. Since you are writing the web server, you don’t have that problem.

    If you really want to process the debug verb, take a look at the ATL code atlisapi.h that uses IDebugAutoAttach.

  5. Kiliman says:

    First of all, thanks for pointing out the ATL code. That’s exactly what I was looking for.

    Now, I went back and read your post about debugging with Cassini. The thing is, I wrote CassiniEx to handle multiple ASP.NET AppDomains in a single instance of CassiniEx. So using the "Program" debug mode wouldn’t work for me.

    Like I said, I’m able to debug just fine using Process Attach, but I’d like to be able to use the same "F5" debugging as IIS.

    I think the ATL code you pointed me to will do what I need. Is there any specific reason I shouldn’t use it?

    Thanks again.

    Kiliman

  6. Gregg Miskelly says:

    If you can get it to work, more power to you.

    If it was me, I would just configure the project to launch CassiniEx instead so that I would have to worry about securing my debug verb code, or diagnosing problems with it.

  7. Here is a great look at common mistakes that can lead to the debugging the server error. You know the one, it sounds a lot like; "You do not have permissions to debug the server". Some of the things that…

  8. Channel 9 says:

    Thanks again peter, your help it’s very usseful (in half a day i advance more than in 2 days), i read the blogs and found that my situation is very scary :), 1