Public Hotfix Patch Available for Debugging ASP.NET on IIS7

People who use VS 2005 to debug ASP.NET applications running in IIS7 on Windows Vista can encounter one of the following error messages when they press F5 to auto-attach the debugger in the IDE:

  • "An authentication error occurred while communicating with the web server."
  • "Debugging failed because integrated Windows authentication is not enabled."
  • "Authentication error occurred while communicating with the web server.  Try disabling 'Digest authentication'"

The above errors occur because of the way that VS 2005 looks up the Process ID of the IIS7 worker process that ASP.NET is running within.  Specifically, when you use F5 to "auto attach" the debugger with Visual Studio it sends an HTTP request to ASP.NET using Windows Authentication to retrieve the worker process details.  This works fine if you have Windows Authentication enabled on your web-server, and are using Windows Authentication as the primary authentication method for your web application.  It runs into problems, though, in a couple of circumstances:

  1. If you have forms-auth enabled in ASP.NET and are running in "integrated mode" on the IIS7 web-server.  This ends up blocking the process handler.
  2. If you don't have the windows authentication module installed on your web-server (it is now an optional component).
  3. If you are running on Windows Vista Home (which doesn't support the windows authentication module).

Patch Download Available

To fix the above cases which block F5 "auto-attaching" from working, we recently released a public hotfix for Visual Studio 2005.  It addresses each of the above problem causes.  You can download the hotfix patch for free here.  Once you install it, your Visual Studio F5 auto-attach behavior will work just fine.

You can read more about the patch and issues it fixes in the KB article here, and the blog posts here and here.

If you have any problems installing the patch or find that you still see issues after you install it, you'll want to contact Microsoft product support for assistance and they'll help debug it further.  Calls to Microsoft Product Support are free if they are related to a product bug (either a QFE HotFix request or a product bug you are running into).  You can find details on how to contact Microsoft product support on this page (it allows you to lookup the local phone number to use by country).

How to Manually Attach a Debugger to a Process

I have helped a few people workaround this issue before the patch was available.  One of the things I realized in doing so was that a lot of developers don't realize all of the options that are available when debugging applications, and the different ways that you can use Visual Studio to debug a process/application.

When you press F5 within Visual Studio (the Debug->Start Debugging menu item) you are telling Visual Studio to start up the application and automatically attach the debugger to it.  An alternative approach that you can also use to debug an already running application is to use the "Debug->Attach to Process..." menu item. 

When you select "Debug->Attach to Process..." it will bring up a dialog that shows you the running processes on your computer (you can also type in the IP address of a remote computer to debug):

If you want to debug an ASP.NET application running using IIS, make sure to select the "Show processes in all sessions" checkbox (since IIS runs as a service on Windows and not under your local account).  You should then find w3wp.exe worker processes listed (which is the name of the IIS worker processes on IIS6 and IIS7). 

Double clicking on any process will cause Visual Studio to attach the debugger to it - at which point all breakpoints you have set will fire and you can debug a process just like you would by launching it with F5.  This works for both web applications and client applications, and can be very useful when you already have an application running.  Note that you no longer have to attach this way if you have the hotfix above installed - but it is a useful approach to know nonetheless.

Hope this helps,

Scott

11 Comments

  • Hi Jon,

    This patch should work with both VS 2005 and Visual Web Developer Express.

    Thanks,

    Scott

  • Hi Mikael,

    This patch only works for VS 2005. VS 2008 Beta2, though, will have this fix built-in though - so starting with that you'll be set with VS 2008 as well.

    Thanks,

    Scott

  • Hi Jozef,

    We haven't finalized the release schedule for a SP2 for VS 2005. What we typically do is monitor the patch request level and then base the service pack schedule for a SP2 off of that.

    Thanks,

    Scott

  • Hi Gowtham,

    If you want to send me email about the virtual path model you are using for development, I can have someone on the team take a look to see why that isn't working.

    Thanks,

    Scott

  • Hi cmv,

    What you are running into with the 30 second issue is that IIS7's health monitoring infrastructure is kicking in. By default if a worker process is frozen for 30 seconds it thinks the worker process is deadlocked and restarts it.

    You can change this setting by opening up the IIS7 admin tool and click on the "Application Pools" node in the explorer. Bring up the "Advanced Settings" for the application pool you are using and then change the "Ping Period" setting underneath the "Process Model" section to something longer than 30 seconds. This should fix the issue.

    Hope this helps,

    Scott

  • Thanks Scott, it would helpful if someone could assist in the virtual path (I am not getting an error but it just bugs me why it shows as a runtime error).

    Thanks again!!

    Gowtham

  • Hi Luke,

    It will work on Vista x64 as well. The VS executable the patch updates is a 32-bit application (which runs in the WOW64 layer on x64), which is why the patch has x86 in the name.

    Thanks,

    Scott

  • Hi a_a,

    VS Orcas Beta1 still has this issue - but Beta2 (which will be out shortly) has it fixed.

    Thanks,

    Scott

  • Hi Ike,

    I don't think the WebDAV improvements are specifically related to ASP.NET's better handling of large files - but in general you should see that file uploads improve with IIS7 - since there has been a lot of optimization in the HTTP Pipeline.

    Hope this helps,

    Scott

  • Hi Dallas,

    Let me know if you are still having a problem (scottgu@microsoft.com).

    Thanks,

    Scott

  • Hi Tony,

    >>>> Edmund asked about the Windows Authentication module problem that exists between Reporting Services and Vista Home Premium. I didn't see a reply, is there a patch or will there be a patch to allow Reporting Services to be installed on Vista Home Premium.

    Unfortunately I don't know much about Reporting Services I'm afraid - so am not sure. :-( Have you tried calling Microsoft Product Support? They should know the answer.

    Thanks,

    Scott

Comments have been disabled for this content.