在 Windows 容器中运行 Visual Studio 远程调试器(由 Docker 管理) [英] Running Visual Studio Remote Debugger in Windows Container (Docker managed)

问题描述

我尝试在 Windows Server 2016 TP4 上的 Windows 容器 中运行 Visual Studio 远程调试器.由于它在容器内运行，因此没有 UI.

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

我以管理员用户(nt authoritysystem)执行上述操作.这在主机上工作正常，但在容器内不起作用.Windows 事件日志显示以下错误事件.

I am executing the above as administrator user (nt authoritysystem). 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. 

完整的事件日志:

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 AUTHORITYSYSTEM

我注意到一个关于容器主机名的问题，但这可以修复:

I noticed one issue regarding the hostname of the container, but this can be fixed:

6D2D071453C5 是我的 Windows 容器(docker 管理)的 container id:

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

通常，在 Docker 中，这个 container id 也将是容器内部/的 hostname.

Usually, in Docker, this container id will also be the hostname inside/of the container.

所以，当我运行 docker inspect 6d2d071453c5 时，我会在输出中得到这个:

So, when I run docker inspect 6d2d071453c5, I get this in the output:

"Config": {
    "Hostname": "6d2d071453c5",
    "Domainname": "",

然后，在容器内，我在命令行中输入hostname"并得到:

But then, inside the container, I type "hostname" in the command line and get:

PS C:> hostname
test2016

这是目前特定于 Windows Server 2016 TP4/Windows 容器的错误.主机名不应是 test2016(容器主机的名称，我的实际物理 Win2016 服务器)，而是容器 id (6d2d071453c5).至少，这将是我的预期行为，当我在需要 VM 的 Windows 上运行任何其他容器(即 Ubuntu 容器)时也是如此.我刚刚重新检查了它.

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

现在我至少可以 ping 我自己的主机名了.

Now I can ping my own hostname at least.

PS C:Program FilesMicrosoft Visual Studio 14.0Common7IDERemote Debuggerx64> 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?

======= 更新 ======

如下所示，我尝试了主机名参数.我不再在事件日志中看到任何错误，但我也没有看到任何东西正在侦听端口 4020.

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.

在 C:Program FilesMicrosoft Visual Studio 14.0Common7IDERemote Debuggerx64 目录下的容器内执行:

Executed inside the container in directory C:Program FilesMicrosoft Visual Studio 14.0Common7IDERemote Debuggerx64:

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

>

推荐答案

我发现这个序列可以工作:

I found this sequence to work:

PS C:> start-service msvsmon150
PS C:Program FilesMicrosoft Visual Studio 15.0Common7IDERemote Debuggerx64> .msvsmon  /noauth /anyuser /silent

在 Windows 10 托管的 Windows 容器中运行时，start-Service 命令会发出一个关于服务无法启动的错误.但是，在输入第二个命令后，端口在 netstat -ab 中显示为被阻止，Visual Studio 2017 可以嗅探调试器单元.

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.

这篇关于在 Windows 容器中运行 Visual Studio 远程调试器(由 Docker 管理)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！