0

This is a follow-up question of this previous one.

I have understood that the easiest way to attach to a remote process, is by adding "IP_Address:Port" into the "Connection target" textbox.

At first, this gives me an error message, mentioning that the problem might be caused by firewall settings. So, on the remote PC, I have added a firewall setting, allowing incoming traffic for port 4022, and now I have following error message:

Unable to connect to the Microsoft Visual Studio Remote Debugger named '10.39.50.10:4022'.
The connection with the remote endpoint was terminated.

The fact that I have another message than the firewall related one clearly shows that the machine is reached and that the new firewall setting is taken into account.

What else can cause this error message?

Screenshot on my local machine:

enter image description here

Screenshot using RDP for the remote machine:

enter image description here

Now I'm back at this error message, which is the same as in the previous question:

enter image description here

Does anybody know how language settings are managed over remote debugging sessions?
One thing might be interesting: on the remote machine, the monitor's screen mentions Failed attempt to connect from Domain\Username.

A remark about the duplication: the answer on the mentioned duplicate mentions I should start up the monitor as administrator. This has always been the case already, so this does not solve my question.

Extra information on files on the remote machine:

Hereby some information on the used files (I can confirm that the "msvsmon.exe" which is running is the "x86" one):

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

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

There is no Visual Studio environment, installed on the remote machine.

On my local machine, Visual Studio's language is English, as you can see here:

enter image description here

Dominique
  • 16,450
  • 15
  • 56
  • 112
  • If you run the remote debugger UI it should offer to open up the firewall for you. That should allow you to just use the "find..." button to locate the remote PC. That worked fine for me, at least on a regular corporate network. – JonasH May 16 '23 at 10:00
  • @JonasH: at first there was an error message, mentioning the firewall. Afterwards, I created an incoming rule, letting traffic come in for port 4022. Now I don't have the firewall error message anymore, but the one, mentioned in my question. – Dominique May 16 '23 at 10:11
  • @JonasH: Now I have the same error message as I had before (in the previous question), I've adapted my question accordingly. – Dominique May 16 '23 at 11:12
  • 1
    @Jonas it would appear they've blanked that single number out in Paint or whatever, giving us only 9 guesses at the entire IP, if it weren't local. – CodeCaster May 16 '23 at 11:15
  • @CodeCaster: indeed, you're right. I'm afraid the customer wouldn't like seeing his IP address on some public website, hence the obfuscation. I can confirm you, however, that the remote machine gets reached, as an extra message is shown in the monitor's window, as mentioned. – Dominique May 16 '23 at 11:17
  • This question is not a duplicate, as the mentioned other question's answer does not solve my issue. Please help me re-opening my question. – Dominique May 16 '23 at 11:21
  • Guys, I have solved the question, but as this question has been closed already, I have written the answer under the previous question (https://stackoverflow.com/questions/76251735/attach-to-process-to-a-running-process-on-a-remote-pc). Please remove the current duplicate reference and replace it as a reference to the previous question. – Dominique May 16 '23 at 12:31

0 Answers0