UI crash when starting on second monitor

[W0D1N]

Seems since latest Windows updates or since i got my new pc i get this weird issue with simc:
When i open Simc on my second monitor Simc crashes (program is not responding).
If i open Simc on my main monitor it works ok. Seems like a weird second screen bug or incompatibility?

SimulationCraft Version (required):
Nightly Build 830-02 x64

PC Specs:
AMD Threadripper 3960X
ASUS Zenith II Extreme
G.Skill TridentZ Neo 64GB 3600 C16
Samsung EVO Plus 970 1TB
Nvidia 2080 Super with latest drivers

Monitor 1 (main): Asus ROG PG278QR @ 144hz
Monitor 2: (second): Asus VG248QE @ 144hz
Windows 10 1909 18363.657

[jazz836062]

I am getting this as well. I pulled this from Reliability Details:

Problem signature
Problem Event Name: AppHangB1
Application Name: SimulationCraft.exe
Application Version: 0.0.0.0
Application Timestamp: 5e431e64
Hang Signature: 58ba
Hang Type: 134217728
OS Version: 10.0.18363.2.0.0.256.48
Locale ID: 1033
Additional Hang Signature 1: 58baca757fa647a708f618c7797d55bb
Additional Hang Signature 2: fa79
Additional Hang Signature 3: fa79f0d1beb6bd7fbd7cd6887d54c8bc
Additional Hang Signature 4: 58ba
Additional Hang Signature 5: 58baca757fa647a708f618c7797d55bb
Additional Hang Signature 6: fa79
Additional Hang Signature 7: fa79f0d1beb6bd7fbd7cd6887d54c8bc

I hope that helps. Very strange error.

[navv1234]

We don't do anything specific with a second monitor with the GUI program. I suspect this may be an issue with Qt instead. Does it crash if you open it on the first monitor and drag it to the second one?

[jazz836062]

It does not crash for me when I drag it to the second screen. Only becomes non-responsive when it tries to start on the second monitor.

[scamille]

Can you please try the latest nightly from http://downloads.simulationcraft.org/?C=M;O=D and also try to get updated graphic drivers if there are any available.

I am not sure if the QT version we use for nightly builds has changed since February, but there might have been some fixes for it.

[jazz836062]

I have tested the 8.3 version and 9.0 version (Nightly build as of 9/24/2020) and both work correctly. Instead of starting on the secondary monitor (where it was closed) it started on the main monitor. No crash and no hang up.

[scamille]

Thanks for the response. I guess this "fixes" it for now, and you are at least able to use it, even if you have to drag it to your other monitor manually :-)

The GUI is definitely not the most loved thing around here, but it usually works somehow. Maybe it will at some point also get better, modern DPI scaling, but that still does not seems to be that easy to pull off with the QT 5.12 LTS release we are using.

[LBerlin]

This seems to have returned with/around the 1005. version. Specifically some time after simc-1002.01.afae166-win64.

Whenever I open the GUI now, it returns to the monitor it was on when it was closed. If that was not my primary monitor, the GUI crashes and is unresponsive.

As a workaround when this happens, I have to open a 1002. version from my primary monitor, which will correctly open on the primary monitor, and then I close it. After that the 1005. version opens on the primary monitor without crashing.

Referenced versions:
simc-1005.01.4362f3a-win64
simc-1005.01.db9b48b-win64
simc-1002.01.afae166-win64

[scamille]

Hmm this might be related to the change in 0c6e3b7#diff-140dc95833e80589c6899abed8501ef8f6cf2a945dd0305bb2117a10728493fe which added the setGeometry(savedApplicationGeometry); call in line 115.

I'll investigate once I have some time available.

[scamille]

I disabled restoring the UI position in 6fd46d3 again. Should be included in the next nightly.

That doesn't really solve the underlying issue here, but should at least restore the workaround of being able to just start SimulationCraft on your primary monitor if you happen to be afflicted by this issue.

[LBerlin]

Seems to have returned some time after the 20230321 nightly.

The workaround I described previously isn't working now either. When I open from simc-1007.01.3652387-win64 the GUI opens on my main monitor regardless of where it was previously. The next most recent build I have is from 20230327; that and any later builds are opening on the secondary monitor and freezing, regardless of what monitor the previous window was closed on.

[LBerlin]

Aside from the previous workaround not working, there's another notable new behavior observed. The window seems to remember what region of the monitor it was snapped to but applies it to the wrong window. That is, if I

1. open the GUI of an older, working build
2. snap it to the side or corner of my primary monitor
3. close it
4. open the GUI of a current, bugged build

then the bugged window still tries to open on the secondary monitor, but it snaps to the same region as the previous window, just on the wrong monitor.

Windows 10 21H2
RTX 2080 super (driver 531.41)
2 displays