Answered by:

Unable to start debugging on the web server with VS2008 SP1 and IIS7

Question

I’m getting the message Unable to start debugging on the web server. IIS does not list a web site that matches the launched URL when attempting to run VB ASP.NET websites within IIS7 using VS2008 SP1 with .NET Framework 3.5 on Vista 64-bit Ultimate.

I’ve installed the Microsoft URL Rewrite module (though I did remove it temporarily whilst having these problems). Apart from that I've done all the usual things like run in Administrator mode, enabled Windows Authentication, HTTP Keep Alives are enabled.

I use IIS rather than the file system for development. I have discovered with a test app that debugging does work with the file system but not with Local IIS.

On VS2003 there used to be a webinfo file that ensured that the debugger could reference the project file, but that now seems obsolete.

Answers

I recently (ie post this debugging issue) had a problem with the Microsoft URL Rewrite Module which it looks like you are using. There was a new release on 10 November 2008 (see http://www.iis.net/extensions) which fixed my problems, but I had to uninstall the old version (not install over the top) to make it behave.

All replies

Could you please tell us the sub-version of your Vista system? Is it Vista Home Basic and Windows Vista Home Premium?

This problem occurs may be because Windows Vista Home Basic and Windows Vista Home Premium do not contain the Windows Authentication module for IIS. When the client tries to automatically attach the debugger in an ASP.NET 2.0 application, the client sends a HTTP request that contains the debug verb. This HTTP request is used to verify that the process of the application is running and to select the correct process to attach. This HTTP request must beauthenticated by using Windows Authentication. However, Windows Vista Home Basic and Windows Vista Home Premium do not contain the Windows Authentication module for IIS. Therefore, the problem that is described occurs.

I ran up a virtual machine over the weekend with a clean copy of VS2008 and debugging worked correctly until I installed Windows Vista Service Pack 1 for x64-based Systems (KB936330). So it would seem that the bug has returned...

The way I set up the test environment was to install everything bit by bit, testing the debugging as I went and taking snapshots in between tests to I could revert if need be. I did all the Windows Update fixes until only SP1 was left. After SP1 was installed the message came back. Reverting to the most recent snapshot removed the problem.

The acid test for me was to uninstall Vista SP1 from my main development computer to see if that made a difference. Obviously I had to do a full backup before doing this - hence the delay.

Unfortunately, just removing SP1 does not resolve the problem. Since I installed SP1 some months ago, it may be that something else is contributing to the problem. This is very wearisome - more to investiage but at some point I've got to do some real work.

I saw that thread earlier and much of it relates to Visual Studio 2005, not Visual Studio 2008 which is why I raised a new thread. I've tried the things mentioned in there and they regrettably they made no difference.

This morning I submitted a support request to Microsoft under my MSDN licence so I'm hoping that I will get an answer in the next few days.

I did find a solution that worked for me. I had assigned a speficic IP address in the Bindings settings in IIS7. To make debugging work you have to set this to All Unassigned.

The reason I set the IP address in the first place was that I was using my internal DNS to be able to resolve the websites that I'm working on individually. Since the host name points to a particular address, it seemed reasonably logical to set that address in the IIS Site Bindings dialogue - but this is wrong.

Unfortunately mine's already set to http:*:80:,https:*:443:. I was thinking of having the URL write done using global.asax which I've done many times before and it works fine locally and run this URL Rewrite on production.

make sure that HTTP Keep Alives are enabled. In IIS7 it's on the HTTP Response Headers > Set Common Headers dialogue. In IIS6, there's a tickbox (aka checkbox) on the Web Site tab of the Properties dialogue, in the connections section.

In addition I think I may have also had to remove Google Toolbar in IE, but I can't remember whether this was another problem or this one. Now I just have it in FireFox.

No go. See if I remove the following from web.config it works fine. However, as soon as this is added, VS 2008 in debug mode displays a page content that's meant for the browser in the application itself. The error message is displayed in a windows popup (not IE) which reads 'Unable to start debugging on the web server. <!DOCTYPE...etc and the rest of the HTML. I've also tried it on both Vista Home Premium and Vista Home Ultimate (configured by your previous email). Were you getting the same error message (HTML error message displayed in VS 2008 <title>IIS 7.0 Detailed Error - 500.50 - URL Rewrite Module Error..?

I just installed Visual Studio 2008 SP1 with .NET 3.5 SP to solve an issue where find and replace crashes VS2008. After applying the service pack, I can no longer debug. I tried all the options here and non of them seem to work. Any help would be greatly appreciated.

I recently (ie post this debugging issue) had a problem with the Microsoft URL Rewrite Module which it looks like you are using. There was a new release on 10 November 2008 (see http://www.iis.net/extensions) which fixed my problems, but I had to uninstall the old version (not install over the top) to make it behave.

This issue only appears on Web Sites configured with a host header on machines with IIS 6 or IIS 5.1 and the RTM version of the .Net Framework 3.5 SP1.

Background

Lukasz Pawlowski, a program mangager on the Reporting Services team, published a great blog post describing the cause and explanation of the authentication error. Paraphrasing Lukasz:

"This error is caused by a security change made to the .Net Framework in SP1. The .Net Framework 3.5 SP1 now defaults to specifying the Host Name used in the request URL in an SPN in the NTLM authentication package. The NTLM authentication process includes a challenge issued by the destination computer and sent back to the client computer. When Windows receives a challenge it generated itself, authentication will fail unless the connection is a loop back connection. When a Web Site is configured with a host header, the host name is neither the machine name nor the loop back IP address nor the machine's IP address, so Windows fails the authentication requests.""