Engine: Windows freezes on Alt+Tab for a specific player

[edmundito]

Describe the bug A player reported an issue where when they alt+tab, the game completely freezes, including Windows:

it doesn't properly crash. It stops responding, and then I can't use my mouse to do anything in Windows - even keyboard controls don't work. I have to sign out.

AGS Version AGS 3.6.0.57

Game Rosewater beta (1280x720px, game speed 60)

To Reproduce

1. Run the game
2. Alt tab

Expected behavior Windows doesn't freeze up.

Screenshots User's game setup:

Desktop (please complete the following information):

• OS: Windows
• Version 10

Additional context Player is using a custom-built PC with the following specs. Player also reported that it has not happened with any other AGS game.

• Nvidia GeForce 3070 Ti
• AMD Ryzen 5 5600x 3.70ghz
• 32 GB RAM
• 1TB HD

[ivan-mogilko]

• does it happen with other graphic drivers?
• does it happen in "Fullscreen as borderless window" or "Windowed mode"?
• does it happen virtually every time, in any moment of the game?
• Player also reported that it has not happened with any other AGS game; which other AGS games did they try (for example), which version of AGS were they made in?
• Speaking of input not working, does ctrl+alt+del work in order to get a menu and bring task manager up, for instance?

[ericoporto]

If it's the issue that I had (on a Ryzen + NVidia Pc) you can use Windows key + Tab to bring the Desktop Switcher and move the hanged AGS to a new workspace/desktop and use the existing one as if nothing happened (to be able to investigate what happened).

It would be nice to know the specific Windows 10 version and Nvidia driver.

Here's my comment, from when I had, I remember I didn't had in 3.6.1, even though I had in 3.6.0, but eventually I upgraded my NVidia drivers and the issue disappeared even on 3.6.0.

[faragher]

I want to add that I had a similar issue that I only managed to escape by virtue of having two monitors so I could alt-tab in and out, as well as using the mouse to attempt to restore focus (the game remained on top of primary monitor, and I don't think I had a cursor on that display). I can't be sure it's the same issue, since I was able to recover, but in case it's related, I'll list information below.

It's also worth noting I alt-tabbed dozens of times and encountered the issue once, and I recall fumbling the keyboard command somehow when it happened.

Fullscreen, not as borderless window 1920x1080 GTX970 32GB RAM Windows 10 NVidia Driver 545.84 DX9 version

Since I have similar problems (but all the time) with games like New Vegas, I'm curious if it would happen when set to OpenGL, but since I can't replicate it on demand, I'm not sure how I'd even test.

[edmundito]

Been chatting with the player, here's some answers:

I think it happened with other AGS games, I just wasn't testing them so I alt-tabbed a lot less.

does it happen virtually every time, in any moment of the game?

no, but I suspect it may be happening when there's a bigger memory issue? or maybe not actually, because that last scene is the one in the screenshot above.

Drivers?

the latest versions of both Win 10 and NVIDIA

---

We've tried a number of combinations with the graphics and audio drivers, and it seems that it's most likelyrelated to d3d9. Software renderer did not crash, although it showed some strange behavior (like the game was responding to clicks even when it was not focused if the player clicked on a window in front of it...)

[edmundito]

And also:

Basically, it triggers with greater frequency in areas with looped audio, and when it's feeling crashy, the audio will loop with a short gap. 2D software rendering seems to make it a lot more stable.

So maybe some audio complexity in Rosewater that is overloading the engine in some cases?

[ivan-mogilko]

I suggest using "fullscreen as borderless window" by default.

Direct3D definitely had issues with exclusive fullscreen in 3.6.0 (#1287). @ericoporto said it's fixed in 3.6.1, but the problem is that I cannot remember if anything was fixed in that regard in 3.6.1, so either any seemingly unrelated changed fixed it, or it became harder to reproduce by coincidence.

[faragher]

Can confirm I can replicate in Rosewater in the wagon. Will download the 3.6.1 executable. Is there any way to enable some kind of verbose logging?

[ivan-mogilko]

Logging config is explained here: https://github.com/adventuregamestudio/ags/blob/master/OPTIONS.md check the "[log]" section for config file, or "--log*" command line args.

Is there a save I could use to check the same location, or alternatively a walkthrough?

[faragher]

Thank you. I downloaded 3.6.1P4, put ac.exe in the directory, and ran it. Issue occurred.

Will supply a save shortly. Will set up logging presently.

[faragher]

AltTab.zip

File should be for 3.6.0, loading then alt+tabbing between around 8 and 12 times should trigger crash.

[faragher]

Log is extensive. I think I grabbed the pertinent section, but I don't think it tells us anything:

Window event: size changed (1920, 1080)
Render frame set, render dest (0, 0, 1919, 1079 : 1920 x 1080)
Mouse cursor graphic area: (0,0)-(1919,1079) (1920x1080)
Window event: focus lost
Suspending the game on switch out
Switching out from the game
Game : (room:39)[? 1926] cLolaBod: View locked to 26
Game : (room:39)[? 3783] cBoylanBody: View locked to 268
Game : (room:39)[? 3979] cImprBod: View locked to 381
Game : (room:39)[? 4038] cBassBod: View locked to 409
Game : (room:39)[? 4191] cSoprBod: View locked to 425
Game : (room:39)[? 4281] cBridgetBod: View locked to 445
Game : (room:39)[? 5328] cPluckBod: View locked to 400
Game.SetAudioTypeVolume: type: 2, volume: 100, change: all
Game.SetAudioTypeVolume: type: 3, volume: 100, change: all
Game.SetAudioTypeVolume: type: 1, volume: 100, change: all
Game.SetAudioTypeVolume: type: 5, volume: 70, change: all
Game.SetAudioTypeVolume: type: 4, volume: 100, change: all
Game.SetAudioTypeVolume: type: 4, volume: 100, change: all
Game : (room:39)[? 811] FileOpen: request: $SAVEGAMEDIR$/prefs.rsw
Game : (room:39)[? 811] FileOpen: success: C:/Users/Michael/Saved Games/Rosewater/prefs.rsw
Renderer exception: Direct3D device is lost
Window event: focus gained
Resuming the game on switch in
Switching back into the game
Window event: size changed (1920, 1080)
Render frame set, render dest (0, 0, 1919, 1079 : 1920 x 1080)
Mouse cursor graphic area: (0,0)-(1919,1079) (1920x1080)
Game : (room:39)[? 907] SkipSpeech style set to 0
Window event: close
SDL event: quit
Window event: size changed (1920, 1080)
Render frame set, render dest (0, 0, 1919, 1079 : 1920 x 1080)
Mouse cursor graphic area: (0,0)-(1919,1079) (1920x1080)
Window event: focus lost
Suspending the game on switch out
Switching out from the game
Quitting the game...
WARNING: Not all of the Direct3D resources have been disposed; ID3D ref count: 1
***** ENGINE HAS SHUTDOWN

I am currently at the debug verbosity. Will see if verbose provides any new information.

As an aside, is polling the prefs.rsw constantly (~1,000 times per minute) AGS behavior or Rosewater behavior? Rosewater specific behavior

Edit: The Direct3d device being lost is the only real information I can gather here. I hope it's helpful for someone with better knowledge of AGS.

[faragher]

Also, I cannot replicate the issue with OpenGL. Combined with the Direct3D device being lost error, it's likely within D3D specific routines. Again, not a surprise, but hopefully helpful.

[ericoporto]

I can't reproduce it anymore since I upgraded the Nvidia drivers but when I had the conditions required were

• Direct3D driver
• Exclusive Fullscreen
• NVidia (could never reproduce in an Intel driver, didn't have AMD card to test).

I think the game resolution and the monitor resolution also can't match (but I wasn't able to test this before the problem went away). If you can reproduce this and this somehow solves it for you, we could make so that exclusive fullscreen uses the same resolution as the desktop was on Windows, and then resize the game through some other way.

Since 3.6.1 there's an additional setting to remove the Fullscreen configuration so one can set and lock the game to use only borderless window Fullscreen.

Also it would be better to get a log for 3.6.1 since the code has diverged from 3.6.0 a certain amount.

NVidia Driver 545.84

That's a very old driver. I think if you upgrade the problem will disappear.

[AlanDrake]

Also, I cannot replicate the issue with OpenGL

The opengl driver can only do borderless, regardless of settings.

Anyway, yeah, always make borderless the default.

[faragher]

The opengl driver can only do borderless, regardless of settings.

Good to know, thanks!

[ivan-mogilko]

So, to summarize, this is likely a reiteration of #1287. Back then I was not able to find what causes the problem nor have any idea how to fix this in the program (or whether this may be fixed in program), nor I do now.

If this may be fixed by updating NVidia driver, I'd propose user to try that, unless it's already the latest version.

In the long term, implementing a new graphic renderer based on contemporary version of DirectX is going to be beneficial, and may solve existing issues with Direct3D renderer.

[ivan-mogilko]

Right, I haven't tried to reproduce this in the "wagon" scene in Rosewater yet. I will try, but not sure if that will improve my understanding of a problem.