I’m trying to get remote debugging working again on a Windows 2003 server that I use for ASP.Net 2.0 development. I had everything up and running for months then one day, I was forced by our AD policy to change my password and the remote debugging has not worked since.
I have a Windows 2003 server running virtually (MS Virtual PC 2007) on the same system that I run my Visual Studio 2005 IDE from (Windows XP Pro). Both systems are members of the same domain and my domain account is in the admin group of both systems. I’m logged into the XP machine running Visual Studio and the Windows server running the Debug Console using this domain account.
When I try to attach to the remote debugger from within VS I get an error after about 1 minute… “Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor and ‘myServer’. This operation returned because the timeout period expired.”
When attaching from VS, I have used just the server name as well as the full debug server instance name (Domain\user#myServer) that is listed in the console but I get the same results. I have also tried running the console as a service using my domain account (this is the original way I had it setup) and from a share on the XP PC running VS….again same results. I also checked the permissions on the Debug Console and both the admin group as well as my domain account are listed and Debug is set to “Allow” for both.
When I try to attach to the debugger from within VS I can see the connection popup on the Remote Debug Console of the server and it says it’s connected but I noticed that it’s trying to connect as a different user than what I’m logged into either machine as. The debug console shows the connection belongs to a local account (myServer\user1)… I would expect to see Domain\User. The local account that shows in the debug console does exist locally on both systems and is in the local admin group on each system but I have no idea why it would all of a sudden try to use that account rather than the domain account I’m logged in as on both systems.
As I mentioned, everything was working for months and only seem to stop functioning after the AD account password was changed.
Does anyone have any ideas on what could be causing this issue?
Any help would be greatly appreciated.
Thanks!
I thought I would put an update to this question in case someone else runs into a similar issue.
Well after pulling my hair out on this issue for a couple days now, I decided to try installing VS 2005 on a new workstation. I was able to connect to the remote debug process of my dev server without any problems.
I’m still not 100% sure what the actually cause of the problem was but I thnk it was related to 2 different issues. Once I was able to get the remote debugging working from the new workstation I decided to reset the VS Environmental settings on the one I was having issue with. I’m not sure why I did not try this sooner …but this seems to have taken care of the problem and remote debugging now works from the system I was having problems with.
The issue of the wrong user was due to a cached login account being used over that of the currently logged in domain user. I ran "%windir%\system32\rundll32.exe keymgr.dll, KRShowKeyMgr" on the workstation running VS, found the local account in question, deleted it from the Stored User Names and Passwords box and from that point on the remote debugger used my domain account as it should.
Related
I must preface this post by saying that I am not an experienced developer, I am in the process of learning through trial and error and a lot of google searches so detailed (step-by-step) feedback would be greatly appreciated. I created a website, which does not use a database, using visual studio 2015 and I am attempting to host it locally on a Windows 2008 R2 server.
I installed IIS and loaded the asp.net v4.0 framework. The site works fine, produces no errors when I test it and works after being published only if the visual studio is still running.
However, when I close the Visual studio and open my browser window to http://localhost:50044 (which is the URL listed in properties menu in VS), I also tried using port :80 and nothing. When trying to add Web Site via the IIS management utility I receive the following authentication error: ”Cannot verify access path (C:\Inetpub\wwwroot).”
I checked the permissions and windows authentication is enabled with read access, and all other permissions seem to be correct. I am at a loss, I'm sure it is probably something simple that I am missing due to my lack of knowledge and experience. Any help would be appreciated.
It's sounds like you are running on IIS express which in your case stops running when you close visual studio. Normal process is create a new website in IIS and point to the folder where your web.config is. You can then hack your host file (C:\Windows\System32\drivers\etc) so DNS works. Add an entry like "127.0.0.1 mytestwebsite.com". I hope that helps
So I figured out part of what was happening. I didn't realize that visual studio has built in IIS and was using that by default.
I ran VS as an admin, created a new project, then attempted to create a virtual directory thru VS under the project/properties/web tab. I selected local IIS and entered http://localhost/boc and it returns an error: unable to create vd. Web server http://localhost... Could not be found.
I then went in to the IIS manager and set up a virtual directory with no issues. However, when I attempt to reference it thru VS I again receive an error message.
Any ideas?
When I try to debug my VS2010 web app (F5), the IE web browser windows pops up but then freezes, and my VS2010 IDE window pops up an error message:
Unable to start program 'http://localhost:nnnn/Login.aspx'.
Access is denied.
I'm running VS2010 (10.0.30319.1), targeted to ASP.NET 4.0 (4.0.30319), in non-administrator mode, with ASP.NET debugging enabled, on 64-bit Windows 7 Enterprise SP1, with IE 9 (9.0.8112.16421 with update 9.0.29).
This web app and others I work with have been working just fine for several months, but they all started to misbehave in this manner a few weeks ago. At first, the first time I tried to debug (F5) I'd get the error, but after clearing it and closing the IE window and trying F5 again a second time, the browser would come up just fine. I assumed it was just some glitch, so I tolerated it.
Lately, though it has gotten worse, to the point that 90% of my attempts and re-attempts to debug the web app cause a hung browser and the error. It sometimes works, but most times it doesn't. I have to kill the handing iexplorer.exe processes to clean up my user space, otherwise I eventually get a message about not having enough files to start the browser. I try rebuilding, stopping the ASP.NET Development Server process, even exiting VS2010 and restarting it, but I can't seem to find the magic sequence of events to get it to work.
If I start without debug (Shift-F5), it works, but two IE web browser windows are opened, and both attach to the web app. I don't know if this is related to the first problem. And needless to say, this does not really allow me to debug my code. I tried attaching to either of the IE processes, but I still could not get the debugger to actually debug the executing app. (There is a message about no symbols being loaded for the attached process.)
Most of the solutions for this problem I've found say something about running with administrator access. I cannot do this, however; I work at a large financial company, and developers are not allowed to have local admin rights on our PCs. I don't control system patches, but I can request Help Desk ticket to resolve the problem; but I'd like to resolve this problem myself if it is a fairly simple configuration problem on my part.
Addendum
I should also add that I am not using IIS (because I don't have it installed on my system, and I can't use it anyway because I don't have local admin rights), but instead I am using the built-in Visual Studio Development Server. I've also selected a specific HTTP port number for it to use. Also, all of the directories I'm been using were created by me (as part of my project workspace), so there should be no access permission problems.
Like I said, I can sometimes get a debugging web session started, but most of the time I can't. So whatever is causing this problem, it is probably something intermittent.
This tend to occur when you try to run the full version of IIS rather than the Visual Studio Web Server or IIS Express. Have you tried running IIS Express instead? I think there's support for IIS Express that came with one of the later updates to VS 2010?
IIS proper definitely requires full admin rights in order to attach a debugger because full IIS runs under a system account rather than your own account. IIS Express (as well as the Visual Studio Web Server) however should run under your own user account and so debugging should work on the local machine even with a non-admin account.
One issue that might cause problems is directory permissions. Make sure that the folder where your Web files live are read/execute accessible through the file system for your user account.
Finally make sure you don't have some other instance of a Web service running on the same HTTP port.
I am having the same issue, it works when i don't choose to debug but CTRL+F5 to start it. F5 Debugger al
I've been at this all day, trying to get Web Deployment setup on my server. First off, I'm running IIS7 under Windows Server 2008 Data Center 64bit (on a VPS). At first I thought I had it working, but it seems I was using the old (Windows Administrator login only) IIS6 stuff that comes alongside IIS7.
I've followed this guide perfectly, and I'm still getting errors: http://learn.iis.net/page.aspx/516/configure-the-web-deployment-handler/.
This is the error I receive (as per the directions at the end of the article): http://i.imgur.com/1HC7F.png
Any help is appreciated. I've tried everything (I've verified all the basic things like LOCAL SERVICE folder access, IIS Manager permissions, the service is active, etc).
Thanks, I know someone on SO knows this stuff ^_^.
I'm trying to debug an ASP.NET webapp that's configured to "Use Local IIS Web Server" on WinXP. When I start the debugger, the compile succeeds, and then the following error is displayed in a dialog:
Unable to start debugging on the web
server. The COM+ registry database
detected a system error
The webapp never launches in my browser. How can I get rid of this message and debug this webapp?
I tried the usual stuff, and my exact scenario ended up being described a post in the MSDN forums. Its answer worked for me, despite my environment (VS2008, .NET 3.5) being more modern:
Here are the steps I followed (basically a summary of the link above -- "ASPNET" being significant because that's the user running the IIS instance on my development box):
Close VS
Shutdown IIS
Add ASPNET to the local Administrators group
Start IIS
Start VS and successfully debug ASP.NET webapp
Close VS
Shutdown IIS
Remove ASPNET from the local Administrators group
Start IIS
Start VS and continue debugging ASP.NET webapp without error
My development workstation's security settings/situation is regularly managed by our security folks here, so something must have upset my ASP.NET/IIS/etc environment.
I am using the Visual Studio 2002 and I had the same problem, with tha same Error Message. To solve it, I did only the first 5 steps of the solution recommended before.
I am starting in VS 2002 because I use it in my work. I have the basic concepts, but I never develop in this program language, so I am a begginer.
The most important point in this solution I believe it is understand that ASPNET is a user in the development machine, as Administrator, as "Name.LastName" or any other user that access the machine. When I search for ASPNET to add in the Administrators Group and found it, made a lot more sense because I don't know exactly how the .NET architecture works.
So, if you have the same problem, I here confirm this solution solved my problem, even when I reboot my machine:
Close VS
Shutdown IIS
Add ASPNET user of the Machine to the local Administrators group
Start IIS
Start VS and successfully debug ASP.NET webapp
Thanks for the solution!!
We have two Win2k3 servers here, one is a domain controller and the other our webserver.
I'm running an ASP.NET MVC web app setup as a website in IIS on the webserver.
I've copied across the x86 remote debugging tools to the webserver, logged in to an admin account and ran msvsmon. I added the user I'm logged into my workstation as to the permissions list.
Opened up the web app project in VS2008 and went to Attach to Process, here are my settings:
Transport: Default
Qualifier: OURDOMAIN\AdminUsername#OURWEBSERVER
Attach To: Managed Code
Selected: w3wp.exe
Upon clicking Attach, the windows flicker for a few seconds and then I get:
Unable to attach to the process. Access is denied.
I've tried right-clicking msvsmon and using Run As to run it under the same account as I'm logged into my machine, but still no difference.
However, if I change the Attach To field to Auto: Native Code, it attaches fine, but I can't debug any of my managed .NET code.
This has me baffled - any ideas?
Anthony
Have you seen this article?
http://support.microsoft.com/default.aspx?scid=kb;en-us;833977&Product=vsnet
It's not clear from your question, but remote debugging requires that the user you are logged into on the remote machine exist on your local machine as well. You basically have to create a local account on your dev machine (yes, that sounds backwards). I'm not sure it respects domain accounts.
Is the code sitting precompiled on the server or in individual uncompiled .cs files?
I've tried right-clicking msvsmon and
using Run As to run it under the same
account as I'm logged into my machine,
but still no difference.
Did you add that account as an administrator in the server? I would try that, and instead of doing Run As, I would effectively log in with that account.
When running server and client in different domains, the plot thickens slightly. In those cases, the trick I use is to create a local account with the same name and same password on both machines. Login with the same account (it is not really the same account) in both machines and launch the remote debugger on the server and VS on the client. If any of the machines in this scenario is running Windows XP, you have to change the Local Security Policy, "Network access: Sharing and security model for local accounts", under "Security Options", to "Classic - local users authenticate themselves".
I have yet to see this work across domains. As with #paul-mrozowski, I've been able to do it on the same domain so long as the user running the debugger server matches your local user AND your able to properly auth against the machine. That last bit can be hampered by firewall configurations.