none
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. 

    Any ideas anyone?

    Thanks

    Crispin

    Sunday, September 21, 2008 9:01 AM

Answers

  • Hi Maz

    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.

    Crispin
    Saturday, November 22, 2008 11:53 AM

All replies

  • Hello CrispinH,

    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 be authenticated 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.

    A supportted hotfix is available from Microsoft, to download this hotfix from the MSDN Code Gallery, visit the following Microsoft Web site:http://code.msdn.microsoft.com/KB937523

    Please do check your Operate System and let me know the result!
    Thank you!

    Best regards,

    Roahn
    Wednesday, September 24, 2008 3:18 AM
  • Hi Roahn

    I'm using 64-bit Vista Ultimate and I've got Windows Authentication available and applied by default to all the websites on this development comptuer.  So does the hotfix still apply?

    In the KB with the hotfix I notice that this appears to be a problem with VS2005 whereas I'm using VS2008.  Again, is this the appropriate hotfix?

    Regards

    Crispin
    Wednesday, September 24, 2008 7:15 AM
  • Hi Roahn

    I'm using 64-bit Vista Ultimate and I've got Windows Authentication available and applied by default to all the websites on this development comptuer.  So does the hotfix still apply?

    In the KB with the hotfix I notice that this appears to be a problem with VS2005 whereas I'm using VS2008.  Again, is this the appropriate hotfix?

    Regards

    Crispin
    Wednesday, September 24, 2008 7:16 AM
  • Hi CrispinH

    Thanks for your reply!

    According the message you described, this is an internal known issue that was identified in Visual Studio 2005, our developers are handling now, it will be fixed in Visual Studio 2008 please refer to this URL to confirm: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=310160&wa=wsignin1.0

    If you have any questions, don't hesitate to tell me!

    yours sincerely,
    Roahn
    Wednesday, September 24, 2008 12:00 PM
  • Hi Roahn

    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 question for me is how this can be resolved quickly.


    Regards

    Crispin

    Sunday, September 28, 2008 7:49 PM
  • More to this tale...

    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.


    Crispin
    Monday, September 29, 2008 2:06 PM
  • Hello CrispinH

    Thanks for your feedback!
    There are many suggestions in the following thread, maybe there's one that can help you!
    http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/04532b6d-e281-4b7f-a623-543dcb683e2f/

    Hoping for your reply!

    Thanks,
    Roahn
    Thursday, October 02, 2008 3:30 AM
  • Hi Roahn

    Thanks for the response.

    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.

    Thanks again

    Crispin
    Thursday, October 02, 2008 10:28 AM
  • Hi Chris,

    I'm having the same issue with Visual Studio 2008 and the Microsoft URL Rewrite module. Have you been able to find a solution?

    Thanks
    Maz
    Saturday, November 15, 2008 12:42 PM
  • Maz

    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.

    Hope this helps.

    Regards

    Crispin
    Saturday, November 15, 2008 1:58 PM
  • 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.

    Please let me know if you come across anything else.

    Thanks
    Maz.
    Saturday, November 15, 2008 2:16 PM
  • Maz

    The classic things (courtesy of http://ryanfarley.com/blog/archive/2005/08/23/8540.aspx) are:

    • enable Windows Authentication
    • 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.

    Good luck

    Crispin

    Saturday, November 15, 2008 2:41 PM
  •  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..? 

    <rewrite><rules><rule name="Rewrite to article.aspx"><match url="^article/([0-9]+)/([_0-9a-z-]+)" /><action type="Rewrite" url="article.aspx?id={R:1}&amp;title={R:2}" /></rule></rules></rewrite>

    Thanks again
    Maz
     

    Sunday, November 16, 2008 2:49 AM
  • 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.
    Friday, November 21, 2008 4:17 PM
  • Hi Maz

    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.

    Crispin
    Saturday, November 22, 2008 11:53 AM
  • Like BobbyJindal above, I too installed .NET 3.5 SP1 to addresss some issues and can no longer debug a .NET 2.0 Website, which has been HTTPS secured with the SSLDiagnostic (SelfSSL) tool.

    Can anyone help?
    Wednesday, February 04, 2009 7:24 AM
  • Ok here's the rub:

    Debugging A Web Site With A Host Header
    http://blogs.msdn.com/webdevtools/archive/2008/08/13/debugging-a-website-with-a-host-header.aspx

    "Scope

    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.""

    Wednesday, February 04, 2009 7:36 AM