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:
- 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.
- If you don't have the windows authentication module installed on your web-server (it is now an optional component).
- 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