Game crashes at Startup with a Wine C++ Runtime Error.
Header: "Wine C++ Runtime Library"
Box:
"R
Program: Z
a
Press OK to exit programm, or Cancel to start the Wine debugger"
Just start it again. Reproduction possible with other Proton Versions.
Basically I have about the same output.
I'm encountering the same issue
i got the same issue on my system :(
Can also confirm.
Adding the "ucrtbase.dll" like Planet Coaster #1538 manage to get pass the Wine C++ Runtime Error for me, (I also unplug the USB mouse and keyboard)
but the game still crashes before any black screen appears and shows the game's Crash Reporter and leaves behind the PlanetZoo.exe process that needs killing
Adding the "ucrtbase.dll" like Planet Coaster #1538 manage to get pass the Wine C++ Runtime Error for me, (I also unplug the USB mouse and keyboard)
but the game still crashes before any black screen appears and shows the game's Crash Reporter and leaves behind the PlanetZoo.exe process that needs killing
I can confirm this behaviour.
I can also confirm
Does anyone have an update on this?
Game still crashes at startup with Proton 5.0-2.
Tested on Proton 5.0-4, still crashes
I see I am not the only one. Planet Coaster runs fine without any issues but Planet Zoo says C++ runtime error.
After long sessions of debugging, log reading and looking at the disassembly, I think I pinpointed the crash. The game uses nt kernel functions to access files. The functions, however, are case sensitive by default (or, at least, implemented in wine as such). The game tries to read a file by its name in the lower case while the actual file on the disk in the camel case. The games fails to read the file and eventually crashes.
I made a hack to force the relevant functions to be always case insensitive: https://github.com/AlexeyProkhin/wine/commit/c3036bc707ca180832eee52d8f2d0423dcf660e1. With the workaround the game opens a window, shows a logo and, unfortunetely, gets stuck on it. Can someone else test the patch? I would appreciate confirming the game does not crash with it. I am especially interested what would happen for AMD users as the game loads nvapi64.dll for me which may explain its being stuck on the logo.
P.S. I made a build with my workaround: https://drive.google.com/file/d/15i9MSm_sPrAgo2wGaS_4ezCcHC-vvxgW/view?usp=sharing. It is totally untested however, denuvo blocked me for one day.
You are correct, at first I also got the C++ error and it was looking for a lower case path on z:
This happens with your patch, which is hopeful:)
But it hangs at this screen now, I have a GTX970.
Added this to launch options:
WINEDLLOVERRIDES="nvapi=d;nvapi64=d" %command%
Didn't work either.
How do I get meaningful logging out of Proton / game? It's just waiting for something right now, if you close the game with alt + F4 the window closes but the game never does.
Too bad you get the 24 hour timeout pretty fast :(
Same issue with an 5700XT
@AlexeyProkhin I build proton GE with your patch and now it is working!
Just unpack this build here: _~/.steam/root/compatibilitytools.d/_
Then restart steam and select _proton-planet-zoo_ under The "Force the use of a specific Steam Play compatibility tool" option.
I tried @AlexeyProkhin 's build per the notes in @JWolvers post, and was not able to get it running. After clicking play, Steam switches to say the game is running, and a few seconds later it goes back to saying Play. Nothing appears to pop up indicating the game is actually running though. Sounds like an early crash but nothing is in the logs.
Checked through the main Steam logs and was only able to find a line indicating that the app started, and then a line immediately after saying the app exited.
Proton log attached.
steam-703080.log
Not sure if I'm missing something from the above.
@r-u-u Run steam via the terminal and it will give you better logs
Tried the Proton-GE build in @JWolvers post as well.
The game does start and reach the main menu.
But after a minute it froze and need to kill the process.
The full proton log is way too big to be uploaded here because of a repeated error
err:nls:get_codepage_table too many codepages
and a lot of trace.
Here's the log without codepage and trace:
planetzoo_proton_filtered.log
I'll try again with a clean install later. (EDIT: still froze randomly on the menu screen)
It sounds promising. Can we expect new NT functions patch to be implement both in proton and wine ? That may help wine upstream on some other games outside of steam
Also tried the Proton-GE build. It seems to start, and I do see the menu and can start a game, but the main screen stays black.
Edit: Seems to be working when putting all graphics settings to low/off
@JWolvers Thank you for confirming. I was actually planning to do the same thing today. Because yesterday I was able to get into the game for the first time. I added the game into lutris and used the wine steam runner and lutris-5.5-2 wine build. But to bypass the case sensitivity issue I remounted my ntfs drive with games as case insensitive:
sudo umount /media/wingames/
sudo mount -t lowntfs-3g -o ignore_case /media/wingames/
It sounds promising. Can we expect new NT functions patch to be implement both in proton and wine ? That may help wine upstream on some other games outside of steam
As of right now, no. First there must be some tests to confirm if it's wine's issue or if the game makes wrong assumptions. The hack may probably go into GloriousEggroll's fork, but even before that it must be modified to be enabled only for the game.
After long sessions of debugging, log reading and looking at the disassembly, I think I pinpointed the crash. The game uses nt kernel functions to access files. The functions, however, are case sensitive by default (or, at least, implemented in wine as such). The game tries to read a file by its name in the lower case while the actual file on the disk in the camel case. The games fails to read the file and eventually crashes.
I made a hack to force the relevant functions to be always case insensitive: AlexeyProkhin/wine@c3036bc. With the workaround the game opens a window, shows a logo and, unfortunetely, gets stuck on it. Can someone else test the patch? I would appreciate confirming the game does not crash with it. I am especially interested what would happen for AMD users as the game loads nvapi64.dll for me which may explain its being stuck on the logo.P.S. I made a build with my workaround: https://drive.google.com/file/d/15i9MSm_sPrAgo2wGaS_4ezCcHC-vvxgW/view?usp=sharing. It is totally untested however, denuvo blocked me for one day.
This game works flawlessly after applying this patch! However, I have noticed the clouds are a bit buggy. Though I doubt this is going to stop players from playing the game given how it never even booted before hand. :)
I am using Fedora 31 with AMD RX 580 GPU using the open source drivers. I am not sure if this is reproduce-able but I will provide logs if necessary to fix it.
Just unpack this build here: _~/.steam/root/compatibilitytools.d/_
Then restart steam and select _proton-planet-zoo_ under The "Force the use of a specific Steam Play compatibility tool" option.
This patch works out of the box for me although in game there is some lag. I haven't tried tweaking the graphics settings yet. I was able to get in game and interact with a zoo. I'm using NixOS channel 20.03 and have a Nvidia GTX 760 graphics card.
Update: I am unable to reliably load saved games. Changes to the master volume setting are reverted to the previous sate.
As of right now, no. First there must be some tests to confirm if it's wine's issue or if the game makes wrong assumptions.
I looked into it one more time. Like I said before the game uses NtCreateFile() but does not set OBJ_CASE_INSENSITIVE attribute. It tries to open "gamemain" directory while the real name on the disk is "GameMain". It works because windows mounts ntfs drives as case insensitive.
It is clearly a bug in the game, it makes an incorrect assumption that drives are always case insensitive. A hack similar to the above one is probably the only way to fix the issue. I can't be sure about it, but I'll open a merge request and let the proton devs decide. Edit: I just remembered the hack does not work with proton master for most people. So it is way too soon opening a merge request.
@AlexeyProkhin Do you think this could be worked around by renaming the file to gamemain? I gave it a shot and it still crashed but I don't know too much about what is going on. I can confirm the patched proton got it working for me on Fedora 31 with an RX 5700xt.
Edit: I gave this a longer play and it crashed after about 20 minutes
The game initially works, but freezes or crashes during the tutorial after some time. At that point it shows to be using over 100% of the CPU.
Edit: even in the menu screen, the process is reported to use over 100% of CPU, however the CPU reports only a load of around 35%. The CPU is an Intel® Core™ i7-8750H. When exiting the game through the 'quit game' button in the main menu, the process remains running in the background while the reported CPU usage ticks down over time.
I have an RTX2060 and am using proprietary nvidia drivers. The game also gives a warning when starting saying that the drivers are out of date, which I know for a fact is not true. After a clean install this warning does no longer show.
I will look into how to provide a better log by running steam/planet zoo through the terminal, but I have never done that yet, so it might be some time.
Just unpack this build here: ~/.steam/root/compatibilitytools.d/
Then restart steam and select proton-planet-zoo under The "Force the use of a specific Steam Play compatibility tool" option.
This looks very promising! Game starts without problems. No further tests done yet though. Using a GeForce GTX 1060 with proprietary drivers.
Has anyone attempted to report the game bug to the developers? They're still actively updating the game, so there is a chance they might take care of it.
I created an issue on their issue tracker: https://issues.frontierstore.net/issue-detail/14441
But they probably won't fix it cause it's a Linux only problem.
P.S. I made a build with my workaround: https://drive.google.com/file/d/15i9MSm_sPrAgo2wGaS_4ezCcHC-vvxgW/view?usp=sharing. It is totally untested however, denuvo blocked me for one day.
What Proton did you use as base for this?
I built my own Proton 5.6-GE-2 using this patch planet-zoo-case-insensitive-hack.patch.txt, and while the game starts and I can get in-game and start building, it doesn't take long before it crashes. The log grows wildly while playing; it almost reached 1GB before crashing once.
Using WineD3D instead of DXVK resulted in the game telling me it couldn't find any suitable graphics adapters, and disabling e-sync seems to have done no difference whatsoever.
Fedora 31
Vega 56 with Mesa 19.2.8
16GB of RAM
Ryzen 3600
Linux 5.5
I created an issue on their issue tracker: https://issues.frontierstore.net/issue-detail/14441
But they probably won't fix it cause it's a Linux only problem.
It may be worth linking this thread so that they know how we came to that conclusion.
@Newbytee I added a link to this issue.
If someone could confirm the issue on their bug tracker, that should at least increase attention. When you log in and go to the issue you can fill out this form:
Basically, always when saving. And at least first two crashes are caused by the same issue (very similar logs mentioning saving a profile and exactly the same backtrace).
The game gets stuck at logo if I enable ntdll debugging channel with the hack I previously wrote about. What is weird another version of the patch gets stuck at logo unless ntdll channel is enabled.
The game does not exit properly and had to be killed.
Starting the game with a debugger or adding a debugging channel often (but not always) changes how the game crashes: another backtrace, another exception type etc. But the game is consistently crashes in cases described in 1.
@AlexeyProkhin Do you think this could be worked around by renaming the file to gamemain?
It should be. But it would require renaming other directories and files. "gamemain" is just a first directory a game couldn't find.
What Proton did you use as base for this?
Proton 5.0-6 rc, I think.
Another thing worth mentioning. Beside Main, rendering threads and some others, the game starts 14 task threads (with names fTask W0, fTask W1 ... fTask 13) and 8 io threads (fIO 0, fIO 1 ... fIO 7). The tasks are constantly jumping from one thread to another. Like a file could be opened in one io thread, then read in other io thread and closed in yet another one. So when the game crashes, it is quite hard (basically impossible at least for me) to figure out where the values came from, because they are from some other thread.
Game seems to consistently crash when you first place down your character on the globe. Bit hard to reproduce though as it can only be done once per account.
@EchoUrandom You say the game works flawlessly for you — does saving work?
Clouds are fine with a GTX 970 using nvidia 440.64. Had same weird looking ones as previous poster on a Vega 56 with Mesa 19.2.8.
Im able to get into the menu screen but it crashes when it loads the game
Im able to get into the menu screen but it crashes when it loads the game
Try loading again. It sometimes works, but don't expect to be able to save or play for very long.
Does anyone know if the character placement step is related to the online profile or if it can be worked around in the game config?
Does anyone know if the character placement step is related to the online profile or if it can be worked around in the game config?
The character placement step crashes, yes, but it's only done once. On subsequent launches you won't have to do it and the game thus won't crash there. That said, it still crashes when doing many other things.
Does anyone know if the character placement step is related to the online profile or if it can be worked around in the game config?
The character placement step crashes, yes, but it's only done once. On subsequent launches you won't have to do it and the game thus won't crash there. That said, it still crashes when doing many other things.
Does it work for you? Because I just can't get past it. I believe the game is crashing before it gets a chance to sync the config to the disk. Just curious - what FS are you using?
Does it work for you?
Yes. Done on 2 different PCs using 2 different accounts.
Because I just can't get past it. I believe the game is crashing before it gets a chance to sync the config to the disk. Just curious - what FS are you using?
ext4 on both.
After multiple debugging attempts and getting 24 hour bans from Denuvo, I finally managed to capture a crash. Specifically the character crash. From a quick look of the logs it crashes because of DOS error 0x2. According to the Microsoft docs 0x2 means ERROR_FILE_NOT_FOUND.
I will try to investigate further, but i got another Denuvo ban.
Edit:
After further examination the error code originates from the NtQueryValueKey function.
Edit 2:
My first conclusion is wrong, wine continues giving this error even after the crash.
Issue found __stdio_common_vsscanf needs further implementation.
The relevant portion of the log:
0030:Call ucrtbase.strpbrk(1b97a960 "https://planet.zaonce.net/api/zoo/avatars/friends",1422d3b68 "\r\n") ret=15e7e8f64
0030:Ret ucrtbase.strpbrk() retval=00000000 ret=15e7e8f64
0030:Call ucrtbase.__stdio_common_vsscanf(00000002,1b97a960,ffffffffffffffff,142302108 "%15[^:]:%[^\n]",00000000,0b22f0c0) ret=14021490a
Edit:
Also not it, the function does return but after the exception happens. If someone else want to give it a try here is the log.
From a quick look of the logs it crashes because of DOS error 0x2. According to the Microsoft docs 0x2 means ERROR_FILE_NOT_FOUND.
This, I think, I can explain.
When writing to a profile file (zplayer) the game creates a temporary file (zplayer.xxxxxx.temp). First it tries to open it with NtCreateFile(disposition=FILE_OPEN) to check if such a file already exists. Then it really opens it with NtCreateFile(disposition=FILE_CVERWRITE_IF).
You probably seeing an error returned by the first call.
The attached patch should help with crashes.
The attached patch should help with crashes.
The patch fixes the crashes when saving a profile or a zoo.
However, I still can't reliably get past the logo. In fact, the game always hangs with my original hack. The only way I am able to get into the game is with this alternative version of hack: https://github.com/AlexeyProkhin/wine/commit/d7c34568c2e26acb6e0df7af7651d15fce147799 and only when I enable ntdll debug channel.
Edit: You shouldn't probably use the patch. It is slightly broken. I just gave a link to it to showcase weirdness that is going on with the game.
The attached patch should help with crashes.
I might be stupid for asking, but could you tell me how to apply this patch? I'm not yet very experienced with these kinds of things. I used the proton build by JWolvers
The attached patch should help with crashes.
patch.zipI might be stupid for asking, but could you tell me how to apply this patch? I'm not yet very experienced with these kinds of things. I used the proton build by JWolvers
I'm currently trying to put together a working Proton with these patches, I can upload it somewhere and link here when I've got it working in case you're interested. Anyway, I suggest that you take a look at the README for this if you want to do it yourself: https://github.com/GloriousEggroll/proton-ge-custom
I created a new build with the new patches from @AlexeyProkhin and @gofman based on Proton 5.6 GE-2.
Install instructions:
Just unpack the build here: _~/.steam/root/compatibilitytools.d/_
Then restart steam and select _proton-5.6-GE-2-planet-zoo_ under The "Force the use of a specific Steam Play compatibility tool" option.
Edit:
I tested the build and I can also not get past the loading screen.
Edit:
I tested the build and I can also not get past the loading screen.
Same here. I have a working build that does get past the loading screen (has yet to fail a single time), but I can't seem to reproduce it, especially not with gofman's patch. Super weird.
@JWolvers @Newbytee Does activating ntdll debug channel help? (WINEDEBUG=+ntdll %command%)
@AlexeyProkhin I have it working now, reverted back to your first patch in combination with @gofman's patch.
@AlexeyProkhin I have it working now, reverted back to your first patch in combination with @gofman's patch.
Can you link to the patch you consider to be his first one? (https://github.com/AlexeyProkhin/wine/commit/c3036bc707ca180832eee52d8f2d0423dcf660e1?)
There is clearly some kind of race condition here.
Also, my second version of the hack is slightly broken because it does not force case insensitivity for NtQueryAttributesFile and NtQueryFullAttribuesFile that are also used by the game.
I uploaded my working build here. Check here for the install instructions.
@AlexeyProkhin I have it working now, reverted back to your first patch in combination with @gofman's patch.
Can you link to the patch you consider to be his first one? (AlexeyProkhin/wine@c3036bc?)
@Newbytee I meant that version.
There is clearly some kind of race condition here.
Also, my second version of the hack is slightly broken because it does not force case insensitivity for NtQueryAttributesFile and NtQueryFullAttribuesFile that are also used by the game.
@AlexeyProkhin So you think the environment variable lookup takes so much longer that it causes this race condition?
Edit: I am testing a combined version of your two patches to see if it is really a race condition.
Edit 2: I tested the patch and still get the same behavior. So indeed a race condition. (And adding WINEDEBUG=+ntdll %command% has no effect)
Hey, so what are the steps to getting it working? I understand you discovered the issue being something to do with casing of letters. But does anyone have some exact steps? I'd like to test it out and then inform people on the steam forums / proton DB if it works.
Hey, so what are the steps to getting it working? I understand you discovered the issue being something to do with casing of letters. But does anyone have some exact steps? I'd like to test it out and then inform people on the steam forums / proton DB if it works.
See the comment above you.
I uploaded my working build here. Check here for the install instructions.
@AlexeyProkhin I have it working now, reverted back to your first patch in combination with @gofman's patch.
Can you link to the patch you consider to be his first one? (AlexeyProkhin/wine@c3036bc?)
@Newbytee I meant that version.
There is clearly some kind of race condition here.
Also, my second version of the hack is slightly broken because it does not force case insensitivity for NtQueryAttributesFile and NtQueryFullAttribuesFile that are also used by the game.@AlexeyProkhin So you think the environment variable lookup takes so much longer that it causes this race condition?
Edit: I am testing a combined version of your two patches to see if it is really a race condition.
Edit 2: I tested the patch and still get the same behavior. So indeed a race condition. (And adding WINEDEBUG=+ntdll %command% has no effect)
It appears that this build is working fine. I am able to play the game and save it without crashing. When quitting it does leave a ghost process though.
I created a release here on GitHub in case someone else isn't a huge fan of Google Drive downloads (also includes branch with sources including patches): https://github.com/Newbytee/Protonbuilds/releases/tag/5.6-ge-2-planet-zoo-1
Just want to say bravo for your work, I've got it running as well
I created a release here on GitHub in case someone else isn't a huge fan of Google Drive downloads (also includes branch with sources including patches): https://github.com/Newbytee/Protonbuilds/releases/tag/5.6-ge-2-planet-zoo-1
Nice work! Indeed a better solution than my google drive link!
Thank you to all who contributed to this!
I have a curious question: Will this make it's way into the official proton development?
Thank you to all who contributed to this!
I have a curious question: Will this make it's way into the official proton development?
No most likely not. One of the patches used is a hack to force wine to be case insensitive. So we still need a better solution.
Thanks for the answer. :)
can't your transforme the forcing to be case insensitive to an variable we can pass to proton like some other wine flags ?
can't your transforme the forcing to be case insensitive to an variable we can pass to proton like some other wine flags ?
Grabbing an environment variable inline in the function is seemingly takes too long for what the game expects, causing it to freeze (likely some data race going on). It might be possible to do this somewhere else and use some form of global state or such, but ideally the developers should fix their mistake. For now, I think the best solution is to await their response and use a custom build of Proton specifically for this game.
I can not get the patch to work. I created the folder as per the instructions but I do not see proton-planet-zoo under The "Force the use of a specific Steam Play compatibility tool" option. The game is installed on another drive so maybe I need to put it in a different directory but I don't know where that would be. Can someone please point me in the right direction. I have never used a custom proton before.
What about the case-insensitive EXT4 support that was added in staging 4.10? Might be a way to have Proton create a case insensitive prefix for the special cases that need it.
What about the case-insensitive EXT4 support that was added in staging 4.10? Might be a way to have Proton create a case insensitive prefix for the special cases that need it.
Should work, but the game still requires another patch that is unrelated to case-sensitivity.
Yes, my point was that we might not need a 'hack' to fix the case insensitivity if a solution already exists somewhere in Wine development. I don't know if it's available outside staging, but Proton might want to pull in that feature regardless (if they haven't already).
What about the case-insensitive EXT4 support that was added in staging 4.10? Might be a way to have Proton create a case insensitive prefix for the special cases that need it.
That requires a flag to be set when creating the EXT4 file system to enable the feature. See this issue for more info.
I can not get the patch to work. I created the folder as per the instructions but I do not see proton-planet-zoo under The "Force the use of a specific Steam Play compatibility tool" option. The game is installed on another drive so maybe I need to put it in a different directory but I don't know where that would be. Can someone please point me in the right direction. I have never used a custom proton before.
@steve7233 Did you try restarting steam?
I can not get the patch to work. I created the folder as per the instructions but I do not see proton-planet-zoo under The "Force the use of a specific Steam Play compatibility tool" option. The game is installed on another drive so maybe I need to put it in a different directory but I don't know where that would be. Can someone please point me in the right direction. I have never used a custom proton before.
@steve7233 Did you try restarting steam?
Just tried restarting Steam... It didn't work. I found the pfx path for the game on the other drive. Should I create the folder compatibilitytools.d there and put the tool in that folder?
I can not get the patch to work. I created the folder as per the instructions but I do not see proton-planet-zoo under The "Force the use of a specific Steam Play compatibility tool" option. The game is installed on another drive so maybe I need to put it in a different directory but I don't know where that would be. Can someone please point me in the right direction. I have never used a custom proton before.
@steve7233 Did you try restarting steam?
Just tried restarting Steam... It didn't work. I found the pfx path for the game on the other drive. Should I create the folder compatibilitytools.d there and put the tool in that folder?
Follow these instructions: https://github.com/GloriousEggroll/proton-ge-custom#Installation
To verify that you installed it correctly, check if this file exists:
~/.steam/root/compatibilitytools.d/<name-of-custom-proton>/compatibilitytool.vdf
If it doesn't you installed it wrong.
It is there but because I installed the game to a different steam library then I suspect it might need to be installed some place else.
It is there but because I installed the game to a different steam library then I suspect it might need to be installed some place else.
I have my game installed on another disk too. It REALLY needs to be in ~/.steam/root/compatibilitytools.d/
.
Ok, then it should show up? I even tried restarting my computer. I looked carefully to make sure it was in the correct hidden folder. ~/.steam/root/compatabilitytools.d/. is there a case spelling for compatibility.d?
If it matters I use Kubuntu 19.10
I found out why Planet Zoo leaves a ghost process when closing. There are multiple threads waiting on a IO operation using the GetQueuedCompletionStatus function. When closing planet zoo, the named pipe associated with the GetQueuedCompletionStatus action is also closed. when the named pipe associated with it is closed while the call is outstanding, the function should returns FALSE. But it just never returns and keeps waiting for the IO operation to finish which it obviously never will.
Ok, then it should show up? I even tried restarting my computer. I looked carefully to make sure it was in the correct hidden folder. ~/.steam/root/compatabilitytools.d/. is there a case spelling for compatibility.d?
@steve7233 Sorry I don't know hot to help you, if it is really in the right folder then it should show up after a restart of steam.
You forgot the root folder.
~/.steam/root/compatabilitytools.d/
I just tried deleting and reinstalling the tool then restarting steam. It still doesn't show up in the games steam properties for steam play tool.
I installed the Ubuntu package for steam. I wonder if they moved anything that might require a sys link or something.
You forgot the root folder.
No, I didn't. It must be an ARK thing because it extracted into two locations. If I delete one folder the other one also gets deleted.
I don't think it's getting registered.
The files are all there and in the place that the install instructions said to install them except that steam doesn't appear to know about them. That makes me wonder if the Ubuntu steam package was modified and maybe the files should be installed someplace else or a sys link is needed.
That would be its own issue. You should probably create a new issue for it.
You forgot the root folder.
~/.steam/root/compatabilitytools.d/
I think Ubuntu uses a different directory actually. I don't remember which however.
I got an inspiration to rename the directory name. I remembered a few years ago where I had an invisible ASCII code creep in a copy-paste and I had to rename it to get it to work. It happened this time also. I just used the rename command and typed in the same directory name and restarted steam and it sees the proton version now. I started the game but I get a new error now. Instead of the C++ error now I get ' Sorry, something went wrong, for solutions please visit:
https://support.codefusion.technology/d4rw1n_d9u123j/?e=88500006&l=english
Clicking the link shows: "Currently your game purchase cannot be re-validated successfully, please wait 24 hours and try again.'
Denuvo got tripped, just wait 24 hours and try again. Also might want to delete the prefix folder, sometimes that helps.
I found the underlying reason for the game to be stuck at logo. It is another issue with NtCreateFile. Patch: https://github.com/AlexeyProkhin/wine/commit/0bdb95eef2a459a5dc8bc862f4d214635125dcaa.
The game starts with patched proton_5.0 for me: https://github.com/AlexeyProkhin/wine/commits/planet_zoo
I found the underlying reason for the game to be stuck at logo. It is another issue with NtCreateFile. Patch: AlexeyProkhin/wine@0bdb95e.
The game starts with patched proton_5.0 for me: https://github.com/AlexeyProkhin/wine/commits/planet_zoo
Did you try patching a newer version of Wine? I'm having no startup issues when applying the 3 patches (your first, second, and gofman's) on Proton 5.6 GE-2 if I omit the runtime check on your patch.
(I realise applying both of your patches might be redundant, but it works)
Did you try patching a newer version of Wine? I'm having no startup issues when applying the 3 patches (your first, second, and gofman's) on Proton 5.6 GE-2 if I omit the runtime check on your patch.
No, I didn't. I made the patch specifically for the latest proton. I think I saw a patch in staging that changes the same function so it is probably why it does not apply for you.
(I realise applying both of your patches might be redundant, but it works)
Which patches are you referring to? In order for game to work three patches are required:
(I realise applying both of your patches might be redundant, but it works)
Which patches are you referring to? In order for game to work three patches are required:
1. A case sensitivity hack to work around the crash at start ([AlexeyProkhin/wine@7b75d7a](https://github.com/AlexeyProkhin/wine/commit/7b75d7a74de5a0ab242923762e2147e2f32e545c)). 2. My latest patch ([AlexeyProkhin/wine@0bdb95e](https://github.com/AlexeyProkhin/wine/commit/0bdb95eef2a459a5dc8bc862f4d214635125dcaa)). Otherwise the game will not get past the logo. This patch is not strictly necessary and some GE builds also work. 3. Gofman's patch to make the game stable and not to constantly crash.
This https://github.com/AlexeyProkhin/wine/commit/7b75d7a74de5a0ab242923762e2147e2f32e545c, this https://github.com/AlexeyProkhin/wine/commit/c3036bc707ca180832eee52d8f2d0423dcf660e1, and Gofman's.
This AlexeyProkhin/wine@7b75d7a, this AlexeyProkhin/wine@c3036bc.
It is indeed redundant :smiley: You just need only one of those.
Also, with my latest patch using a ge build is not necessary anymore. Patched Proton 5.0.6 should work.
I made a new build: https://drive.google.com/file/d/1O2WaL95iOPki9-vg8jAcaGbfcqM9NCmh/view?usp=sharing . I would appreciate someone confirming that it works.
I just tried it and it works. When they say to wait 24 hours you don't have to wait all 24 hours maybe 6 hours or so. I created my avatar and placed my HQ. I then tried to exit the game so I could report here. The exits the main menu but doesn't completely shut down. I had to use the activity list and even then the regular end command didn't work. I had to right-click the game name and select send signal > kill. The main menu looks good. I will go test some more now. It looks like Proton is on the right path but we still need a better solution as the way this modifies wine to allow case insensitive file names is not acceptable in Linux as we are better than that. This is Windoze crap is bad for the security of the OS.
I just tried this custom Proton on Jurassic World Evolution and the program got further in starting. It eventualy went to a blank black screen but then got an abnormal termination leaving a hung screen requiring the user to use the skull and crossbones to kill the process.
I tried the last build by AlexeyProkhin. The game runs good. Thank you! :D
I noticed 2 minor issues:
I'm new to posting issues here. If you want more information please ask, cause I don't know what would be useful. :)
I'm new to posting issues here. If you want more information please ask, cause I don't know what would be useful. :)
I think you're doing well. Though, considering that you have the cloud issue, it might be useful to know what GPU you have and what driver you're using. AMD GPU with Mesa? You may also want to report the cloud issue to DXVK's issue tracker if it hasn't been done already.
It is AMD with Mesa.
It is AMD with Mesa.
What type? I have an AMD RX5700XT and have no issues.
It is AMD with Mesa.
What type? I have an AMD RX5700XT and have no issues.
What version of Mesa are you using?
20.0.4
I found out why Planet Zoo leaves a ghost process when closing. There are multiple threads waiting on a IO operation using the GetQueuedCompletionStatus function. When closing planet zoo, the named pipe associated with the GetQueuedCompletionStatus action is also closed. when the named pipe associated with it is closed while the call is outstanding, the function should returns FALSE. But it just never returns and keeps waiting for the IO operation to finish which it obviously never will.
Yes. Except the io threads open files not pipes. GetQueuedCompletionStatus() should exit when the completion port is closed in other thread but it never does. I have made some progress on the patch for the issues locally and the game finally exists properly.
20.0.4
Ah, all right. I had the issue with Mesa 19.2.8, perhaps it has been fixed in recent versions then.
Sorry, I could've known you'd like the versions, too. facepalm
AMD Radeon RX 480
Mesa 19.2.8
I found out why Planet Zoo leaves a ghost process when closing. There are multiple threads waiting on a IO operation using the GetQueuedCompletionStatus function. When closing planet zoo, the named pipe associated with the GetQueuedCompletionStatus action is also closed. when the named pipe associated with it is closed while the call is outstanding, the function should returns FALSE. But it just never returns and keeps waiting for the IO operation to finish which it obviously never will.
Yes. Except the io threads open files not pipes. GetQueuedCompletionStatus() should exit when the completion port is closed in other thread but it never does. I have made some progress on the patch for the issues locally and the game finally exists properly.
The named pipe was opened by a different thread, but in my log it was definitely a File IO thread waiting for this named pipe. But it is probably the same issue.
Sorry, I could've known you'd like the versions, too. _facepalm_
AMD Radeon RX 480
Mesa 19.2.8
So far everyone who reported the cloud issue has been using an AMD card with Mesa 19.2.8, seeing as JWolvers claims it isn't there for him with a newer version of Mesa, I think we can write this one off as a fixed Mesa bug.
Yes. Except the io threads open files not pipes. GetQueuedCompletionStatus() should exit when the completion port is closed in other thread but it never does. I have made some progress on the patch for the issues locally and the game finally exists properly.
The named pipe was opened by a different thread, but in my log it was definitely a File IO thread waiting for this named pipe. But it is probably the same issue.
Sorry. My mistake.
In any case, my testing shows the issue is not with pipes or files but rather with a completion port. The game, it seams, creates only one for all its io threads. The io threads open pipes and files, read and write them asynchronously waiting for results on the completion port. When the game exists the port is closed.
Hello @AlexeyProkhin, when you're happy with your patches, please send them to the upstream winehq mailing list for review.
Dropping the Mesa drivers label since it appears to be already resolved in at least mesa 20.0.
@AlexeyProkhin Tried the new patch for about 10 minutes. Saving worked and the game exited properly as well. Will update this when I give it a longer play.
Regarding various issues here:
The fix for crashes in game has been committed to upstream Wine: https://source.winehq.org/git/wine.git/commit/b0d3b5b69cf0be469a94a7330285a82f534ca3f1
Case insensitivity problem. I think Alexey's diagnosis of the problem here is perfectly correct. The problem does not look game specific though and it seems like we want case insensitive file name search for everything except \??\unix file names. I've sent a different patch upstream for review: https://source.winehq.org/patches/data/184213
Problem with NULL name in call to NtCreateFile(). Again, Alexey diagnosis looks correct but I feel like the core problem is not in nt_to_unix_file_name() but in ntdll_wcstoumbs(). I've sent a different patch for review: https://source.winehq.org/patches/data/184210
Hang on exit (abort wait on completion port).
I had a brief look at the patches here: https://github.com/AlexeyProkhin/wine/commits/planet_zoo
This looks sensible at the first glance. I feel like it could use a bit more tests involving direct calls to NtRemoveIoCompletionEx and checking the status and IO_STATUS_BLOCK returned from there (see test_set_io_completion()).
@AlexeyProkhin, would you like to add a bit more tests and send those patches to upstream Wine for review? Also, you probably want to return something else instead of STATUS_PENDING from DECL_HANDLER(remove_completion) in server/completion.c? I know it works without as NtRemoveIoCompletion() gets error status from wait function anyway, but I guess it would be something safer and cleaner. All these are just my thoughts, I am not the one to review the patches.
@AlexeyProkhin I tried your new build for multiple hours. Seems to work entirely fine. Only thing I discovered, is that if my computer locks the session (in other words, I left the game on but didn't play for some time) after unlocking, the screen stays black and doesn't show the zoo I was in. The cursor is the Planet Zoo cursor though and the game is still running according to Steam and the process manager, but the game doesn't respond to any inputs. I don't know if this is an issue with this game specifically or that this happens with any game that is run with Proton.
@AlexeyProkhin I have installed latest build you posted on a laptop with Nvidia 1050 GTX and the proprietary 435 driver, it works very well. Hours of playtime with no crashes.
Edit: when, however one exits to the main menu, from one game, and then tries to start a new one, the loading screen just never goes away, and the game I frozen on the screen (with music still playing)
@AlexeyProkhin, would you like to add a bit more tests and send those patches to upstream Wine for review?
@gofman I'd love to. However, the tests wouldn't be very useful. I actually started with writing a test for NtRemoveIoCompletion(). But I ended up writing this:
key = 0xdeadbeef;
U(iosb).Status = 0xdeadbeef;
res = pNtRemoveIoCompletion( h, &key, &value, &iosb, &timeout );
ok( res == STATUS_ABANDONED_WAIT_0,
"expected STATUS_ABANDONED_WAIT_0, got %#x\n", res );
todo_wine ok( key == 0, "Invalid completion key: %#lx\n", key );
todo_wine ok( U(iosb).Status == 0x500016, "Invalid iosb.Status: %#x\n", U(iosb).Status );
value and Information seem to contain garbage and always change. And I have no idea what the status supposed to mean.
Problem with NULL name in call to NtCreateFile(). Again, Alexey diagnosis looks correct but I feel like the core problem is not in nt_to_unix_file_name() but in ntdll_wcstoumbs(). I've sent a different patch for review: https://source.winehq.org/patches/data/184210
It may be worth adding "nameW.Buffer = 0;" like in my patch or a whole new test where Buffer and Length are 0 and a root directory is set. Just for the sake of reproducing the issue with Planet Zoo.
@AlexeyProkhin
@gofman I'd love to. However, the tests wouldn't be very useful. I actually started with writing a test for NtRemoveIoCompletion(). But I ended up writing this:
key = 0xdeadbeef; U(iosb).Status = 0xdeadbeef; res = pNtRemoveIoCompletion( h, &key, &value, &iosb, &timeout ); ok( res == STATUS_ABANDONED_WAIT_0, "expected STATUS_ABANDONED_WAIT_0, got %#x\n", res ); todo_wine ok( key == 0, "Invalid completion key: %#lx\n", key ); todo_wine ok( U(iosb).Status == 0x500016, "Invalid iosb.Status: %#x\n", U(iosb).Status );
value and Information seem to contain garbage and always change. And I have no idea what the status supposed to mean.
This result doesn't look impossible. It looks that return status makes perfect sense. If it happens that iosb.Status contains garbage with STATUS_ABANDONED_WAIT_0 returned then so be it, you can remove the check for it in test and add a comment stating that the iosb.Status is garbage. It doesn't necessarily mean we should simulate that garbage in Wine. That can be dependent on Windows version though, I use to check such things with testbot.winehq.org which can run your test on winxp - win10, unless you have all the versions in place.
Problem with NULL name in call to NtCreateFile(). Again, Alexey diagnosis looks correct but I feel like the core problem is not in nt_to_unix_file_name() but in ntdll_wcstoumbs(). I've sent a different patch for review: https://source.winehq.org/patches/data/184210
It may be worth adding "nameW.Buffer = 0;" like in my patch or a whole new test where Buffer and Length are 0 and a root directory is set. Just for the sake of reproducing the issue with Planet Zoo.
Yeah, right, I thought of that too but figured we have such a test already, see dlls/ntdll/tests/file.c, open_file_test(), line 508 (the line number is for current upstream Wine). The thing is it was not failing for me. It is quite possible as we have an initialized variable in the function, it can often happen to be 0 and work ok, but sometimes not. I could not reproduce this hang on Planet Zoo start most of the time until some changes in build happened and it started to fail reliably for me.
@AlexeyProkhin I tried your new build for multiple hours. Seems to work entirely fine. Only thing I discovered, is that if my computer locks the session (in other words, I left the game on but didn't play for some time) after unlocking, the screen stays black and doesn't show the zoo I was in. The cursor is the Planet Zoo cursor though and the game is still running according to Steam and the process manager, but the game doesn't respond to any inputs. I don't know if this is an issue with this game specifically or that this happens with any game that is run with Proton.
Yes, this issue is well known and affects many games in Proton.
To prevent lockscreen you should install Feral Game Mode and run it as a starting option with gamemoderun %command%
When clicking the Baobab tree 01
in the landscape editor... thing, in the map: Myeas Lake Iceland Zoo
The game freezes. Other tree's can be selected without incident.
(Do you need additional information? Tell me how to log it, and I will get it)
When clicking the
Baobab tree 01
in the landscape editor... thing, in the map:Myeas Lake Iceland Zoo
The game freezes. Other tree's can be selected without incident.(Do you need additional information? Tell me how to log it, and I will get it)
Add PROTON_LOG=1 %command%
to the game's launch options, reproduce the freeze, close the game, and upload the file 703080-steam.log here. It will be created in your home directory.
When clicking the
Baobab tree 01
in the landscape editor... thing, in the map:Myeas Lake Iceland Zoo
The game freezes. Other tree's can be selected without incident.(Do you need additional information? Tell me how to log it, and I will get it)
Add
PROTON_LOG=1 %command%
to the game's launch options, reproduce the freeze, close the game, and upload the file 703080-steam.log here. It will be created in your home directory.
I have done just that, and there is no such log file 😕
I also tried the user settings file with the same amount of luck, however, I could not reproduce the freeze this time around, picking the tree works just fine
I cleaned up my patches for the hanging issue at exit and made a build with them. The patches are in my repo. I would appreciate the testing.
This build doesn't work for me. The elephant shows up tosses the Earth globe then the screen goes black and NO mouse cursor. The music plays. I have the latest NVIDIA driver from https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa
If someone wants to try asking them for a favour regarding the case-sensitivity issue: https://issues.frontierstore.net/report-issue (you need a free account first).
Might be the same problem(s) that keep "Jurassic World: Evolution" from working.
I already made one at: https://issues.frontierstore.net/issue-detail/14441
Great work, thanks a lot for your effort. I can confirm that game works great with the latest build prepared by @AlexeyProkhin. Performance is the same like on Windows on following PC config:
Ubuntu 20.04
Ryzen 5 1500X
16GB RAM
Radeon 5600XT (mesa 20.0.6 from Kisak ppa + ACO enabled)
I just see minor issue, however I'm not sure if it's caused by Proton or just Steam client -> saved games uploading to cloud doesn't work, however downloading works properly (on Windows works good, for other games on Linux too).
Even with the latest build I still can't get anything but a black screen after the logo, I got all the menus for customizing my avatar but nothing but black in the middle of the screen.
PopOS 20.04
Ryzen 3600
16GB Ram
Radeon RX 570 (mesa 20.0.6)
Exact same issue but changing graphics settings doesn't change a thing
https://github.com/ValveSoftware/Proton/issues/3201#issuecomment-611902962
Installing mesa-ACO did the trick thanks for your work
I cleaned up my patches for the hanging issue at exit and made a build with them. The patches are in my repo. I would appreciate the testing.
with this @AlexeyProkhin patch works fine but I get a black screen in the middle of the screen and cannot play anything because it is blackscreen.
Manjaro OS
AMD Ryzen 5 3550H
AMD ATI Radeon RX 560x (mesa 20.0.6-2)
8gb of RAM
I can confirm the black screen with Mesa on AMD cards. Switching Mesa to the ACO shared compiler instead of LLVM fixes this.
After long sessions of debugging, log reading and looking at the disassembly, I think I pinpointed the crash. The game uses nt kernel functions to access files. The functions, however, are case sensitive by default (or, at least, implemented in wine as such). The game tries to read a file by its name in the lower case while the actual file on the disk in the camel case. The games fails to read the file and eventually crashes.
I made a hack to force the relevant functions to be always case insensitive: AlexeyProkhin/wine@c3036bc. With the workaround the game opens a window, shows a logo and, unfortunetely, gets stuck on it. Can someone else test the patch? I would appreciate confirming the game does not crash with it. I am especially interested what would happen for AMD users as the game loads nvapi64.dll for me which may explain its being stuck on the logo.
P.S. I made a build with my workaround: drive.google.com/file/d/15i9MSm_sPrAgo2wGaS_4ezCcHC-vvxgW/view?usp=sharing. It is totally untested however, denuvo blocked me for one day.This game works flawlessly after applying this patch! However, I have noticed the clouds are a bit buggy. Though I doubt this is going to stop players from playing the game given how it never even booted before hand. :)
I am using Fedora 31 with AMD RX 580 GPU using the open source drivers. I am not sure if this is reproduce-able but I will provide logs if necessary to fix it.
I've been out of the loop with the progress here since I reported it working well after the patch was added. I upgraded to an RX 5700 XT and started using Fedora 32. I noticed it crashes now. Not sure why. I can confirm that enabling ACO fixes this somehow. Also the clouds do not bug out anymore.
I cleaned up my patches for the hanging issue at exit and made a build with them. The patches are in my repo. I would appreciate the testing.
This build wasn't working for me with the game stuck in a black screen while the music plays after the Frontier Logo. Even the MangoHUD overlay froze.
But with Proton 5.0-8 RC, the game seems to be working perfectly. Played for about an hour without any problem. There isn't any graphical issue that I noticed and the process exits without hanging.
Arch Linux
Intel i7-7700HQ
GTX1060 with nvidia-vulkan 440.66
Cheers!
I cleaned up my patches for the hanging issue at exit and made a build with them. The patches are in my repo. I would appreciate the testing.
How do you get it to work with the patch? I just got Planet Zoo, didnt work out of the box with this crash message
I have the patch downloaded but what do I do from here to make it work?
Im on Ubuntu 18.04.4
@PenguLePenguin You need to opt in into proton beta. Here's a nice gif that shows how to do it.
This build wasn't working for me with the game stuck in a black screen while the music plays after the Frontier Logo. Even the MangoHUD overlay froze.
@SpntKbrg Nice to hear. But strange it didn't work with my build as the patches are the same.
@PenguLePenguin That patch is no longer needs to be applied manually. Use Proton 5.0-8 RC 1 as AlexeyProkhin suggested.
Proton 5.0-8 released today, can someone test and verify the game runs properly?
Fix crashes in Detroit: Become Human, Planet Zoo, Jurassic World: Evolution, Unity of Command II, and Splinter Cell Blacklist.
Proton 5.0-8 released today, can someone test and verify the game runs properly?
Tested just now. I haven't played for a longer period, but the game starts up and I'm able to load into a zoo. Also exits cleanly.
I just had a 20 minute test on 5.0.8 and did not notice any issues. Looks like we are done here.
Proton 5.0-8 released today, can someone test and verify the game runs properly?
Fix crashes in Detroit: Become Human, Planet Zoo, Jurassic World: Evolution, Unity of Command II, and Splinter Cell Blacklist.
Running the game without gamemoderun RADV_PERFTEST=aco %command%
causes the clouds to glitch still. Using the launch options fixes that. The game quits normally without getting stuck and doesn't appear to crash either.
Running the game without
gamemoderun RADV_PERFTEST=aco %command%
causes the clouds to glitch still. Using the launch options fixes that.
So it's most likely an LLVM bug. not a Proton bug. Apart from this, is there anything blocking this from becoming a whitelist request?
Very rarely it does still crash upon exiting the game for, al though it mostly exits just fine. It doesn't influence the playability of the game though.
Took 4 tries to reproduce. Steps to reproduce:
1) Open Planet Zoo
2) No need to do anything ingame. In the main menu just exit the game via the button in the top-right corner.
3) Repeat steps 1 & 2 until it crashes.
Result: https://imgur.com/a/3pHKApV
Proton 5.0-8 released today, can someone test and verify the game runs properly?
I just spent about an hour in-game. One thing I've noticed is that the game always starts up in windowed mode, regardless of which setting I closed it in, and if I load into a zoo without first switching it to borderless or fullscreen, the game gets very slow and laggy. Changing mode on the main menu before loading a zoo works fine, however. Overall playability is fine, though!
Proton 5.0-8 released today, can someone test and verify the game runs properly?
Fix crashes in Detroit: Become Human, Planet Zoo, Jurassic World: Evolution, Unity of Command II, and Splinter Cell Blacklist.
Also tested it and I can confirm that it works
Same for me, both Detroit demo (not the full version i have on epic games store...) & Planet Zoo works
Yup, new Proton working great!
For RADV users: the black screen issue is LLVM specific and now that ACO is enabled default, it should just work.
So, here the game crashes on selecting plants to set. Not everytime. I have followed the instructions to set proton version to 5.0-8, but it does not seem to exist, and 5.0-9 just starts a black screen.
The logging option does not produce any log file, so I am kind of at a loss here.
Most helpful comment
I'm encountering the same issue
System Information
steam proton log
steam-703080.log