RDM multi-monitor selection inconsistent between sessions

Hello,

Thank you for contacting us regarding this matter.

While we are conducting tests on our end, could you please let me know your RDM version and the type of data source you are using?

Additionally, could you clarify your screen setup? For example, is screen 0 positioned on the left, screen 1 in the middle, and screen 2 on the right?

Best regards,

Sure.

The RDM version is 2025.1.29.0 64-bit (.NET 9.0.3)

I am connecting to Windows 11 Pro via RDP.

In the local machine (doing the connecting), also Windows 11 Pro, the screens are numbered 1, 2, 3 from left to right. Screen 2 (in the center) is the main display.
In RDM, the screens are numbered 0, 1, 2 where screen 0 is the main display. Screens 1 and 2 seems to switch mapping.

Hello,

Thank you for your response.

We’ve been able to reproduce the issue using the latest RDM version (2025.1.31.0) and have reported it to our development team.

I’ll follow up with you as soon as I receive an update from them.

Best regards,

Hello,

Thank you for your patience.

Could you please update Remote Desktop Manager to the latest version (2025.1.37.0) and let me know if the issue persists?

Best regards,

Thanks for following up. Yes, at least one of the problems still persists with version 2025.1.37.0 64-bit .NET 9.0.3. I have been running that version for a couple of days.

Minimizing and then restoring a full-screen dual-monitor guest on a three-monitor host still restores the guest to the wrong monitors. It is fixed by restoring down and then maximizing the guest.

I have yet not tested the issue where the monitors change number and order when the host comes out of sleep.

Hello,

Thank you for your response.

We are continuing to investigate this issue and will get back to you as soon as possible.

Best regards,

Hello,

The issue you're experiencing is an mstsc issue and is unfortunately outside of our control. We pass information to the Remote Desktop connection module, and once launched, we can no longer make modifications to it. I've managed to replicate your issue directly by using an RDP file (without using RDM. Here is a link if you're interested https://www.hanselman.com/blog/how-to-remote-desktop-fullscreen-rdp-with-just-some-of-your-multiple-monitors).

The parameters in the link above are essentially what we are doing when passing the information through RDM. We have no other control on how it handles the screen placement from there.

If there is anything else we can help you with, or if you have further questions, please let us know.

Regards,

Thanks for following up. I am experiencing two issues that I thought could be related. Are you saying that both are mstsc issues and beyond your control?

1. RDP screens show up on the wrong monitor after minimizing and restoring. I can understand that this is an mstsc issue.

2. Screen numbers change after sleep or reboot. I sometimes need to reconfigure RDM to use monitors 0,1 or 0,2 or 1,2 after sleeping or rebooting the host. I had one occasion where RDM numbered the monitors as 36, 37 and 38 in the monitor selection dialog. I had to hand-edit the monitor selection to 0,1 for RDM to use multiple monitors. Are you saying that this is also an mstsc issue?

Hello,

The specifics of "re-assigning/not remembering" the correct monitor after sleep/minimizing are the problems I investigated and are the ones caused by the mstsc issue. (So #1, and part of #2 where setting the Host to Sleep then prompts the incorrect monitors upon waking).

However, the issue you are mentioning where RDM detects the monitor selection as 36, 37 and 38 (if I understand correctly, you are referring to the selection made in the DIsplay tab of the RDP entry's properties) is not something I was aware could happen (unless you had 38 monitors connected). This numbered selection is not something we generate ourselves, we simply fetch the monitors detected by your computer, as well as their assigned index. (meaning that when this happens, if you verify the display options by right clicking your desktop and going into Display settings, their assigned number by Windows should be the same as the one detected in RDM).

If I understand correctly, you're saying that the Monitor selection window provided 3 monitors, indexed as 36, 37 and 38, and you had to instead manually input the numbers 0,1 in the textbox (outside of said selection) for it to work? To populate the Monitor selection window, we simply use the native Windows API that gives us the general settings all detected screens. The numbers displayed are directly acquired from those. This provides us with all of currently connected screens DeviceName, which appears as \\.\DISPLAY? (replace the ? for the index of the display) This index usually starts at 0, and increments with each display. We use this information to provide monitor selection (we don't assign them a number ourselves) and we generate this list at the moment that you prompt the Monitor selection window, not before. If your OS is somehow incrementing your display indexes by itself, this would explain the issue you experienced. The "0,1" that you input manually is the information that mstsc is expecting, and we have no control over that.

If you are interested, we could try troubleshooting this issue (with your help). I don't know if this will lead to a fix, but it might provide insight into what is causing it, and there is a chance some modifications to your setup/environment could solve the problem. As an example, the issue could possibly with your Windows version, or it is possible that your specific monitors (or the specific dock you are using to connect them to your computer, if any) are somehow no longer recognized when the computer enters sleep mode (perhaps because of some battery saving setting, or the make/model of the monitors), and that waking up the machine results in an increment of the monitors "selection index".

Ideally, we would need to able to properly replicate this issue to trouble shoot it. If you can find a way for it to happen consistently, we can investigate the issue.

Regards,

Thanks for the explanation. Windows multi-monitor support has always been a bit fragile, so I guess I should not be surprised. The problem is irritating, but not show-stopping. I'll keep an eye on it and see if I can identify a reliable reproducible case, at least on my machine. I get back to you if I can.

For reference:

• O/S is Windows 11 Pro 24H2 (26100.4061)
• I am not using a dock - all monitors are plugged directly into the video card
• Yes, I saw 3 monitors, numbered 36,37 and 38 in the "Monitors Selection" dialog when I clicked the "..." beside the monitor selection entry field. It has only happened once.
  • Yes, I had to type 1,2 into the entry field adjacent to the "..." button.
  • Your guess that I don't have 38 monitors was correct.
  • When I saw 36,37,38, Windows identified them as 1, 2, 3 from the Display Settings -> Identify button
• When the machine reboots, the monitor arrangement, scale and resolution are retained for all monitors, so it doesn't look like Windows is forgetting about them.

I appreciate your willingness to try to track this down, and I know that you can't diagnose it without a reproducible case. Leave it with me and I'll come back if I can identify a way to investigate further.

I wrote a little program with the help of GPT 4.1 that queries all the attached monitors and lists their properties. It had no problem finding the "\\.\DISPLAY?" entries and listing their positions and resolutions. However, when I asked it to produce the monitor ID, it was not able to do it.

• It tried parsing \\.\DISPLAY?? to get the ID, but I was able to show that it was not necessarily valid. For example, on my RDP session the displays are DISPLAY161 and DISPLAY162. I'm sure my encounter with 36, 37 and 38 is similar, for whatever reason.
• It tried just using the order in the return from EnumDisplayDevices, claiming that the monitor ID is just a sequence number starting from 1. That seems plausible, but it incorrectly called my main monitor 1, when Windows calls it monitor 2, so that clearly isn't it.
• It tried using Win32 calls EnumDisplayDevices, GetMonitorInfo and EnumDisplayMonitors and then comparing the results from those with each other to identify the order that the displays appear in the enumeration. It claimed that the monitor ID is a sequence number derived from comparing those enumerations, but was not able to make it work.
• It claimed that there is no publicly accessible API in Win32 that produces the monitor IDs that match what Windows produces.

The outcome of all this is that the monitor IDs appear not to be defined or accessible. Parsing DISPLAY? is not the answer, and neither is the order of the return from EnumDisplayDevices. There is no point in pursuing this further. Thanks for looking into it.