I have a 3rd party firewall blocking VS 2013 Update 2 Remote Debugging. I want our domain admin to open the necessary ports, but there seems to be a discrepancy in the documentation.
Online version mentions:
DCOM (TCP Port 135) and IPSEC (UDP 4500 / UDP 500)
Installed documentation mentions:
...To do so, allow traffic on TCP/IP ports that msvsmon.exe is listening on. By default, these are port 4018 and 4019, where 4018 is used on all operating systems, and 4019 is used only on Windows x64 to allow debugging x86 processes.
No mention of DCOM / IPSec. I know there was an architectural change starting Remote Tools 2012, but I don't know if it means that DCOM and IPSec were dropped since then. I've seen in the installed documentation mention of the Windows Web Services API, shipping with Windows 7 and Windows Server 2008 R2 (which happen to be my local/remote versions). Does this perhaps replace the DCOM and IPSec architecture?
Bottom line - which ports do I need to open for this particular version?
Comment: Editors please do not remove the words "Update 2", the Remote Tools have different versions corresponding to the different Visual Studio 2013 versions.
I recently tested remote debugging with Visual Studio 2013 Update 3 to an AWS EC2 instance.
I only needed inbound security group rules for TCP 4018-4019.
(Previously with Visual Studio 2012 I only needed inbound security group rules for TCP 4016-4017.)
Related
I have a fairly large web application developed in Visual Studio 2013, working perfectly on my local IIS. I have deployed to my remote server (Windows Server 2012) and have the usual problems with adapting to remote vs. local. My main issue is I cannot remote debug out of VS2013. The message I get is this:
Error Message from VS2013
What I have tried so far:
As per Firewall ports needed for Visual Studio 2013 Remote Debugging I have opened both TCP 4018 and 4019. First inbound, then also outbound.
Since that did not work I also opened DCOM (TCP 135) and UDP 4500 and 500. I did not create a new DCOM rule, only enabled the existing ones.
A few things to note:
1. The correct version of Remote Debugging Tools for VS2013 is installed
2. The Debugger is running and waiting for a new connection (run as admin)
3. My local machine and the remote server are both on the same VPN using LogMeIn Hamachi
4. I can see the machine when I try to attach process in the VS2013 debug configuration, it just won't allow me to connect.
I am out of ideas here. Any help is appreciated.
See the required ports for remote debugging here:
https://msdn.microsoft.com/library/ee126350(v=vs.100).aspx
[TCP] 135, 139, 445 - Required
[UDP] 137, 138 - Required
[UDP] 500, 4500 - Required if your domain policy requires network communication to be performed through IPSec.
[TCP] 80 - Required for Web Server debugging.
hope this helps ;)
I have an ASP.NET server running under VS2010 on my PC (Win7) on port 12345.
When I load localhost:12345 in Chrome, my default page loads perfectly.
But when I load 192.168.128.104:12345 (by my internal IP, not by localhost) I get "connection refused".
Exact same behavior when I try to access the server from another device on my intranet (in my case, a Raspberry Pi)
I realize that when I hit localhost that I'm just looping back in my adapter, thus the request never leaves my machine. So it would seem that the cause is due to the request leaving & re-entering my machine.
I've create custom Inbound & Outbound rules in my Windows Firewall to allow port 12345, but to no avail.
Any ideas would be appreciated.
I found the answer here:
Can I access ASP.NET Development server in an intranet?
which led me to this:
http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/UseFiddlerAsReverseProxy
As is so often the case, finding the answer is hugely dependent upon using the correct search terms. Here the critical keywords were "asp.net debug intranet"
The 'right way' here is to use IIS Express and you don't need fiddler to act as a reverse proxy. Its a hack that was used to work around using Cassini - a low budge web server that is outdated (and doesn't compare to IIS Express) and used with VS2010 prior to SP1.
In VS2010 SP1, IIS Express support was added. You can read about that here:
http://blogs.msdn.com/b/webdev/archive/2011/03/14/enabling-iis-express-support-in-vs-2010-sp1.aspx
IIS Express can handle this just fine - and Visual Studio 2010 integrates with it. Its not one or the other - you develop with Visual Studio and when you launch your app it launches it with 2010.
If you want something really easy, install Visual Studio 2015 Community Edition, use ASP.NET 5 (now called ASP.NET Core 1) and simply run it to self host via the play button looking drop down you are used to seeing in VS 2010- no web server required.
Again - being that its 2016 - what you cited is a very old way. If its a quick hack, I can understand that - but if you are looking for the best practice way going forward, use IIS Express (and ideally a newer version of Visual Studio - we have them for free in the 2013/2015 Community Editions)
Hope that helps!
I’m trying to set up automatic driver deployment and debugging to test a win 8.1 driver from Visual Studio 2013.
Host machine:
Win 7
VS2013
Target Machine:
Win 8.1
My host machine is set up with 2 network cards, 1 which connects to the corporate network and one spare. The target machine also has a network adapter.
My question is: is it possible to set up automatic deployment and debugging of drivers in Visual studio 2013 by connecting the host and target via a LAN whilst still being connected to the corporate domain and if not, is there a way of debugging wdk drivers on a target pc outside of visual studio, maybe via another application?
The documentation I found here only makes it seem possible by connecting to the same domain name or workgroup.
link to documentation
Many Thanks
Yes you can set up automatic deployment of the driver as well as getting visual studio to do the provisioning of the target pc over a local network as well as being connected to a corporate domain.
Admin rights are needed on the target
An extra ethernet card is needed in the host
All networks connections on the target are open with printer and file sharing options enabled
The ip and name of the target are listed in system32/etc/host in the host PC
A switch is needed and DHCP setting are enable with automatic IP
A good place to start:
https://msdn.microsoft.com/en-us/library/windows/hardware/gg507680.aspx
EDIT:
Basically, this was a nightmare and started dropping its connection. I reverted back to using WinDBG using:
custom scripts to copy everything over to USB
devcon to automactially load the driver
WinDBG to autoload appropriate settings on startup and load source files in to debug
I'm asking my network admin to open up ports on the firewall to allow remote debugging. It says in the documentation on MSDN that it needs UDP 135. However, the admin says that a number of non-standard 19xx ports are being used.
Exactly what ports are required for remote debugging to work?
You need to open ports on both your computer and the remote computer. Primarily it's TCP 135 not UDP 135.
All the ports and steps are listed here:
http://msdn.microsoft.com/en-us/library/h0d7tte4(v=vs.120).aspx
You can link your Admin to that page. If you don't have IPSec rules it basically comes down to:
Your PC:
TCP 135
Remote PC:
TCP 135, TCP 139, TCP 445, UDP 137, and UDP 138
Update: Fix the link as it was updated. Note, Remote Debugging transport changed significantly between Visual Studio 2010 and Visual Studio 2012+. The above ports should work for VS2010. Follow the link to see more information on VS2012+.
For Visual Studio 2013 I just needed to open 4018 and 4019 and it works like a breeze
Reference:
https://learn.microsoft.com/en-us/visualstudio/debugger/configure-the-windows-firewall-for-remote-debugging?view=vs-2022
For Visual Studio 2022 the remote computer needs
TCP Incoming
4026 for VS 2022
4025 for VS 2022 and Microsoft Azure App Service. This port is only used to remote debug a 32-bit process from a 64-bit version of the remote debugger
4024 for Microsoft Azure App Service
TCP Outgoing
3702
I need to do remote debugging of managed code (.NET) on a server hosted on a different network. Neither the client or server is on a domain so i have to use the public ip of the server.
I'm trying to use Visual Studio -> Attach to process -> default transport with the qualifier john#xx.xx.xx.xx but it's not working.
I get the error message : "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'john#xx.xx.xx.xx'. There is no server by the specified name running on the remote computer"
This error message tells me i can connect just fine but it can't find the msvsmon instance (which is 'john#WEB-001'). So i tried to use the combination of qualifiers such as WEB-001\john#xx.xx.xx.xx and xx.xx.xx.xx\john#WEB-001 but neither are working.
If I choose the transport "Remote (Native only with no authentication)" it connects just fine and I can see the process list on the server but it is pretty much useless because I can't debug managed code.
The administrator 'john' exists on both computer with the same password
Windows 2008 R2 X64 (Server)
Remote debugging component (VS2010) X64 installed
Firewall off
Msvsmon new server named 'john#WEB-001' running as john
Windows 7 X64 (Client)
Visual studio 2010 running as john
Firewall off
Any idea how to fix this, or is this scenario not supported? Thanks
having you tried putting web-001 in your hosts file, and connecting as john#web-001?
Try adding the server name to your hosts file:
192.168.1.100 WEB-001
Replace the IP with your own. Native code debugging is done over plain TCP/IP with no security but native code requires DCOM to enforce security, I don't understand the reason but ....
I know this is an old thread now but.
When the remote debugger is first installed you can set a firewall setting that allows all web traffic or only subnet connections. Run the configuration again to allow all web traffic.
Also, as the Administrator account, not a user in the Administrator group, Shift+r-click on the debugger shortcut to execute as a different user. Enter in the other user account that has the same username and password as the machine you are debugging with, in this case john.
This is the process I have to use.