I try to run the Visual Studio Remote Debugger in a Windows Container on Windows Server 2016 TP4. Since it runs inside a container, there is no UI.
I try to run the remote debugger via:
.\msvsmon.exe /nostatus /silent /nosecuritywarn /nofirewallwarn /noclrwarn /port 4020
I am executing the above as administrator user (nt authority\system). This works fine on the host computer, but it does not work inside the container. The Windows event log shows the following error event.
Msvsmon was unable to start a server named "`6D2D071453C5:4020`".
The following error occurred: The parameter is incorrect.
Complete event log:
Get-EventLog -LogName Application -EntryType Error | format-list
Index : 1718
EntryType : Error
InstanceId : 3221226473
Message : The description for Event ID '-1073740823' in Source 'Visual Studio Remote Debugger' cannot be found. The local computer may not have the necessary registry information or message DLL
files to display the message, or you may not have permission to access them. The following information is part of the event:'Msvsmon was unable to start a server named
'6D2D071453C5:4020'. The following error occurred: The parameter is incorrect.
View Msvsmon's help for more information.'
Category : (0)
CategoryNumber : 0
ReplacementStrings : {Msvsmon was unable to start a server named '6D2D071453C5:4020'. The following error occurred: The parameter is incorrect.
View Msvsmon's help for more information.}
Source : Visual Studio Remote Debugger
TimeGenerated : 05.04.2016 9:47:19 AM
TimeWritten : 05.04.2016 9:47:19 AM
UserName : NT AUTHORITY\SYSTEM
I noticed one issue regarding the hostname of the container, but this can be fixed:
6D2D071453C5 is the container id of my Windows container (docker managed):
PS C:> docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6d2d071453c5 d9d15fbca6d7 "cmd /S /C 'C:\\myprg-" 6 days ago Up 3 days derrin
Usually, in Docker, this container id will also be the hostname inside/of the container.
So, when I run docker inspect 6d2d071453c5, I get this in the output:
"Config": {
"Hostname": "6d2d071453c5",
"Domainname": "",
But then, inside the container, I type "hostname" in the command line and get:
PS C:> hostname
test2016
This is a bug specific to Windows Server 2016 TP4 / Windows Containers at the moment.
The hostname should not be test2016 (the name of the container host, my actual physical Win2016 server) but the container id (6d2d071453c5).
At least, this would be my expected behaviour and this is also the case when I run any other container, i.e. a Ubuntu container, on Windows that require a VM. I just re-checked it.
Nevertheless, to circumvent the issue, I adjust the host file, adding:
172.16.0.2 6d2d071453c5
Now I can ping my own hostname at least.
PS C:\Program Files\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64> ping 6D2D071453C5
Pinging 6d2d071453c5 [172.16.0.2] with 32 bytes of data:
Reply from 172.16.0.2: bytes=32 time<1ms TTL=128
Reply from 172.16.0.2: bytes=32 time<1ms TTL=128
Nevertheless, the remote debugger still does not start, and still says:
Msvsmon was unable to start a server named "`6D2D071453C5:4020`".
The following error occurred: The parameter is incorrect.
I don't see what's wrong with any of the parameters, according to the accompanied help file that lists all the parameters and options. The very same command works fine on the container host, just not inside the container.
Has anybody gotten the remote debugger to work inside a container?
======= Update ======
As suggest below, I tried the hostname parameter. I don't see any error in the event log anymore, but I also don't see that anything is listening on port 4020.
Executed inside the container in directory C:\Program Files\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64:
> hostname
WIN-DE6U4068NAF
> ".\msvsmon.exe /nostatus /silent /nosecuritywarn /nofirewallwarn /noclrwarn /port 4020 /hostname WIN-DE6U4068NAF"
.\msvsmon.exe /nostatus /silent /nosecuritywarn /nofirewallwarn /noclrwarn /port 4020 /hostname WIN-DE6U4068NAF
> netstat -ab | find "4020"
>
Did you try to "hardcode" the hostname using the msvsmon /hostname option?
According to the msvsmon documentation: "/hostname hostname_value Instructs the remote debugger to listen on the network using the specified hostname value, or IP address value. On a computer with multiple network cards, or with multiple assigned DNS host names, this option can be used to restrict which of these will allow remote debugging. For example, a server may have an internet facing address, and an internal address. By using '/hostname private_ip_address', remote debugging will not be available through the internet facing address."
Okay, throwing out the really obvious here. From your post, the command
".\msvsmon.exe /nostatus /silent /nosecuritywarn /nofirewallwarn /noclrwarn /port 4020 /hostname WIN-DE6U4068NAF"
will just print that exact same string in powershell. It doesn't actually start the debugger. The echo output shows this. (I might be reading too much into this)
So /nofirewallwarn only suppresses the blocked by firewall warning (YMMV), and doesn't actually get through the firewall. Have you run it with /prepcomputer first?
Have you tried /anyuser to bypass auth and allow just TCP to work?
Is msvsmon actually bound to the right network interface? Sometimes, being bound to the loopback adapter means that it can only be reachable locally. When you netstat does it show listening on all interfaces (0.0.0.0)?
Have you tried running it as a service with the /service option?
There might be some more gotchas, though. I've usually had a tough time getting it to work in the field.
To debug you'll need to install the remote tools into the image, run the container as per normal, and then start the remote debugger using docker exec.
The command line is as follows:
docker exec -it <container id/name> "C:\Program Files\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe" /nostatus /silent /noauth /anyuser /nosecuritywarn
I've got more detail in a blog post, and yes, turning off auth on your local dev machine does carry some risk (no matter how small) but this should at least give you an idea of how to do it. You can always tweak the command line options to get it working the way you want.
I found this sequence to work:
PS C:\> start-service msvsmon150
PS C:\Program Files\Microsoft Visual Studio 15.0\Common7\IDE\Remote Debugger\x64> .\msvsmon /noauth /anyuser /silent
The start-Service command will fart out an error about how the service can not start when running in a Windows 10 hosted Windows container. However, after entering the second command, the ports show up as blocked in netstat -ab and Visual Studio 2017 can sniff the debugger unit.
来源：https://stackoverflow.com/questions/36420337/running-visual-studio-remote-debugger-in-windows-container-docker-managed