Crash on startup when program is moved to other screen then closed

[lllIIIllII]

• What happened?
  Application crashed after the initial startup console
• What were you trying to do?
  launch the application
• What steps will reproduce the bug?
  execute the .exe file
• Does it reproduce every time? If not, why so?
  every time, windows tells me it's not responding anymore
• Additional information:
  I had just downloaded the most recent version a few hours ago. The first start of the application after a reboot works but once i close it it keeps crashing on startup. Putting windows into sleep mode and starting it back up doesn't resolve the issue. Only a hard reboot does.
  Uninstalling doesn't work anymore because the process is still running in some way.
  Task manger won't show it but running "tasklist" still shows a "Path of Building.exe".
  Killing that process via taskkill worked one time but the issue of the application crashing was still there.
  I didn't find a log of the startup console but after the "loading 3.11..." lines there were some "xyz is missing" lines in there (log was moving too fast and closed right after those lines).

[ghost]

for the time being, until this is fixed, use the portable version (zip archive!)

[BWRStennett]

If you use two monitors, this description for "working once, then crashing on subsequent attempts" seems similar to a problem I'm experiencing (and used to experience with the Openarl version):
Openarl/PathOfBuilding#336 (comment)

If I close PoB while it's on my second monitor, subsequent attempts to open it default to opening it on the second monitor, and PoB throws a memory access error, then hangs without responding to attempts to close it (except through task manager).

As in the link above, deleting a line in the Openarl version's Launch.cfg prevented PoB from remembering which monitor it was on last time, working around the problem, but I see no such Launch.cfg to edit for the fork and see if it's the same issue.

For now, remembering to move PoB back to my primary monitor before closing it avoids the problem, but if I forget it'll require a reinstall unless I can find where the fork stores the set vid_last line. Apologies if this is a different issue from above.

Edit: And of course if I'd taken two more minutes on my own, I'd have found it:
C:\ProgramData\Path of Building Community\Launch.cfg. Deleted the set vid_last line, marked the file Read Only, PoB Fork version now opens on primary monitor each time even after being moved, just like the workaround for Openarl version.

[lllIIIllII]

Yeah i'm running a triple monitor setup and usually move PoB around. I'll try this one, thanks for the suggestion

Edit: Unfortunately this didn't help. Even after removing the line and putting the file to read only it still goes black after startup and doesn't respond anymore. I can however close it the traditional way (don't need task manager) so this might be a different issue.

[lllIIIllII]

for the time being, until this is fixed, use the portable version (zip archive!)

downloaded and tried using the .zip version but this one doesn't even work on first startup. I get the usual startup console, it reads Unnamed build(Scion) at the top and screen is black and goes into "not responding" when i try to interact with it

[skolazbynek]

I have the exact same issue here. I've used both .exe and zip archive, same result.

I was using the .exe installer about two or three days earlier and it has worked without problems.

Edit: After restarting, which updated windows, and removing Path of Building folders from AppData, the issue is gone.

[LocalIdentity]

This should have been fixed with the new installers from version 1.4.170.4 onwards

[lllIIIllII]

Got the latest installer (1.4.170.4) and installed the latest version but can still cause it to crash with the same pattern.
Open PoB -> Move to different monitor -> close -> open again -> program stops responding after startup console and i also can't move the window back to the original monitor since it won't let me drag it.

[Notty1]

Still getting this issues with Release 1.4.170.16. have tried both .exe and .zip versions.

[dclamage]

@BWRStennett @lllIIIllII @Notty1 @ShiShi-CZ

Could you please try out this updated SimpleGraphic.dll and see if it fixes your crashing issues?
https://github.com/dclamage/PathOfBuilding-SimpleGraphic/suites/1899290700/artifacts/37223955

1. Unzip the file to extract SimpleGraphic.dll
2. Replace SimpleGraphic.dll in your PoB installation folder with this new one
3. Run PoB and see if you run into any issues.

PoB will say there is an update, but do not apply it. If you apply the update, it will replace SimpleGraphic.dll with the original version.

Thanks!

[BWRStennett]

@dclamage Thanks for the ping!

I recently came back to PoE for Ritual and uninstalled/reinstalled PoB Community because I was having an issue with updates hanging on updating SimpleGraphic.dll. I don't recall which version PoB installed as, but I'm currently running 1.4.170.25.
I checked the Launch.cfg at \AppData\Roaming\Path of Building Community and the set vid_last line is present and the file is not marked Read Only, so my previous work-around seems to no longer be present for this installation of PoB.

I can close PoB while it's on my second monitor and relaunch it without any crashes so far. When I launch it now, the SimpleGraphic console briefly appears on whichever monitor I click the shortcut on, and after the console finishes its preparations, PoB launches on my second monitor where I had it last. Even with my workaround, it's never successfully launched on my second monitor before. Preliminary results would seem to suggest that my issue mentioned above has been fixed sometime since I took a break from PoE back in early Heist league. I'll have to wait for another update to confirm my update hanging issue is fixed, but even if it isn't, that's likely a separate issue from this topic.

For clarity, I haven't updated my SimpleGraphic.dll as you instructed above, but if it would help your diagnosis at all to run it even when my issue seems to be fixed, let me know.

[dclamage]

@BWRStennett Thanks for the reply. I would be grateful if you could run a quick test with the dll I provided, as I want to make sure it doesn't re-introduce the crash you were experiencing. It shouldn't, but I have no way to test it myself, so I want to make sure.

Thanks!

[BWRStennett]

@dclamage

I downloaded your SimpleGraphic.dll, replaced my own (after making a copy), and launched PoB from the shortcut on my first monitor. The SimpleGraphic console appears on the first monitor, but because I last closed PoB on my second monitor the main window tries to open on the second monitor, and then I get an APPCRASH. Of note, this crash is handled far more gracefully than before, because Windows recognizes the process has stopped working and I can choose to "Close the program." Previously, I would have to kill the process manually.

I edited my Launch.cfg as I described back in June, so PoB forgot which monitor it was previously on before closing. I also created a second PoB shortcut on my second monitor. Now, I can launch PoB from either shortcut (so, either monitor) and the SimpleGraphic console will appear on the respective monitor before launching the main PoB window on my first monitor without any problem. However, if I move this PoB window to my second monitor and close it, relaunching PoB from either shortcut reintroduces the crash.

Since I've been typing this out, I reset the set vid_last line again and have been playing around with it a bit more: I can resize the PoB window by, say, dragging it to the right edge of my first monitor so Windows resizes it as a right pane on my first monitor. I can close it and reopen it without issue. If I drag it over to the left edge of my second monitor, Windows resizes it, then I pull this newly-resized window back over to the first monitor, close it, and it reopens without issue. But if I drag it such that the left edge of the PoB window is just barely on my second monitor (the window frame ONLY) and close it, it reopens without issue. If I drag it a little further so that the contents of the PoB window frame (the brown background or the stats if you have a build open) are on the second monitor at all, then closing and attempting to reopen PoB causes the crash when it tries to start up.

In summary, your modified SimpleGraphic.dll did indeed reintroduce a very similar crash to what I was experiencing before, albeit a more gracefully-handled error that I can simply close. Upon further testing, the window's frame/bezel is allowed to be on my second monitor when I close it without inducing the crash on next startup, but if any portion of the window's contents appear on the second monitor when I close it, it will crash on next startup.

I have now replaced the modified SimpleGraphic.dll with the standard version I was using (still 1.4.170.25) and run all the same tests without any crashes. Hope that helps!

[dclamage]

@BWRStennett Thanks for the info and detailed response. I'll be looking into this and asking you to try another dll later if that's ok?

[BWRStennett]

@dclamage Sure, I'll try to keep an eye on my email. I haven't been getting push notifications lately, but I check in from time to time.

[dclamage]

@BWRStennett

I have a new dll for you to test here: https://github.com/dclamage/PathOfBuilding-SimpleGraphic/suites/1899290700/artifacts/37223955

Thanks!

[BWRStennett]

@dclamage Great! I made a copy of my SimpleGraphic.dll again before testing it as the control one last time (no issues) and then overwriting it with this one. I thought ahead and deleted the set vid_last line from my Launch.cfg before testing, which brings me to my first note: when the set vid_last line is missing, PoB launches as a maximized window on my first monitor without issue. I then close PoB and it creates a set vid_last line for the stored position, except that the position isn't in the right place.
At this point in the process it reads: set vid_last "1920,1018,320,180,0"
Edit: This seems to only occur if the window isn't moved from its default location. If the set vid_last line is missing and PoB defaults to a maximized window on my first monitor, closing it in this position saves the incorrect position noted above. However, if the line is missing, it defaults to this location, and I manually drag the window down a little before returning it to its maximized position, the set vid_last line saves correctly and avoids the behavior described below. /edit
I launch PoB again and it defaults to a maximized-sized window, but moved down and to the right, so that the bottom and right edges are off the screen.
If I move the window back to its maximized position on the first monitor and close it, the line correctly reads: set vid_last "1920,1018,0,22,1" and subsequent launches have no issue with remembering the correct position. So, just some interesting behavior when the line is missing from the Launch.cfg.
For kicks, I just tested this with my 1.4.170.25 SimpleGraphic.dll as well as the previous one you asked me to test, just in case this behavior exists in other versions and I never attempted it or noticed it before. However, it does not behave this way in either of those versions and simply saves the correct position the first time when the line is missing.
One other thing I've noticed is that in your two versions the SimpleGraphic console appears at the same time as a blank black window for PoB, and when the console finishes loading the black window populates with the expected content. But on my 1.4.170.25 version, the main window does not appear at all until after the console finishes loading.

Anyway, back to your latest version!
Firstly, I can launch, close, and relaunch PoB on my first monitor without issue (aside from the first-time position saving as detailed above).
Next note: closing the window while it's maximized on my first monitor correctly saves the location as set vid_last "1920,1018,0,22,1". A second launch puts the window right back in the same place as expected. A third launch, however gets the position mostly right, except the window is slightly larger now, with the window frame/bezel bleeding off every edge of the monitor. The window controls in the top-right corner to minimize or close the window are slightly cut off and the left edge of the frame is even slightly showing on my second monitor to the left. After closing, the Launch.cfg now reads set vid_last "1920,1018,0,22,0". So far this pattern is repeatable: if the window launched is too large, drag it to be maximized, close, relaunch, and it's still maximized. Close, relaunch, and it's too big again. If I simply let it remain too big when I close PoB, then that doesn't alter the saved location, so it will always be too big. From what I can tell, this larger window isn't large enough for the contents of the PoB window to actually be on my second monitor, so there are no crashes yet.

Now for the actual bug for which we're here:
If I launch PoB, drag it to my second monitor, close it, and reopen, the console appears on the monitor corresponding to which monitor the shortcut is on, the black main PoB window appears on my second monitor as it remembers, then it hangs. Windows is still able to recognize the hanging and allows me to close the program from the prompt rather than killing the process manually. It does save the position (presumably) correctly as set vid_last "1920,1058,-1920,22,1", as the other two versions also do.

Lastly, some things I expect you already know, but which I've not reported before:
These crashes seems to happen consistently at the same line in the SimpleGraphic console: Pixel format: need 32,24,0. The same line in a successful load appears to be Pixel format: need 32,24,0, using 32,24,8. I've attached three screenshots corresponding to my live version's successful console load (not a complete screenshot, since I needed to catch the screen before it finished loading), as well as crashes from your two versions.
Additionally, I've noticed my live version saves its set vid_last line as the last line of the Launch.cfg while yours save it as line 6, after set vid_resizable. I don't suspect this is significant, but those are all the differences I can see from my end.
Edit: If a set vid_last line exists on line 6 already, the live version won't move it to the end of the file, but if no such line exists, the live version creates one at the end of the file rather than in the middle. I did not check for this behavior on your versions, as it's 5 AM and as I mentioned above I can't imagine this is significant. Let me know if you'd like for me to check it anyway. /edit

I should mention at this point that in the course of swapping versions around, I accidentally overwrote my copy of the live version backup I made at the start of testing, so I "updated" PoB in order to get a fresh copy. I don't expect there is any difference between the copy I lost of my 1.4.170.25 SimpleGraphic.dll and the 1.4.170.25 SimpleGraphic.dll I just downloaded, but in the event we notice some change in behavior, I'm making note of it here. It seems to act just like the one I had without any crashes, at any rate.

No luck yet, but I hope that helps some!

Live 1.4.170.25
dclamage v1
dclamage v2
Live 1.4.170.25
dclamage v1
dclamage v2

[dclamage]

@BWRStennett Thanks for the incredible detail. None of the PoB community devs have been able to reproduce your issue. If you're willing to set aside some time to help out, could you contact me on Discord [REDACTED] so that we can try different things and discuss this in real-time? I live in the PST time zone.

[dclamage]

This issue has been tracked down to a bad interaction between a Windows 7 update and Radeon drivers, and neither company has any plans to fix it. This means PoB simply won't work in that specific scenario. You may be able to fool with driver setups, but my recommendation is to upgrade to Windows 10.

If you encounter this issue and you are on Windows 8 or newer, please let me know.

[lllIIIllII]

Still same szenario: Win 10 and a Nvidia card.
Open on main monitor (27") and move to second monitor (24") -> close application -> open again -> black screen and application doesn't respond.

Tried using both the first and the second DLL provided but that didn't help. The DLLs were tried in a state where it was already crashing all the time.

Did a fresh reinstall and tried the first and second DLL but same pattern

[dclamage]

I gave you several weeks to respond and you did not. Thanks for coming back with the issue but please try to be more responsive in the future if you want your issue fixed. We are not able to reproduce the issue ourselves.

Please make sure the following:

1. Your Windows 10 is up-to-date
2. Your nvidia drivers are up-to-date
3. Both of your monitors are connected to your nvidia card, and not the motherboard

[lllIIIllII]

Sorry for that, turned out that my mailclient wasn't configured correctly and the folder that got these updates didn't check automatically. Should get updates every 10 minutes now.

Both Windows and Nvidia drivers up to date and all 3 monitors are connected to the GPU.
Did another fresh install and still got the same behaviour

[dclamage]

@lllIIIllII
Can you confirm if your behavior is different than what BWRStennett described? Basically, are you able to tell what the console output is when you get the crash? Or does it crash at a different point?

[lllIIIllII]

It loads all the 3.x tree data and the last line in the console is "loading item database".
Then the console closes and the main window pops up all black and already crashed

[hamadbhassan]

I am having the same issue as well on windows 10 with updated nvidia drivers and everything.

If I close pob on my 2nd screen then relaunch it, it will go through all the start up loading then crashes when pob windows pop ups. If I delete the launch.cfg, it will work again and go back the main monitor. Is there any more details or anything I can help to resolve this issue?

[dclamage]

@hamadbhassan We have plans to use a helper library for handling window creation and OpenGL initialization, rather than doing it ourselves at a low level. Clearly PoB is doing something nonstandard that makes certain computer setups crash, but it's hard to figure out exactly what or how to fix it, since none of the devs can reproduce the issue.

You'll just have to be patient, as swapping out something low level like that is both time consuming and intricate, and will need to be thoroughly tested. No ETA at the moment.

[hamadbhassan]

Fair enough. Thanks for the reply. If you need anything from my side, I am happy to help as well.