17

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"

>
Mathias Conradt
  • 28,420
  • 21
  • 138
  • 192
  • Added docker issue regarding the hostname: https://github.com/docker/docker/issues/21762 – Mathias Conradt Apr 05 '16 at 09:28
  • The hostname issue seems to be a known Windows Container issue in Server 2016 TP4, see https://github.com/docker/docker/issues/21762#issuecomment-205904128. However, my original question remains. – Mathias Conradt Apr 05 '16 at 17:19
  • Hostname issue is resolved in Server 2016 TP5, however, still haven't gotten the remote debugger to work on it either. – Mathias Conradt Aug 11 '16 at 12:40
  • i know its an old post but i see that there are no ports in your docker ps -a... i think your debugger cant find the docker container with port because you didnt set EXPOSE 4020 in your Dockerfile. – Gabbax0r Dec 01 '16 at 10:49

4 Answers4

2

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.

Asti
  • 12,447
  • 29
  • 38
  • Thanks for the answer. I don't have this environment up and running anymore, so I cannot test it anymore right now. The project has become obsolete in the meantime. I think I also ran it without the colons `"` as well, but not sure, cause that's how I ran it on the host to test it there as well (see my first command line). Did you get the debugger to run inside the container on your side? Since you mentioned "I've usually had a tough time getting it to work in the field." – Mathias Conradt Dec 01 '16 at 10:31
  • I've tried to make it work in Windows Server headless over a VPN (TAP), and these were some of the things I would have tried. – Asti Dec 01 '16 at 10:36
  • My apologies, Mathias. I just noticed the date of the original posting. – Asti Dec 01 '16 at 10:37
  • No problem. btw: I think that Windows Container and Windows Server headless are still different things and have different issues / behaviours. Not sure though. I had found and reported several issues (unrelated to this post) that were container specific, not Windows specific. If I ever get to setup the container again, I will give your thoughts a try though. If @Sedate Alien, who opened the bounty on this post, can confirm this as a solution, just let me know. – Mathias Conradt Dec 01 '16 at 11:51
  • If you and Sir Alien cannot make this work, and since you do have shell access might I recommend using `cordbg`? Assuming you have your symbol files in place, you could (slightly miserably) set breakpoints and get console output. – Asti Dec 01 '16 at 12:06
2

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.

Richard Banks
  • 12,456
  • 3
  • 46
  • 62
2

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.

Tam HANNA
  • 51
  • 6
1

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."

Eduardo Lucas
  • 44
  • 1
  • 3