We’re encountering an issue on some Windows 11 machines where the call to:
FDisplayMetrics::RebuildDisplayMetrics(DisplayMetrics)fails to return any monitor information.
Upon investigation, it appears that the underlying call to GetMonitorsInfo, which uses EnumDisplayDevices, does not return any display data. This occurs despite the fact that:
A monitor is physically connected via HDMI (through a switch),
An HDMI dongle is connected,
The monitor is functioning correctly and displays our application as expected.
We also tried replugging and also completely removing the dongle/the HDMI cable, but the issue still occurred.
Has anyone experienced a similar issue or have insights into what might be causing this?
Do you mean that EnumDisplayDevices returns 0 on the first call or that no found devices is using the DISPLAY_DEVICE_ATTACHED_TO_DESKTOP StateFlag?
It would be useful to get more details on the application and the problems that this is causing at runtime.
Which display mode is used? Fullscreen/Windowed/WindowedFullscreen
What effects are you seeing on the application side?
Can you share the log?
One thing that might be related to the problem is the Windows SDK used when compiling the application executable. Version 5.4 is looking for version 19041 of the Windows SDK which corresponds to Win10. UBT will look for that SDK and use it if it’s installed. It will default to the most recent version if not there. You can search in the compilation logs for a line that starts with “Using Visual Studio…” which logs the toolchain and Win SDK being used to compile\link the exe. We moved to version 22621 (Win11) at 5.5 so that problem might go away when you upgrade if related.
You might be able to use 22621 with 5.4 although I can’t remember if the code is compatible. The easiest is to uninstall older Windows SDKs. It can also be forced though a BuildConfiguration.xml. I can share an example if you need it.
The information for the toolchain and SDK that the version are using is stored in a file named Windows_SDK.json in the Engine\Config\Windows folder.
Thank you for your response and apologies for not being clearer in my initial post.
The issue we’re encountering is that the body of the while loop:
while (EnumDisplayDevices(0,DeviceIndex,&DisplayDevice,0))does not execute even once.
After further investigation, it appears this is entirely a Windows issue (which we somewhat expected), but we were initially hoping you might have some additional insight.
We’ve observed that remotely accessing the affected machines seems to disrupt the display information in the Windows session, and this disruption persists until the machine is accessed locally again. Initially, we weren’t sure if the remote connection was the root cause, since the issue continued even long after disconnecting—but in the end, it turned out to be directly related. Fortunately, we seem to have found a way to circumvent this issue in Windows.