1.17.13 Appcrash (Windows 7)

[Spannerbag]

Hi,
I have 1.17.13 and 1.16.6 installed on the same PC.

When developing/debugging on v16 I frequently switch to other windows or the desktop without any problem but this crashes 1.17.13

If I switch (Alt-Tab) to another open window (e.g. the logfile folder) it seems OK but if I then go to desktop from the toolbar or Alt-Tab directly to the desktop it halts with an Appcrash. I've checked this 3 times now and seen the same behaviour every time

The version though is 1.16.0.0 ? V16 wasn't even running...

...

Just checked again and yes, v1.16.0.0 is reported.

Anyway here's the appcrash text (seems identical each time, 2 copies pasted here):

Code: Select all

Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	wesnoth.exe
  Application Version:	1.16.0.0
  Application Timestamp:	63f31a30
  Fault Module Name:	wesnoth.exe
  Fault Module Version:	1.16.0.0
  Fault Module Timestamp:	63f31a30
  Exception Code:	c0000094
  Exception Offset:	0000000000acfcf3
  OS Version:	6.1.7601.2.1.0.768.3
  Locale ID:	2057
  Additional Information 1:	05db
  Additional Information 2:	05db13bb5ed0c793f402b604b073df82
  Additional Information 3:	e68a
  Additional Information 4:	e68aac55aa3db11a0cbf894ccaf96097

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
  C:\Windows\system32\en-US\erofflps.txt

----------------------------------------------------------------

Code: Select all

Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	wesnoth.exe
  Application Version:	1.16.0.0
  Application Timestamp:	63f31a30
  Fault Module Name:	wesnoth.exe
  Fault Module Version:	1.16.0.0
  Fault Module Timestamp:	63f31a30
  Exception Code:	c0000094
  Exception Offset:	0000000000acfcf3
  OS Version:	6.1.7601.2.1.0.768.3
  Locale ID:	2057
  Additional Information 1:	05db
  Additional Information 2:	05db13bb5ed0c793f402b604b073df82
  Additional Information 3:	e68a
  Additional Information 4:	e68aac55aa3db11a0cbf894ccaf96097

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
  C:\Windows\system32\en-US\erofflps.txt

There's nothing helpful in the logs, that all looks OK.

Automatically found a possible data directory at: C:\Program Files\battle-for-wesnoth-win-beta

Code: Select all

Data directory:               C:\Program Files\battle-for-wesnoth-win-beta
User configuration directory: C:\Users\USER\Documents\My Games\Wesnoth1.17
User data directory:          C:\Users\USER\Documents\My Games\Wesnoth1.17
Cache directory:              C:\Users\USER\Documents\My Games\Wesnoth1.17\cache


Setting mode to 1366x768
20230304 21:59:38 warning config: add-on 'Road_to_Carcyn17' has no _info.cfg; cannot read version info
Checking lua scripts... ok

Changed the folder name to Battle for Wesnoth 1.17.13 (general paranoia) but no change.
Also happens when the editor is launched ("C:\Program Files\Battle for Wesnoth 1.17.13\wesnoth.exe" -e).

Config:

Anything else you need or want me to try please let me know.
For now at least I'll have to continue developing/testing on 1.16...

Cheers!
-- Spannerbag

[Spannerbag]

Just removed all add-ons. No change, still crashes (thought it might be my UMC).
Cheers!
-- Spannerbag

[Pentarctagon]

The text version of the build information is much more useful (as described in viewtopic.php?t=25660). I'm not sure what else to suggest though - a stacktrace is what's needed most, but that requires building Wesnoth yourself.

[Spannerbag]

The text version of the build information is much more useful (as described in viewtopic.php?t=25660). I'm not sure what else to suggest though - a stacktrace is what's needed most, but that requires building Wesnoth yourself.

Build info below.
There's a couple of things I'm going to try:

• reinstall from scratch in case there was a glitch somewhere
• try v17 on windows 10 (without v16)

I'm not hugely hopeful but you never know.
I regularly run antivirus etc. and my machine is reasonably well armoured so I doubt it's malware etc.


The Battle for Wesnoth version 1.17.13 x86_64
Running on Microsoft Windows 7 Service Pack 1 (6.1.7601) x86_64
Distribution channel: itch

Game paths
==========

Data dir: C:\Program Files\Battle for Wesnoth 1.17.13
User config dir: C:\Users\USER\Documents\My Games\Wesnoth1.17
User data dir: C:\Users\USER\Documents\My Games\Wesnoth1.17
Saves dir: C:\Users\USER\Documents\My Games\Wesnoth1.17\saves
Add-ons dir: C:\Users\USER\Documents\My Games\Wesnoth1.17\data\add-ons
Cache dir: C:\Users\USER\Documents\My Games\Wesnoth1.17\cache
Logs dir: C:\Users\USER\Documents\My Games\Wesnoth1.17\logs

Libraries
=========

Boost: 1.80
Lua: 5.4.4
OpenSSL/libcrypto: 1.1.1s (runtime 1.1.1s)
Cairo: 1.17.6 (runtime 1.17.6)
Pango: 1.50.11 (runtime 1.50.11)
SDL: 2.24.1 (runtime 2.24.1)
SDL_image: 2.6.2 (runtime 2.6.2)
SDL_mixer: 2.6.2 (runtime 2.6.2)

Features
========

Lua console completion: yes
Win32 notifications back end: yes

Current video settings
======================

SDL video drivers: [windows] dummy
Window size: 1366x768
Game canvas size: 1366x768
Final render target size: 1366x768
Screen refresh rate: 60
Screen dpi: 96.00x96.00
Renderer: direct3d (hw)
Maximum texture size: 4096x4096
VSync: on

Current audio settings
======================

SDL audio drivers: [wasapi] directsound
Number of channels: 2
Output rate: 48000 Hz
Sample format: signed 16 bit little-endian
Sample size: 4096 bytes

Installed add-ons
=================

No add-ons installed.

Cheers,
-- Spannerbag

[Spannerbag]

Just deleted and reinstalled from fresh dl, no change.
Also scanned PC, no malware.
V17 only crashes when switching to desktop, not to another open window (browser, folder etc.).

However, switch out of full screen mode and it doesn't crash!

Hope that helps, please let me know if I can try out anything else.
Might get round to testing on Windows 10 if/when I get chance.

PS: not seen that weird continuous idle behaviour again thankfully, no idea how/why that happened

Cheers,
-- Spannerbag

[Toranks]

I can confirm the bug. Wesnoth 1.17.13 crashes when alt+tab to DESKTOP, but not crashes when alt+tab to another active windows.
And i get too that strange "1.16.0.0" version on the crash report

[Spannerbag]

I can confirm the bug. Wesnoth 1.17.13 crashes when alt+tab to DESKTOP, but not crashes when alt+tab to another active windows.
And i get too that strange "1.16.0.0" version on the crash report

Thanks for that - out of interest, what OS version did you use?
I used 7 and when I get chance will see if 10 does likewise - but you may have saved me a job

Cheers,
-- Spannerbag

[Spannerbag]

The text version of the build information is much more useful (as described in viewtopic.php?t=25660). I'm not sure what else to suggest though - a stacktrace is what's needed most, but that requires building Wesnoth yourself.

Just a sanity check really, do these posts constitute a valid "bug report" or do I need to do anything else?
Hopefully, having linked the behaviour to setting/unsetting full screen mode, the issue source should be constrained somewhat?
Please let me know if you do need anything else from me.
I might try building with stacktrace but it won't happen anytime soon, not least 'cos I've never compiled anything on windows.

PS - if any helpful soul on this forum who has compiled stuff on windows could advise me on what (free) tools/software to use that'd be a great start.
I could search for stuff myself but I'd rather use something that I know works

Cheers,
-- Spannerbag

[Toranks]

Thanks for that - out of interest, what OS version did you use?
I used 7 and when I get chance will see if 10 does likewise - but you may have saved me a job

Cheers,
-- Spannerbag

Windows 7, I already reported it here seeing that it wasn't just my problem. It happened to me once a while ago and I didn't know how to reproduce it until you found the key: alt+tab to DESKTOP xD

https://github.com/wesnoth/wesnoth/issues/7438

[gnombat]

I used 7 and when I get chance will see if 10 does likewise - but you may have saved me a job

Is it actually possible to Alt+Tab to desktop in Windows 10? I think that's a feature that exists only in Windows 7. Unless there's a setting for it somewhere...?

[Pentarctagon]

The text version of the build information is much more useful (as described in viewtopic.php?t=25660). I'm not sure what else to suggest though - a stacktrace is what's needed most, but that requires building Wesnoth yourself.

Just a sanity check really, do these posts constitute a valid "bug report" or do I need to do anything else?
Hopefully, having linked the behaviour to setting/unsetting full screen mode, the issue source should be constrained somewhat?
Please let me know if you do need anything else from me.
I might try building with stacktrace but it won't happen anytime soon, not least 'cos I've never compiled anything on windows.

PS - if any helpful soul on this forum who has compiled stuff on windows could advise me on what (free) tools/software to use that'd be a great start.
I could search for stuff myself but I'd rather use something that I know works

Cheers,
-- Spannerbag

It's a valid bug report. The problem with figuring out what's causing the problem in this case is that:

• The appcrash report is just not very useful unfortunately and there's nothing in the log indicating what actually went wrong.
• Fullscreen vs non-fullscreen is essentially just a setting passed to the SDL2 library that Wesnoth depends on, so it's not immediately clear what Wesnoth would be doing to cause this issue.

The instructions for building on Windows is here if you decide to give it a shot.

[Wedge009]

After some investigation, I'm inclined to think the issue is with how SDL calculates the width and height of its renderer objects when Windows is in its desktop view mode, starting with SDL 2.24.0. I couldn't replicate the crash in Wesnoth 1.17.13, if I dropped SDL 2.0.22 DLL in its installation instead.

You can read https://github.com/wesnoth/wesnoth/issues/7438 if you're interested in the technical details. The mix-up with the version numbers is a separate problem and is logged as https://github.com/wesnoth/wesnoth/issues/7441.

[Spannerbag]

After some investigation, I'm inclined to think the issue is with how SDL calculates the width and height of its renderer objects when Windows is in its desktop view mode, starting with SDL 2.24.0. I couldn't replicate the crash in Wesnoth 1.17.13, if I dropped SDL 2.0.22 DLL in its installation instead.

You can read https://github.com/wesnoth/wesnoth/issues/7438 if you're interested in the technical details. The mix-up with the version numbers is a separate problem and is logged as https://github.com/wesnoth/wesnoth/issues/7441.

Many thanks for your time and trouble in digging into this, and then updating us here - it's appreciated and good to see what's going on "under the bonnet".
I have a few random ideas/suggestions but doubtless you're waaay ahead of me so I'll shut up and let you get on with it

Thanks again,
cheers!
-- Spannerbag

[Wedge009]

SDL team has resolved the zero width/height issue, so when that's included in the next SDL release (some time in April) and we include it in our next release, this issue should be resolved. I assume this isn't a crippling bug for you (unless you're using Windows desktop view frequently).

[Spannerbag]

... next release, this issue should be resolved. I assume this isn't a crippling bug for you (unless you're using Windows desktop view frequently).

Nah, it was annoying but not fatal - just glad it was resolved so swiftly
Thanks for your effort, much appreciated.
Cheers!
-- Spannerbag