[Bug 41002] New: Worms 2 (GOG version) fails to start, crashes with a Visual C++ runtime error
https://bugs.winehq.org/show_bug.cgi?id=41002
Bug ID: 41002 Summary: Worms 2 (GOG version) fails to start, crashes with a Visual C++ runtime error Product: Wine Version: 1.9.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: fjfrackiewicz@gmail.com Distribution: ---
Created attachment 55166 --> https://bugs.winehq.org/attachment.cgi?id=55166 Terminal output Wine 1.9.15
I am using the GOG.com version of Worms 2 in a clean 32-bit prefix.
$ sha1sum setup_worms2_2.0.0.23.exe 28a7798fa948c2d285e7028ff8ff17cb1399c260 setup_worms2_2.0.0.23.exe
So far I have attempted to run the game without emulating a virtual desktop and while emulating a virtual desktop in Windows XP, 98, ME modes and the game crashes with a Visual C++ runtime error.
There's not much terminal output but I have added it anyways. If anyone has any suggestions as to which WINEDEBUG channels I should try, please let me know.
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #1 from fjfrackiewicz@gmail.com --- Created attachment 55167 --> https://bugs.winehq.org/attachment.cgi?id=55167 Picture of the error message
This is the error message I receive when I attempt to launch the game using the command "wine worms2.exe" in terminal.
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #2 from Bruno Jesus 00cpxxx@gmail.com --- This is a very common error in Windows too (since forever). Are you running frontend.exe or worms2.exe? Because it should be frontend.exe.
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #3 from fjfrackiewicz@gmail.com --- (In reply to Bruno Jesus from comment #2)
This is a very common error in Windows too (since forever). Are you running frontend.exe or worms2.exe? Because it should be frontend.exe.
I used frontend.exe and I got to the main menu. I clicked "Play a quick mission against the computer" and got the same error that you see in comment 1.
This happened with and without the virtual desktop.
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #4 from fjfrackiewicz@gmail.com --- Created attachment 55168 --> https://bugs.winehq.org/attachment.cgi?id=55168 Terminal output wine frontend.exe
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #5 from fjfrackiewicz@gmail.com --- (In reply to fjfrackiewicz from comment #4)
Created attachment 55168 [details] Terminal output wine frontend.exe
I also ran "winetricks directplay" after seeing dplay in the terminal and those fixmes and errors went away but the game still crashes.
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #6 from Aexander kq3thih@mailnesia.com --- According to the latest AppDB report (https://appdb.winehq.org/objectManager.php?sClass=version&iId=28494) this should work with Wine 1.8.3. That report also mentions it doesn't start on unspecified 1.9.x. If 1.8.3 does work for you than a regressions test would no doubt be useful: https://wiki.winehq.org/Regression_Testing.
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #7 from Bruno Jesus 00cpxxx@gmail.com --- My CD version of the game works fine, so I can't help testing as it seems to be GOG specific.
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #8 from fjfrackiewicz@gmail.com --- (In reply to Bruno Jesus from comment #7)
My CD version of the game works fine, so I can't help testing as it seems to be GOG specific.
Hi Bruno,
I can get you a copy of the game from GOG in order to help test it. I read up on regression testing, tried a few of the commands in there as far as bisecting goes but it looks like it requires knowledge of the components the bisection command lists in order to flag them as either a good or bad commit.
The copy would be a legal one, of course :)
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #9 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to fjfrackiewicz from comment #8)
I read up on regression testing, tried a few of the commands in there as far as bisecting goes but it looks like it requires knowledge of the components the bisection command lists in order to flag them as either a good or bad commit.
Actually it doesn't. You just need to compile Wine at each step, test Worms and then run "git bisect good" if Worms works fine or "git bisect bad" if it fails with the error in this bug.
You need to be able to compile Wine to do a bisection, obviously. You also need a starting point, that's why you should look for a Wine version that works first. According to comment 6, 1.8.3 should work so you should probably try with 1.8 (1.8.3 and 1.9.15 are on two separate branches so bisecting between them is a bit trickier than necessary).
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #10 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to fjfrackiewicz from comment #8)
I can get you a copy of the game from GOG in order to help test it....
The copy would be a legal one, of course :)
Thank you very much for the offer but my skills for debugging are very basic, most likely I would not be able to find the problem. As Matteo stated in the previous comment you can try the regression test, it is not difficult if you are used to compiling wine, just takes time.
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #11 from fjfrackiewicz@gmail.com --- Just an update on this:
This bug is not abandoned, I am currently making an attempt at a regression test. I am not sure if I will be successful though.
https://bugs.winehq.org/show_bug.cgi?id=41002
fjfrackiewicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |christopherwuy@gmail.com
--- Comment #12 from fjfrackiewicz@gmail.com ---
(In reply to Matteo Bruni from comment #9)
(In reply to fjfrackiewicz from comment #8)
I read up on regression testing, tried a few of the commands in there as far as bisecting goes but it looks like it requires knowledge of the components the bisection command lists in order to flag them as either a good or bad commit.
Actually it doesn't. You just need to compile Wine at each step, test Worms and then run "git bisect good" if Worms works fine or "git bisect bad" if it fails with the error in this bug.
You need to be able to compile Wine to do a bisection, obviously. You also need a starting point, that's why you should look for a Wine version that works first. According to comment 6, 1.8.3 should work so you should probably try with 1.8 (1.8.3 and 1.9.15 are on two separate branches so bisecting between them is a bit trickier than necessary).
Well, I got a seemingly "bad" commit when using these commands at the start of the bisection:
git bisect start git bisect good wine-1.8 git bisect bad wine-1.9.0
and then "git bisect bad" every time the game crashed with the Visual C++ error
The commit in question:
2ed5d0afc1e516c65a2f606ead009e666ffc29ff is the first bad commit commit 2ed5d0afc1e516c65a2f606ead009e666ffc29ff Author: YongHao Hu christopherwuy@gmail.com Date: Mon Dec 21 12:15:34 2015 +0800
msvcp110: Add tr2_sys__Read_dir implementation.
Signed-off-by: YongHao Hu christopherwuy@gmail.com Signed-off-by: Piotr Caban piotr@codeweavers.com Signed-off-by: Alexandre Julliard julliard@winehq.org
I am really unsure of this but that's what I got. If someone smarter than me can point me in a different direction I need to take in order to check this, please feel free to do so.
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #13 from fjfrackiewicz@gmail.com --- In case it helps, I ran the game in Wine 1.9.16 with the WINEDEBUG=+all command and I've uploaded the log here (the archive is 7 MB and the log uncompressed is 230 MB):
https://www.dropbox.com/s/zfv1mdae4dz4jf9/wineddebugall_txt.xz?dl=0
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #14 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to fjfrackiewicz from comment #13)
In case it helps, I ran the game in Wine 1.9.16 with the WINEDEBUG=+all command and I've uploaded the log here (the archive is 7 MB and the log uncompressed is 230 MB):
https://www.dropbox.com/s/zfv1mdae4dz4jf9/wineddebugall_txt.xz?dl=0
2523436 46574.943:0036:0037:warn:file:CreateFileW Unable to create file L"c:\nw2\data\level\Gulf\Level.dir" (status c000003a)
This is ugly, usually GOG games are always installed in the GOG folder, it looks like a bug in the application that is trying to find its data in the wrong place.
Try going to your drive_c folder and 'ln -s "GOG Games/Worms 2" nw2' Then run Worms 2 again, now it should find its data (I'm assuming GOG Games/Worms 2 is the default installation place, if not please adjust).
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #15 from fjfrackiewicz@gmail.com --- (In reply to Bruno Jesus from comment #14)
(In reply to fjfrackiewicz from comment #13)
In case it helps, I ran the game in Wine 1.9.16 with the WINEDEBUG=+all command and I've uploaded the log here (the archive is 7 MB and the log uncompressed is 230 MB):
https://www.dropbox.com/s/zfv1mdae4dz4jf9/wineddebugall_txt.xz?dl=0
2523436 46574.943:0036:0037:warn:file:CreateFileW Unable to create file L"c:\nw2\data\level\Gulf\Level.dir" (status c000003a)
This is ugly, usually GOG games are always installed in the GOG folder, it looks like a bug in the application that is trying to find its data in the wrong place.
Try going to your drive_c folder and 'ln -s "GOG Games/Worms 2" nw2' Then run Worms 2 again, now it should find its data (I'm assuming GOG Games/Worms 2 is the default installation place, if not please adjust).
My default install is C:\GOG Games so I am not sure why this is happening. I try to avoid unusual installation paths for this very reason. Still, if the application is trying something funny, I'll try adjusting the install path, I guess.
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #16 from fjfrackiewicz@gmail.com --- (In reply to Bruno Jesus from comment #14)
(In reply to fjfrackiewicz from comment #13)
In case it helps, I ran the game in Wine 1.9.16 with the WINEDEBUG=+all command and I've uploaded the log here (the archive is 7 MB and the log uncompressed is 230 MB):
https://www.dropbox.com/s/zfv1mdae4dz4jf9/wineddebugall_txt.xz?dl=0
2523436 46574.943:0036:0037:warn:file:CreateFileW Unable to create file L"c:\nw2\data\level\Gulf\Level.dir" (status c000003a)
This is ugly, usually GOG games are always installed in the GOG folder, it looks like a bug in the application that is trying to find its data in the wrong place.
Try going to your drive_c folder and 'ln -s "GOG Games/Worms 2" nw2' Then run Worms 2 again, now it should find its data (I'm assuming GOG Games/Worms 2 is the default installation place, if not please adjust).
Ok, now the game works after setting 'ln -s "GOG Games/Worms 2" nw2' in drive_c. Sound and everything.
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #17 from fjfrackiewicz@gmail.com --- So now the question remains if this is a Wine bug, a bug within the application, or a GOG-version bug.
Thank Bruno for finding out that one line in the debug text.
As for me, I will run this game on a Windows machine to see what it does when installed there and to see if that nw2 folder shows up.
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #18 from Bruno Jesus 00cpxxx@gmail.com ---
From your log I know it was installed in the correct folder, this nw2 is
probably some leftover when the game was ported to GOG (wild guess). I wonder if it works in Windows now to check if this is really a Wine bug.
From inside the Worms 2 folder try "grep nw2 * -R", it may take some time but
should reveal the culprit file. If you find a match try opening the file in a text editor and check if you see a path related to this folder.
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #19 from fjfrackiewicz@gmail.com --- (In reply to Bruno Jesus from comment #18)
From your log I know it was installed in the correct folder, this nw2 is probably some leftover when the game was ported to GOG (wild guess). I wonder if it works in Windows now to check if this is really a Wine bug.
From inside the Worms 2 folder try "grep nw2 * -R", it may take some time but should reveal the culprit file. If you find a match try opening the file in a text editor and check if you see a path related to this folder.
I am not sure .OGG and .dat files can be opened in a text editor :)
My output from the command you gave me:
Binary file Data/land.dat matches Binary file music/Track07.ogg matches Binary file music/Track05.ogg matches Binary file music/Track04.ogg matches Binary file Saves/land.dat matches
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #20 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to fjfrackiewicz from comment #19)
I am not sure .OGG and .dat files can be opened in a text editor :)
My output from the command you gave me:
Binary file Data/land.dat matches
Most likely it is this one, about opening do :
strings Data/land.dat | grep nw2
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #21 from fjfrackiewicz@gmail.com --- (In reply to Bruno Jesus from comment #20)
(In reply to fjfrackiewicz from comment #19)
I am not sure .OGG and .dat files can be opened in a text editor :)
My output from the command you gave me:
Binary file Data/land.dat matches
Most likely it is this one, about opening do :
strings Data/land.dat | grep nw2
Output is:
c:\nw2\data\level\Gulf c:\nw2\data\water\Green
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #22 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to fjfrackiewicz from comment #21)
Output is:
c:\nw2\data\level\Gulf c:\nw2\data\water\Green
Nice, so indeed this weird path exists somewhere and it is trying to be reached when running from Wine. It could be that in Windows it tries to do the same but due to a different error code the game goes on or crash.
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #23 from fjfrackiewicz@gmail.com --- (In reply to Bruno Jesus from comment #22)
(In reply to fjfrackiewicz from comment #21)
Output is:
c:\nw2\data\level\Gulf c:\nw2\data\water\Green
Nice, so indeed this weird path exists somewhere and it is trying to be reached when running from Wine. It could be that in Windows it tries to do the same but due to a different error code the game goes on or crash.
Probably. I'll have to see how the game acts on Windows 10, for example.
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #24 from fjfrackiewicz@gmail.com --- Unfortunately, the game refuses to even work on Windows 10 but I have no idea why. It could be trying to perform the same operation it does in Wine but performing symlinks in Windows 10 (it does have an mklink command) is a bit tricky as the mklink command fails with "Cannot create already existing file" or something to that effect.
The other bit of bad news is that I do not have access to a Windows 7 PC or even a license so I can't test the game on a more sane version of Windows :/
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #25 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to fjfrackiewicz from comment #24)
Unfortunately, the game refuses to even work on Windows 10 but I have no idea why. It could be trying to perform the same operation it does in Wine but performing symlinks in Windows 10 (it does have an mklink command) is a bit tricky as the mklink command fails with "Cannot create already existing file" or something to that effect.
The other bit of bad news is that I do not have access to a Windows 7 PC or even a license so I can't test the game on a more sane version of Windows :/
Just copy the contents of the worms 2 folder to c:\nw2, it should have the same effect in this case. But if the game does not even start the problem may be different.
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #26 from fjfrackiewicz@gmail.com --- (In reply to Bruno Jesus from comment #25)
(In reply to fjfrackiewicz from comment #24)
Unfortunately, the game refuses to even work on Windows 10 but I have no idea why. It could be trying to perform the same operation it does in Wine but performing symlinks in Windows 10 (it does have an mklink command) is a bit tricky as the mklink command fails with "Cannot create already existing file" or something to that effect.
The other bit of bad news is that I do not have access to a Windows 7 PC or even a license so I can't test the game on a more sane version of Windows :/
Just copy the contents of the worms 2 folder to c:\nw2, it should have the same effect in this case. But if the game does not even start the problem may be different.
Thanks, I will do so once I have access to that machine. I should've thought of that earlier.
https://bugs.winehq.org/show_bug.cgi?id=41002
Peter Beutner p.beutner@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |p.beutner@gmx.net
--- Comment #27 from Peter Beutner p.beutner@gmx.net --- found the culprit:
trace:file:GetShortPathNameA ".\\data\water\Yellow" trace:file:GetShortPathNameW L".\\data\water\Yellow" trace:file:GetShortPathNameW not found!
this leads to frontend.exe calling landgen.exe without the path to the water sprites. landgen.exe then simply exits without updating data/land.dat with the correct paths.
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #28 from Peter Beutner p.beutner@gmx.net --- Created attachment 55311 --> https://bugs.winehq.org/attachment.cgi?id=55311 fix for GetShortPathName
properly handle path name starting with ".\"
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #29 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Peter Beutner from comment #27)
found the culprit:
trace:file:GetShortPathNameA ".\\data\water\Yellow" trace:file:GetShortPathNameW L".\\data\water\Yellow" trace:file:GetShortPathNameW not found!
this leads to frontend.exe calling landgen.exe without the path to the water sprites. landgen.exe then simply exits without updating data/land.dat with the correct paths.
Sounds awesome, I would never think about that. Please check file kernel32\testes\path.c and add some tests to back your changes, at line 1381 you will find the function test_GetShortPathNameW, there is already a extended_prefix test that I think you can duplicate and change. Then read http://wiki.winehq.org/SubmittingPatches
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #30 from Peter Beutner p.beutner@gmx.net --- (In reply to Bruno Jesus from comment #29)
Sounds awesome, I would never think about that. Please check file kernel32\testes\path.c and add some tests to back your changes, at line 1381 you will find the function test_GetShortPathNameW, there is already a extended_prefix test that I think you can duplicate and change. Then read http://wiki.winehq.org/SubmittingPatches
uh, just send the patch, before seeing your reply Since the existing code already strips double path delimiters, but fails to handle this corner case, I felt it was a simple code bug in wine which doesn't need a test case.
oh well, I'll see how it goes. If it gets rejected I'll add a test case and resend. thanks for the pointer on where to add the test.
https://bugs.winehq.org/show_bug.cgi?id=41002
fjfrackiewicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |kernel32
https://bugs.winehq.org/show_bug.cgi?id=41002
--- Comment #31 from fjfrackiewicz@gmail.com --- (In reply to Peter Beutner from comment #28)
Created attachment 55311 [details] fix for GetShortPathName
properly handle path name starting with ".\"
The patch works. I just played through a single player mission with no trouble at all :)
https://bugs.winehq.org/show_bug.cgi?id=41002
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |c90e46b66ded518dbfb88f1efdc | |366e7986defb4 Resolution|--- |FIXED
--- Comment #32 from Bruno Jesus 00cpxxx@gmail.com --- Patch commited: http://source.winehq.org/git/wine.git/?a=commit;h=c90e46b66ded518dbfb88f1efd...
Thanks OP for the tests and Peter for the patch.
https://bugs.winehq.org/show_bug.cgi?id=41002
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #33 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.9.17.
-
wine-bugs＠winehq.org