Cannot Debug Web Project!

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Axel Dahmen - 28 Oct 2006 01:55 GMT

Hi,

after installing Visual Studio 2005 on my machine (W2k3 SP1) and creating a test web project I finally can't get the debugger to run!

This is the error message (box) I get (translated from German):

Debugging can not be started on the web server. Login failed: unknown user or wrong password.

It probably has to do with my network setup: I've got two IP addresses on my machine. The second one is dedicated to IIS. I've created two new websites responding only to this second IP address. Both are separated by host names (dev and prod). On Visual Studio .NET (2003) I once had to install Remote Debugging to get this configuration to run so I know it's a bit complicated to get this configuration to run.

Using a browser I can run the web application without any problem. I just can't debug.

HEEEEEEEEEEEEEELP!!!

Axel Dahmen

Signature

Vote for a next step in ASP.NET evolution:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID
=231678

Reply to this Message

Steven Cheng[MSFT] - 30 Oct 2006 08:35 GMT

Hello Axel,

From your description, you're encountering the following error when try F5
debugging an ASP.NET 2.0 web application in a virtual directory that is
under a n explicit IP IIS site(and use hostheader), correct?

=====================
Unable to start debugging on the web server. Logon failure: unknown user
name or bad password. See help for more information.
=====================

According to your description, I've performed some test in my local test
environment and I did reproduce the same behavior with the following
settings:

** In IIS create a new website and assign it an explicit IP address and
configure it to use a custom host header.

**Create an ASP.NET 2.0 web site application under that site and configure
it to use integrated windows authentication in IIS

When start F5 debugging , it report the error you mentioned. Is this the
exact behavior in your case?

Also, based on my test, currently if you assign the IIS site's IP address
as "All Unassigned" and do not use host header(as the default setting for
default site), we can correctly perform F5 debugging against it.

I'm currently performing further research on this and will update you if I
get any new update. Also, if there is anything different from my
description and yours or anything I missed, please feel free to let me know.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

Steven Cheng[MSFT] - 30 Oct 2006 14:58 GMT

Hello Axel,

After some further research, I think the problem here is caused by the
IIS's loopback address checking, on XP SP2 or windows 2k3 sp1, the IIS will
verify the coming request's servername , if it unmatch the computer name,
the authentication will fail. See the below knowledge base article:

#You receive error 401.1 when you browse a Web site that uses Integrated
Authentication and is hosted on IIS 5.1 or IIS 6
http://support.microsoft.com/kb/896861/en-us

Therefore, for your scenario, you can disable the local loopback check on
the development server machine following the description in the above
aritlce. Remember to restart the IIS admin service after the change. I've
tested it in my local environment and it works well.

Hope this helps.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

Axel Dahmen - 31 Oct 2006 02:11 GMT

Hello Steven,

thanks for replying, your help is quite appreciated!

I've tried both solutions of the KB article, but to no avail:

I)
I've set the authentication scheme to "None". No change.

II)
Method 2:
No change, even after rebooting the server (W2k3 R2).

One question: In the KB article there's no information about which separator character to use in order to enter more than one host name. Do you by chance know what this separator character might be?

Method 1:
Removing the key from Method 2 and adding the DWord value mentioned in Method 1 yields following error after starting a debug session (translated again from the German version):

Debugging can't be started on the web server. Connection wasn't established because an identical name already exists in the network. Go to "System" in Control Panel to change the computer name and try again.

This error persists, even after rebooting the server (W2k3 R2).

May I take the opportunity to mention three things:

- The first error message provides a help button pointing to a void web page.

- In the second message's second paragraph it says "Click 'Help' to get more information". But there's no [Help] button.

- Using "Windows" as authentication scheme for a web application seems rather uncommon to me. Is it possible for me to change the default value for new web applications to "None"?

Thanks again for trying to help so hard!

TIA,
Axel

Signature

Vote for a next step in ASP.NET evolution:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID
=231678

------

> Hello Axel,
>
[quoted text clipped - 21 lines]
>
> This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

Steven Cheng[MSFT] - 31 Oct 2006 05:00 GMT

Thanks for your reply Axel,

I'm sorry to hear that the problem remains on your side.

For your comments in the last reply,

Yes, you need to use "integrated windows authentication" in your IIS
virtual directory for your ASP.NET application because F5 debug rely on
integrated windows authentication. You can choose to enable anonymous or
not, this doesn't matter.

And for the two solutions in that kb article, I only tried the first one
(disable loopback) originally and it works, after I tried the second one,
it seems it didn't work on my side either. For the first solution, after
you add the "DisableLoopbackCheck" dword value, it report a different error
message, I think your original problem has been resolved by this setting
and the new error message indicate another problem in your environment.

As the new error message said:

==================
Debugging can't be started on the web server. Connection wasn't established
because an identical name already exists in the network. Go to "System" in
Control Panel to change the computer name and try again.
==================

there seems have naming collision in your network environment. Since your
IIS site is configured to use host header(or DNS name), have you checked to
see whether the name is conflicting with other machine's name or registered
SPN in your local environment? By default for windows OS XP sp2 or 2003
later, the integrated windows authentication will use kerberos by default
and in such scenario, the server service's principal name is very
important. For general test, you can use the following command(mentioned
in the below kb article) to disable kerberos protocol and force your IIS to
use NTLM authentication to see whether the behavior changes :

cscript adsutil.vbs set w3svc/NTAuthenticationProviders "NTLM"

#How to configure IIS to support both the Kerberos protocol and the NTLM
protocol for network authentication
http://support.microsoft.com/kb/215383/en-us

Meanwhile, I'll perform some further research to see whether there is any
information that fit this case. Please feel free to let me know your update
and test result.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

Axel Dahmen - 31 Oct 2006 08:32 GMT

> For your comments in the last reply,
>
> Yes, you need to use "integrated windows authentication" in your IIS
> virtual directory for your ASP.NET application because F5 debug rely on
> integrated windows authentication. You can choose to enable anonymous or
> not, this doesn't matter.

Have you been talking about the IIS settings in your last reply? Well that uses Windows authentication on my machine for sure. I'd been referring to the web.config setting in my last reply. So the web.config setting doesn't have any influence here then, right?

> important. For general test, you can use the following command(mentioned
> in the below kb article) to disable kerberos protocol and force your IIS to
> use NTLM authentication to see whether the behavior changes :
>
> cscript adsutil.vbs set w3svc/NTAuthenticationProviders "NTLM"

adsutil.vbs get ... yields: "The parameter "NTAuthenticationProviders" is not set at this node." which, according to the KB article you've mentioned, equals "NTLM".

Perhaps the following information is of any help to you:

* I've currently got only one machine, running Windows 2003 Server R2.

* These are it's DNS settings:

Name Type Data
-------------------------
+ _msdcs
+ _sites
+ _tcp
+ _udp
+ DomainDnsZones
+ ForestDnsZones
+ TAPI3Directory
(identisch mit übergeordnetem Ordner) Autoritätsursprung (SOA) [148], hans.shop.local., hostmaster.
(identisch mit übergeordnetem Ordner) Namenserver (NS) hans.shop.local.
(identisch mit übergeordnetem Ordner) Host (A) 192.168.19.1
(identisch mit übergeordnetem Ordner) Host (A) 192.168.19.2
dev Alias (CNAME) prod.shop.local.
hans Host (A) 192.168.19.1
prod Host (A) 192.168.19.2

* This is a listing of the web sites it's running:
Path .NET Version Name AppPool
-----------------------------------------
W3SVC/ 1.1.4322.2300 Default DefaultAppPool
W3SVC/1/ROOT/ 1.1.4322.2300 Admin DefaultAppPool
W3SVC/1076814132/root/ 2.0.50727.0 dev PoolNet2.0
W3SVC/2083407965/root/ 2.0.50727.0 prod PoolNet2.0
W3SVC/3/ROOT/ 2.0.50727.0 Virtual Server PoolNet2.0
W3SVC/3815/Root/ 1.1.4322.2300 MS SharePoint Admin. MSSharePointAppPool

* These are the IP settings of dev and prod:
IP Port Host Name
-------------------------------
192.168.19.2 80 dev
192.168.19.2 80 prod

TIA,
Axel Dahmen

Reply to this Message

Axel Dahmen - 31 Oct 2006 15:14 GMT

Steven, I have to admit that I don't have any clue why the debugger isn't working... I'd love to give you any piece of helpful information at hand, but I can't.

Reply to this Message

Steven Cheng[MSFT] - 01 Nov 2006 06:54 GMT

Hi Axel,

Thanks for your reply and the effort you put.

I've just got some new information from the product team engineers, they
tell me that the new problem you met is likely due to the existing issue of
VS IDE when send debugging request to local website that use custom
hostheader or DNS name rather than the localhost address. here is the
original description from the developer engineer:

=============
Prior to SP1, the debugger didn't do a full DNS query to decide if a
hostname represented the local computer. So for anything funky, the
debugger would thinks that the hostname represents a remote machine and
tries to connect to a named pipe on this remote machine. The file system
then returns this bogus error message. With SP1, we resolve the host name
and realize that it really represents the local computer.
================

They say that this issue should be fixed in the coming VS 2005 SP1. Also,
since the beta version of VS 2005 SP1 is already available, they recommend
that you try installing the VS 2005 SP1 on your test machine to see whether
it helps if it won't quite affect your current machine's settings.
Here you can get the beta package of visual studio 2005 sp1:

#Visual Studio 2005 Service Pack 1 Beta
http://www.microsoft.com/downloads/details.aspx?FamilyID=8D702463-674B-4978-
9E22-C989130F6553&displaylang=en

Hope this helps. Please feel free to let me know how everything going.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

Axel Dahmen - 05 Nov 2006 18:19 GMT

Hi Steven,

I've tried to install the SP1 beta but unfortunately it doesn't install on my German Visual Studio as it's only available in English.

I felt the information from the product team engineers was quite helpful. Knowing that the problem will be solved with VS80SP1 I can now start working preliminary using the File System access mode and the web server coming with VS8. I still require the solution to test deployment of my web applications with different configurations.

Steven, you've been a GREAT help and I really much appreciate the effort you've taken to help me solve my problem!

I'm now looking forward to be able to download SP1. Do you perhaps know when the final version will be available?

TIA,
www.dashop.de
Axel Dahmen

Signature

Vote for a next step in ASP.NET evolution:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID
=231678

------

> Hi Axel,
>
[quoted text clipped - 34 lines]
>
> This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

Steven Cheng[MSFT] - 06 Nov 2006 03:43 GMT

Hello Axel,

Thanks for your followup.

As for the VS 2005 SP1, as far as I know, the current scheduled plan for
the final release is at the end of December. However, this is a estimate
date and may change due to any additional code/bug review/fixs plan.
Anyway, it won't be very far from here.

In addition, for your current ASP.NET application debugging(hosted in IIS),
have you also tried manually attach the ASP.NET worker process for source
code debugging? This will has the same effect as F5 debugging, you can do
this through the following steps:

**start running your ASP.NET application(by visit a page in the application)

** Go "Debug---> Attache to Process..." menu item and in the popup dialog,
choose the ASP.NET worker process in which your asp.net application is
running( for IIS6, ASP.NET worker process is the w3wp.exe while for IIS5,
it is the aspnet_wp.exe ). After chosen the process, click "attach"
button.

** Then the IDE is under debugging mode, when you visit a page and invoke a
function that has breakpoint set, the IDE/debugger will break to the source
line as F5 debugging.

You can try this to see whether it works for you. As always, welcome to
post here if there is anything else we can help.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

Axel Dahmen - 19 Nov 2006 14:35 GMT

Hi Steven,

thanks for replying. You're right, I can use the two methods you've mentioned meanwhile. Great Ideas!

Sorry for being so short-worded recently. The new project I've just started has a very high priority on my workload.

You've been a great help!

Best regards,
Axel Dahmen

------------------

> Hello Axel,
>
[quoted text clipped - 32 lines]
>
> This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

Steven Cheng[MSFT] - 20 Nov 2006 01:27 GMT

Glad to hear from you Axel,

Also wish you good luck in the new project.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

Rate this thread:

Cannot Debug Web Project!

Free Magazines