Fetch debugger port number from running game code

Unity Engine
,
1

Hello,

Is there any way to fetch or calculate the debugger’s port number from within the application’s code?
Visual Studio > Attach Unity Debugger and the Profiler in the Unity Editor can fetch this port, how do they do it?

I am trying to show the debugger port in the title bar of the running standalone application. While debugging / profiling, often multiple running instances of the game are needed, and it is difficult to identify which running instance is the target for debugging or profiling since they cannot be differentiated from each other and matched to the list of processes in Visual Studio or the Profiler.

I found this thread, but the solutions mentioned here do not seem to apply. The port numbers I see are 55000 and upwards, while the calculation there is upwards from 56000. There also does not seem to be any usable log output. UWP IL2CPP debug port number?

There was this thread also, but no response. get debugger listening port from code

Any help appreciated.

I have tried the following since posting:

  • Enumerating all ports in use and matching associated PID to the application PID; there is no way to tell which port is the debugger port, I am left with multiple possible ports.
2

Unity player will broadcast its presence via UDP multicast message (on IP 225.0.0.222, ports 54997 and 4597). That message contains info about the player, including the port the debugger is listening to.

1 Like
3

Thanks! I think I remember seeing something like this in the source code for the Unity extension for Rider.

It’s unfortunate something as complicated as this is required just to get the debugger port from the process it belongs to. Would there be there interest in exposing this through e.g. Application or some other class? The debugger port is used between a couple of editor tools and it’s very hard to match running instances to the list of instances in these tools (e.g. Profiler in the Unity editor does not report PID, and the extension in older versions of Visual Studio does not report PID either)

Something else concerning however is that I’ve noticed the Profiler in the Unity editor, and in the Visual Studio > Attach Unity Debugger menu report different ports for what should be the same running instance. Is one of these incorrect, or are there multiple possible debugger ports? If these are inconsistent this makes it much harder and perhaps impossible for me to show relevant information to help match running instances to the list of instances in both the Profiler and VS.

4

Let me pass the feedback to the relevant team.

Profiler and debugger uses different ports. You can have both attached at the same time too!

1 Like
5

That’s good to know! Does the Unity player broadcast the Profiler port in the same way?

Really appreciate it, thanks! It would definitely be useful for these to be exposed to the running process when available, or at the very least for the Profiler in the editor to report PID in addition to the port. I can ask people to update Visual Studio to see the PID and solve half of my problem, but that still leaves the Profiler only identifying running instances with the port and machine; to solve the problem here I would still need to write the entire listener.

6

Hi,

There is an update coming to 2021.2 that allows for setting a custom id string from the Profiler Preferences to help identify builds. Additionally, the Product title, IP and port will be listed and the entire connection drop-down can be search filtered.

In which way? C:\Users<username>\AppData\LocalLow<yourCompanyName or DefaultCompany><projectName>\Player.log should exist and contain a line with the Multi cast info (look for Multi-casting), including the port.

Also, you could look into the MonoDevelop code to see how to handle and parse the Player info from the multicast message.

Exposing the profiler/player connection port in the player itself (or possibly showing PID in the connection drop down) is a valid proposition though and I’ve added it to our feedback backlog :slight_smile:

7

Good to hear about those changes for 2021.2, that sounds like a good step forward. It would just take us a while to get to that early of a version since we’re on LTS.

I wasn’t aware player logs went there actually, we have different logs going out somewhere else and it looks like that’s what I was looking at, so that’s very helpful. I don’t know if I can read this file from the player while the player is also writing to it (another user mentioned they could not do this), so I will have to experiment, but this sounds promising.

Otherwise, that source code looks a lot more useful than what I found, definitely a good reference for writing the listener if I have to, thank you.

Thanks for noting this in the backlog!

1 Like
8

Hello again,
unfortunately I’ve been trying to get this multicast listener working, but it looks like calling IPInterfaceProperties.GetIPv4Properties() like the monodevelop code does (and all other code that does this) results in the application crashing immediately with nothing logged. This looks like it might be an issue with Unity?

I found this, but the symptoms are slightly different from me (I am using mono and not il2cpp, the crashes also happen in editor) on Unity 2020.3.6f1.

I can’t seem to find a workaround for this so I am starting to think I’m blocked. Any advice is appreciated.

I cannot look at logs because when you run multiple build processes, player.log gets overridden.

Nevermind, it looks like I have it working, I switched from iterating nics to just passing IPAddress.Any instead of the nic index.

1 Like
9

This exactly. It would help so much to just have the port in the title bar (or accessible from code so we can display it on the UI somewhere at least).
A more detailed list in the profiler or a compile-time set identifier won’t help much if you run the same compiled game multiple times at once. Still need to open the log each time to identify which window uses what debugger port.

Any chance this could be added (i.e. either a way to show it in the window handle bar or allow fetching the port-number from within the game’s code)?

10

You could use this to specify the port Unity - Scripting API: EditorUserBuildSettings.managedDebuggerFixedPort

Then you would know in advance what the port was.

11

To build on Mark’s post above, in newer Unity versions (2021.2+) the Profiler target selection drop down lists multiple process instances of your build with their process ID to help disambiguation.

So with a combination of port defined at Build-time, and PID, this should be solved?

1 Like
12

I could not find any hint on where to set the EditorUserBuildSettings.managedDebuggerFixedPort.
I want to debug our server under a fixed port.

Would you tell me?

13

You’d set it via an Editor script (that you’d need to write) that sets this API to the port you’d want to use.

14

For the next person in line: The following script I put under Assets/Editor.

using UnityEditor;
using UnityEditor.Build;
using UnityEditor.Build.Reporting;

namespace Editor {
  class BuildProcessor : IPreprocessBuildWithReport {
    public int callbackOrder {
      get { return 0; }
    }

    public void OnPreprocessBuild(BuildReport report) {
      EditorUserBuildSettings.managedDebuggerFixedPort = 50000;
    }
  }
}
1 Like
15

By the way, I have noticed that it’s common for Unity to advertise the wrong port. If you ever get stuck and can’t figure out why MSVC won’t connect to Unity, you can run TCPView (from Microsoft) and show what port Unity.exe is listening on. It’s often NOT the same port MSVC is trying to connect to. This is after having first killing all the Unity and UnityHub processes and relaunching Unity and MSVC clean. In my case, I saw Unity connecting to 0.0.0.0:56190 and MSVC says:

No connection could be made because the target machine actively refused it 127.0.0.1:56188

Which is clearly wrong.

1 Like