We have received similar reports but never got any feedback from the reporting users. Unfortunately, even when attaching three screens to my PC, I cannot reproduce it, but given that you encountered the problem on two different machines using that configuration, maybe you can give some more information on the setup:

• What are the resolutions and DPI settings of the individual sreens?
• How are they positioned relative to each other?
• Which one of them is configured to be the primary screen?
• On which screen did you place OpenMPT? Does the problem go away when placing it on a different screen?

Are both setups on Windows 11?

What may also help us is a memory dump of the frozen application. Open Task Manager, right-click the OpenMPT entry and choose "Create dump file". This file will be very large but compressing it as .7z or .rar should get the size down by quite a bit. If you have a place to share the file, it would be very interesting to look at it.

The Home setup has 3 screens, all with the same resolution 1920x1080. (100% Scaling)
They are set op next to each other.
The Middle screen is the "Main display" (See -> Screen_Setup_Home)

The Work environment has a Surface Laptop, 2496 x 1664 and 2 HD (1920x1080) screens setup on top of the Laptop screen. A little like Mickey Mouse Ears. (the 2 HD screens are Next to each other)
I don't have that environment available at this moment so I've made a simulation of the setup (see work_setup_simulated).

At the time of reporting the main OpenMPT window was on the rightmost monitor. (Monitor 3 on Screen Setup Home).
I can't move the window because the OpenMPT screen is unresponsive.

Now for the kicker; As I already installed the latest version after the screen unfroze after a few minutes (It automatically downloaded a RETRO version by the way), I couldn't reproduce the error.
So I downloaded an older version, uninstalled the latest and reinstalled the old version. IT only shows the balloon sometimes, but... it was correctly placed, both on Screen 1 and Screen 3. So Uninstalling and reinstalling did do the trick for now as it did happen before (I have the screenshots to prove it ;-) )

I will create a memory dump on my work setup on Friday when the process hangs there.

screen_setup_Home.png (16,803 bytes)   

screen_setup_Home.png (16,803 bytes)   

work_setup_simulated.png (2,892 bytes)   

work_setup_simulated.png (2,892 bytes)   

One thing you could try with your home setup is checking if there are any shadow copies of OpenMPT's setting file, and if reverting to that shadow copy would provoke the same issue again. To do that, go to Help -> Show Settings Folder, right-click on mptrack.ini there and check if under "Restore previous version" you see an older copy of the file. Maybe make a copy of the current file and then restore the older file, and see if the problem happens again. If so, it would also be interesting to have a look at that INI file.

Also, please try to keep the installation on your work machine in a broken state, e.g. by backing up all of OpenMPT's settings files to a different folder. I might have to create some special test builds for you to test a few things.

Unfortunately no shadow copies exist for my home PC.
I will keep the work laptop in "broken" state and send you the memory-dump on Friday when I'm in the office.

Unfortunately I was unable to replicate the exact issue on my work PC at this time.

The UPDATE dialog is malformed, but does not "hang" the client at this time (See Attachment);

I did create a DMP file, maybe it helps, maybe not. When the issue occurs again, I will create another DMP file.

The DMP can be downloaded until the 8th of August at: https://wetransfer.com/downloads/b9ff280dfdd758229e7256e88c2cee8520230801095409/1959f094036685385ca857ed80b1d84c20230801095432/fc6cb1

image.png (22,347 bytes)   

image.png (22,347 bytes)   

That's really odd. Unfortunately the memory dump also doesn't provide any clues in this case. If you find any other way of reproducing the issue, it would be really helpful. In the meantime I also tried this in a Windows 11 VM and it also didn't happen there with three virtual displays.

I think I have finally understood this issue, and your original guess isn't far off: I am finally able to reproduce the problem if OpenMPT was in a minimized window state when it was last open. This window state is restored when OpenMPT starts, and minimized windows traditionally live somewhere around -32000/-32000 in Windows. I guess the Tooltip slowly "travels" from there to a visible screen area (or, as it appears to be stuck in a WM_PAINT call, try to paint that entire off-screen area). Do you think it is possible that OpenMPT was in a minimized when you used it and those hangs happened?

This should hopefully be resolved in r21906. If you notice this happening again in a future update from OpenMPT 1.31.11.00 or higher to a new version, do not hesitate to reopen this issue.

Also, if it happens again, we'll need that mptrack.ini file (it would have solved the mystery in no time :)).