I'm trying to debug some code running on a server using the Visual Studio 2015 Remote Debugger. I can get connected and view all the running processes but when I try to connect to the w3wp.exe process it is having none of it.
From my fiddling I've noticed that it will connect to apps that are running in the Managed (v4.0.30319), x86 mode, however if it's just x86 it doesn't connect and I'm guessing this is because it's been compiled and isn't in MSIL.
I've copied over the files from my machine, by passing all the precompilation that we were doing, as much config set to debug as I can find and even still when I try to attach it still reports x86 with no mention of any managed code.
Just to clarify, this is what I see when attaching on my local machine:
And this is the same app running on the remote server:
Does anyone know how to force the server to run in managed mode, or is there another reason I can't connect to the remove debugger?
Thanks
Related
I have recently deployed my ASP.NET Core application to my IIS8 server. However due to some issues, I have to remotely debug it.
I installed the Remote Debugger and managed to connect to the server and Attach a process.
However, I am unsure of what to attach from there. I have tried attaching all dotnet.exe and w3wp.exe processes but each time I do that, my breakpoint turns white and says that it won't hit.
I took a look at my Modules tab and for some reason, my symbols aren't loaded for my application dlls. I have made sure that the configuration is Debug and that the ASPNETCORE_ENVIRONMENT is Development.
Currently this is what I am doing:
Run the Remote debugger on the IIS server
Run the website on my local laptop
Attach a process in Visual Studio
I am using VS2012, .NET 4.5. I just downloaded NuGetGalary from github and trying to build and run the Web application of it.
I am using IIS Express with project Url http://localhost:8081
But when I launch the project, I get the following error message
What could be wrong ?
Silly reason,
I used this Microsoft Support Article to find out what was wrong. Turned out it was VMWare Workstation Server service holding up the 443 port. I stopped the service and now project launches fine.
Since I can't add comments yet, I put my thoughts here.
Since you launch the site on "localhost:8081", and it can't be launched because of port 443 being used, it's probably that inside the solution, some service is started, and by default is running on 443.
Your solution consisted of stopping the app "VMWare Workstation Server" which seemed to be using the same port. This might not always be possible, depending the type of app using the port.
What you could also have done (maybe), is configuring the project/service (inside Visual Studio) to use another port than 443.
You can usually find this element in the project properties.
We have a Windows Server 2008 R2 box setup as a Terminal Server with Visual Studio 2012 installed on it for remote developers to be able to do development on our ASP.net systems.
We would like to be able to do debugging on out projects the same way we do when developing on our local machines using visual studios internal development server.
I am trying to start local debugging on an ASP.Net project (F5) in VS2012 - the project compiles - IE comes up with my localhost url and then it just spins with "connecting..." and the page never comes up.
Pulling up the same workspace on a local machine and debugging comes up just fine.
I've exhausted my google-fu on looking for solutions here and humbly ask you all for any insight.
Visual Studio works a little differently when you are debugging on a server. You don't really want to use VStudio to play/debug on a web server. You need to use the menu option "Debug", "Attach to process". There will be several processes running, so it might take a few tries to find the right process.
Be careful though. Because your break-points will actually freeze IIS for the entire server. It could be a pretty big inconvenience for everyone who is using IIS at the time.
If you are trying to debug the project from your IIS server, you need to verify if the account has Administrator rights, also if the project has been deployed with its source files, you can attach the process (maybe it is w3wp.exe) in Visual Studio and debug it.
Another way is to open the solution using Visual Studio and change in the web project's property the server: Use Visual Studio Development Server.
Let me know more info about your scenario to provide you more paths.
What I would do is attach to the IIS process on the server: http://msdn.microsoft.com/en-us/library/vstudio/3s68z0b3.aspx you can even do this off your machine.
make sure debug is enabled in web.config for that app and you've mounted the remote project. Add a break point, debug by attaching to the IIS app pool process & it'll trigger the break point.
I was able to Attach Process to the SPUCWorkerProcess.exe even though it's a farm solution and not a sandbox solution
I have local my projects asp.net open in visual studio 2010. And also copy this project to IIS folder in remote hosting. Cause in hosting directory I don't have VS so I copy there remote debugger application. I connect from my Visual Studio to IIS process on hosting, but any of breakpoints not fire.
Why ?
I had the same issue when I connected using the Transport in the "Attach to Process" dialog set to "Remote (native only with no authentication)". I was able to connect to the IIS process (w3wp.exe for IIS6 on Win2K3), but no breakpoints were hit when I navigated within the web app.
To get it working, I changed the Transport to "Default". Then I ran into numerous issues with successfully connecting to the Visual Studio Remote Debugging Monitor. But once I resolved them all and was able to get the list of processes from the remote machine, I could connect to W3WP.exe and voila, my breakpoints started working and I was able to debug normally.
You don't provide much detail on your local and remote configuration, so this just a guess whether it might help.
So, I've read that it is not a good idea to install VS2008 on my test server machine as it changes the run time environment too much. I've never attempted remote debugging with Visual Studio before, so what is the "best" way to get line by line remote debugging of server side web app code. I'd like to be able to set a breakpoint, attach, and start stepping line by line to verify code flow and, you know, debug and stuff :).
I'm sure most of the answers will pertain to ASP.NET code, and I'm interested in that, but my current code base is actually Classic ASP and ISAPI Extensions, so I care about that a little more.
Also, my test server is running in VMWare, I've noticed in the latest VMWare install it mentioning something about debugging support, but I'm unfamiliar with what that means...anyone using it, what does it do for you?
First, this is MUCH easier if both the server and your workstation are on the same domain (the server needs access to connect to your machine). In your C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86 (or x64, or ia64) directory are the files you need to copy to your server. There are different versions between Visual Studio versions, so make sure they match on the client and server side. On the server, fire up msvsmon. It will say something like "Msvsmon started a new server named xxx#yyyy". This is the name you'll use in Visual Studio to connect to this server. You can go into Tools > Options to set the server name and to set the authentication mode (hopefully Windows Authentication) - BTW No Authentication doesn't work for managed code.
On the client side, open up Visual Studio and load the solution you're going to debug. Then go to Debug > Attach to Process. In the "Qualifier" field enter the name of the server as you saw it appear earlier. Click on the Select button and select the type of code you want to debug, then hit OK. Hopefully you'll see a list of the processes on the server that you can attach to (you should also see on the server that the debugging monitor just said you connected). Find the process to attach to (start up the app if necessary). If it's an ASP.NET website, you'd select w3wp.exe, then hit Attach. Set your breakpoints and hopefully you're now remotely debugging the code.
AFAIK - the VMWare option lets you start up code inside of a VM but debug it from your workstation.
Visual Studio comes with a remote debugger that you can run as an exe on your server. It works best if you can run it as the same domain user as your copy of visual studio. You can then do an attach to process from the debugger on your machine to the IIS process on the server and debug as if it was running on your machine. You get more options for .Net debugging, but there's support for older platforms too.