WinSCP UI collapse & 100% CPU when monitor/display disconnects while WinSCP is running

When WinSCP is running and the display device is disconnected (monitor powers off, unplugged HDMI/DisplayPort cable, or when whatever event temporarily removes the monitor – such as something like "Samsung Display Optimization" kicking in without asking, which was the latest for me), the application window collapses into a tiny unreadable frame and CPU usage on one of the cores spikes to 100%. If there were transfers underway, they continue in the background, but the UI becomes unusable/unresponsive until WinSCP is forcibly killed.

Likely WinSCP is not handling missing primary display correctly. Possibly related to unhandled WM_DISPLAYCHANGE or WM_DEVICECHANGE messages in the UI thread?

OS: Microsoft Windows 10 Enterprise LTSC (x64) Build 19044.6218 (21H2)
WinSCP v6.5.3 (Build 16364 2025-07-16)
GPU: Geforce GTX 1080
Screen: Samsung Odyssey G8 32" 4K OLED (but said quirk has happened on other screens and other gpus)

Thanks for your report. What is your monitor setup? Do I understand right that you are running WinSCP on a primary external display and your disconnect that. And WinSCP gets moved into the internal display (which is now becoming the primary/only display). What is scaling of both displays?

martin wrote:

Thanks for your report. What is your monitor setup? Do I understand right that you are running WinSCP on a primary external display and your disconnect that. And WinSCP gets moved into the internal display (which is now becoming the primary/only display). What is scaling of both displays?

A desktop computer with single screen which is attached to Geforce 1080, cpu built in graphics disabled. There is no permanent screen that's not going anywhere, as in laptop.

Problem somehow relates to how Windows 10 (and probably 11) no longer has "virtual graphics adapter" inside it as Windows 7 and earlier used to have. When the primary (and only) screen is gone, it's now "headless", and operates in little unusual ways. This becomes evident with various remote desktop tools, such as VNC and its many variants. I found it necessary to install HDMI dummies (simulating connected screen with various screenmodes available) into my headless boxes, which would not play ball in any other way. What seem to be hardware accelerated surfaces, no longer draw (so they remain blank), because there's nothing to draw on. Despite the GPU still being there.