-1

I'm working on a C# application, which is running on a remote PC. I have a VPN connection and using an RDP session, I can login to that computer.

On that computer, next to the running process, there are also two "msvsmon.exe" processes, having the following "Command line" entry in task manager:

  • C:\Program Files\...\Common\IDE\Remote Debugger\x86\msvsmon.exe
  • C:\Program Files\...\Common\IDE\Remote Debugger\x86\msvsmon.exe /CHILDSERVER 428 "+:4022" {...}

(I suppose this means that the monitoring server is running and that the monitoring server is listening to port 4022.)

I have checked my application: the task manager clearly states that my application is 32-bit, so the x86 "msvsmon.exe" should be the good one.

On my local PC, I try to open a remote connection, but that seems not to work: I use the "Default" Connection type, but in the "Find ..." dialog box in the "Remote Connections" window, I have tried different possibilities:

  • 10.39.50.50
  • 10.39.50.50:4022
  • Address:"10.39.50.10"
  • Address:"10.39.50.10:4022"
  • Address:"10.39.50.10":4022

=> after refreshing, all those attempts resulted in "Showing 0 of 0 connection(s)"

I have opened a Developer Command Prompt for VS 2017 and I've typed ping 10.39.50.10, which clearly showed results (this is normal as a I have an RDP session open to that machine).

I believe that remote debugging uses some other "communication channel" than regular TCP/IP, which means that I need to alter the communication between my local PC and that remote one, but which "communication channel" and which command can I use (next to ping) in order to check the availability of the communication?

Further debugging: I have created (and deleted afterwards) the mentioned firewall rule, but now I'm dealing with following error message:

Unable to connect to the Microsoft Visual Studio Remote Debugger
named '10.39.50.10:4022'.
The Remote Debugger was unable to locate a resource dll 
(vsdebugeng.impl.resources.dll).
Please ensure that the complete remote debugger folder was copied 
or installed on the target computer.  

Searching for this file on the remote computer gives following result:

C:\>dir /S /B vsdebugeng.impl.resources.dll
C:\Program Files (x86)\Microsoft SQL Server Management Studio 19\
Common7\Packages\Debugger\1033\vsdebugeng.impl.resources.dll

=> Why is that file not found?

(I've checked and the msvsmon.exe processes are running as administrator (Elevated="Yes"))

Dominique
  • 16,450
  • 15
  • 56
  • 112
  • 1
    It uses standard Tcp/Udp you may find something in the [firewall](https://learn.microsoft.com/en-us/visualstudio/debugger/configure-the-windows-firewall-for-remote-debugging?view=vs-2022) configuration that gives you hints why you can't connect. Additionally when using a VPN make sure your routing for that port actually goes through that VPN. – Ralf May 15 '23 at 07:38
  • You can check the availability of the connection using `telnet 10.39.50.10 4022` or by using PowerShell's [Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection?view=windowsserver2022-ps). – John Wu May 15 '23 at 07:44
  • `Test-NetConnection 10.39.50.10 -Port 4022` reveals (amongst others) `InterfaceAlias : Ethernet 7`, `SourceAddress : 10.24.5.60`, `TcpTestSucceeded : True`. I believe this means that the connection is ok. But what do I need to do in order to debug remotely? – Dominique May 15 '23 at 08:05
  • @Ralf: how can I know if I go through the VPN or not? (I didn't even know it was possible not to pass through the VPN) – Dominique May 15 '23 at 08:07
  • If "Ethernet 7" in the test above is your Adapter for the VPN then you know it uses the VPN. Windows has routing tables that defines what Adapzter to use for what IP Range. On a commandshell you can look at them via "route print" presumably there is a equivalent Powershell command. Had you taken a look at the firewall setting on the remote machine? – Ralf May 15 '23 at 08:27
  • @Ralf: thanks for your support. The remote machine belongs to a customer, so I don't dare altering their firewall settings. I've asked the customer making the necessary modifications, we'll see how it goes further. – Dominique May 15 '23 at 08:47
  • @Ralf: I can confirm that "Ethernet 7" is indeed the adapter for the mentioned VPN (I checked `ipconfig` results). – Dominique May 15 '23 at 08:48
  • @Ralf: apparently the Firewall setting is not a problem, but there seems now to be a problem with "vsdebugeng.impl.resources.dll". – Dominique May 15 '23 at 09:07
  • That belongs to localization. Has the customers machine some special or uncommon culture settings? – Ralf May 15 '23 at 09:16
  • @Ralf: The customer has English (United States) as regional format, while I'm working with English (United Kingdom). – Dominique May 15 '23 at 09:36
  • @I've replaced United Kingdom by United States, but the problem remains. – Dominique May 15 '23 at 10:01
  • @Ralf: in my Visual Studio options, "Environment", "International Settings", the language is set to "English". – Dominique May 15 '23 at 11:40
  • @Ralf: On the remote machine, the directory "C:\Program Files (x86)\Microsoft SQL Server Management Studio 19\Common7\Packages\Debugger" contains three directories: "x64", "Visualizers" and the "1033" directory, which I believe is responsible for the English language handling. – Dominique May 15 '23 at 11:43
  • Don't understand what the remote debugger has with the Management Studio. – Ralf May 15 '23 at 11:44
  • @Ralf: I don't know either, I have the impression that this is just the location of the "msvsmon.exe" process, seen that the remote machine does not have a Visual Studio installation. I don't think that this is a big deal, as there are plenty of other VS debugger related files present in those directories. On my local PC, I have "msvsmon.exe" files both in my VS and in my SQL-Server Management directories. – Dominique May 15 '23 at 11:52
  • @Ralf: also, when I look into the "msvsmon.exe" "Visual Studio 2017 Remote Debugger" window, it starts with sayin "Msvsmon started a new server named '...:4022': Waiting for new connections.", followed by some "Failed attempt to connect from "Domain\username".", so I guess the `msvsmon.exe` running process is found. – Dominique May 15 '23 at 12:09
  • On the remote machine, msvsmon.exe has version "15.0.28307.421", language "English (United States)". On my local machine, I'm working with Microsoft Visual Studio Enterprise 2017, version 15.9.54. – Dominique May 15 '23 at 15:04

1 Answers1

1

Apparently, you can't rely on the "msvsmon.exe" installation, based on SQL server management studio:

On my computer, Visual Studio is installed, and hereby I can find "msvsmon.exe":

C:\>dir /S /B msvsmon.exe
C:\...\Microsoft Visual Studio\2017\...\Common7\IDE\Remote Debugger\x86\msvsmon.exe

The resources library:

C:\>dir /S /B vsdebugeng.impl.resources.dll
C:\...\Microsoft Visual Studio\2017\...\Common7\IDE\Remote Debugger\x86\1033\vsdebugeng.impl.resources.dll

In other words: the "1033" (English locale) directory is stored under the "x86" directory where "msvsmon.exe" can be found.

On the remote computer, "msvsmon.exe" was installed under SQL Server Management Studio, which have another structure (which is wrong):

C:\>dir /S /B msvsmon.exe
C:\...\Microsoft SQL Server Management Studio 19\Common7\IDE\Remote Debugger\x86\msvsmon.exe

C:\>dir /S /B vsdebugeng.impl.resources.dll
C:\...\Microsoft SQL Server Management Studio 19\Common7\Packages\Debugger\1033\vsdebugeng.impl.resources.dll

Apparently, "msvsmon.exe" looks into the "1033" subdirectory in order to find the resource dll, so that entire directory needs to be copied:

C:\>dir /S /B vsdebugeng.impl.resources.dll
C:\...\Microsoft SQL Server Management Studio 19\Common7\IDE\Remote Debugger\x86\1033\vsdebugeng.impl.resources.dll
C:\...\Microsoft SQL Server Management Studio 19\Common7\Packages\Debugger\1033\vsdebugeng.impl.resources.dll

The one, found after the whole "1033" directory has been copied under the "msvsmon.exe" directory, solves the problem.

Extra information: where does the 1033 come from?

This URL mentions the link between Visual Studio's language setting and the value of the mentioned subdirectory.

Dominique
  • 16,450
  • 15
  • 56
  • 112