我之前碰到过好几例类似的情况，咱们一步步排查，应该能定位到问题所在：

1. 先确认远程调试组件版本是否匹配 #

VS2017远程调试.NET Core进程，依赖Linux机器上的vsdbg工具，版本必须和你的VS2017对应上才不会出问题：

• 登录Linux服务器，进入~/.vs-debugger目录，查看里面的vsdbg版本号
• 打开VS2017，点击「帮助」→「关于Microsoft Visual Studio」，记下你的VS版本（比如15.9.xx）
• 如果版本不匹配，就在Linux终端运行微软官方的vsdbg安装脚本，指定适配VS2017的版本号，或者直接安装兼容的最新版（脚本会自动处理依赖）

2. 再检查权限细节（哪怕用了root也不能忽略） #

虽然你用root登录，但还是有几个权限点要确认：

• 确保vsdbg有可执行权限：在Linux上执行chmod +x ~/.vs-debugger/vsdbg
• 试试临时关闭SELinux：执行setenforce 0，如果这时候能正常附加，说明是SELinux阻止了调试操作，之后再去配置对应的允许规则即可
• 确认你要附加的进程确实是root用户运行的（或者至少root有权限调试它，不过root一般都没问题，但万一进程是用其他用户启动的，也可能存在隐藏权限问题）

3. 打开VS调试日志，抓取错误细节 #

有时候VS没有弹出提示，但日志里会藏着关键信息：

• 打开VS2017，点击「工具」→「选项」→「调试」→「常规」，勾选「启用日志记录」，选择一个容易找到的保存路径
• 再尝试一次附加操作，等窗口关闭后，打开日志文件，搜索「Launching debug adapter」「error」「failure」这些关键词，应该能找到具体的失败原因，比如调试器无法连接到进程、缺少某个依赖之类的

4. 核对.NET Core发布和运行环境 #

• 你发布的是linux-arm runtime，要确保Linux服务器上安装了对应的.NET Core运行时（如果是框架依赖发布的话）；如果是自包含发布，要确认程序包完整，没有丢失文件
• 在Linux上执行ps aux | grep 你的程序名，确认进程确实是托管的.NET Core进程（命令行里能看到dotnet或者你的自包含程序名，不是原生进程）

5. 手动用vsdbg附加，查看是否有报错 #

直接在Linux上操作调试器，能排除VS端的问题：

• 先用pidof 你的程序名找到进程PID
• 执行~/.vs-debugger/vsdbg --attach <PID> --interpreter=vscode
  如果这个命令执行时弹出错误，那就是调试器本身或者进程的问题，跟着错误提示修复即可；如果能正常进入调试模式，那问题大概率出在VS2017的远程连接配置上

6. 重置VS的远程连接和缓存 #

• 尝试删掉现有的SSH连接配置，重新创建一个，有时候配置文件损坏会导致奇怪的连接失败
• 关闭VS2017，找到缓存目录C:\Users\<你的用户名>\AppData\Local\Microsoft\VisualStudio\15.0_<一串随机字符>\ComponentModelCache，删掉里面的文件，重启VS再试——缓存出问题也会导致各种诡异的调试故障

内容的提问来源于stack exchange，提问作者user3501602