Crossout (386180)
Compatibility Report
- Name of the game with compatibility issues: crossout
- Steam AppID of the game: 386180
System Information
- GPU: GTX 1070
- Driver/LLVM version: nvidia 396.54
- Kernel version: 4.16.0
- Link to full system information report as Gist: Gist
- Proton version: 3.16-4 beta
I confirm:
- [X] that I haven't found an existing compatibility report for this game.
- [X] that I have checked whether there are updates for my system available.
Symptoms
crashes after download. gjagent.exe stays open however, user must manually find and end process to relaunch. crash reporter does admittedly work though.
Reproduction
simply install and try to run the game.
I can confirm I have the same issue.
EasyAntiCheat
Implementation of some kind of whitelist/integration of EAC / anti-cheat systems into Proton is tracked here: #1468
Just FYI, the game seems to work now. When I downloaded the game, it also downloaded the EAC Proton runtime and after I launched the game, I've seen a "success" message in EAC log.
Also, there are 2 EAC .so files in the game directory. Does that mean the developer himself enabled Proton support for the game? (So far I haven't seen any official word from the developer regarding Proton support).
Just FYI, the game seems to work now. When I downloaded the game, it also downloaded the EAC Proton runtime and after I launched the game, I've seen a "success" message in EAC log.
Also, there are 2 EAC .so files in the game directory. Does that mean the developer himself enabled Proton support for the game? (So far I haven't seen any official word from the developer regarding Proton support).
The developers enabled support for it through EAC, their engine also has support for Linux. Though, their implementation is far from being playable for some. I can enter games, last for a few seconds to minutes before it just crashes, have yet to find a solution for it.
Then there's micro-stuttering, which can be be somewhat resolved via VMTouch (Preload game-files into RAM)
Crossout crashing with stack smashing detected
Issue transferred from https://github.com/ValveSoftware/Proton/issues/6278. @vars1ty posted on 2022-10-29T09:36:22:
Compatibility Report
- Name of the game with compatibility issues: Crossout
- Steam AppID of the game: 386180
System Information
- GPU: MSI GeForce RTX 3070 TI
- Driver/LLVM version: 520.56.06
- Kernel version: 6.0.5
- Link to full system information report as Gist: https://gist.github.com/vars1ty/d17023663ad7f346cb26ccfd66f842e3
- Proton version: 7.0-4
I confirm:
- [x] that I haven't found an existing compatibility report for this game.
- There is one, but it doesn't relate to this specific issue.
- [x] that I have checked whether there are updates for my system available.
Log: https://gist.github.com/vars1ty/3520dfe0b103578daa67522bfd0bcd63
Symptoms
The game fails to launch 9,5/10 of the times, ending up with errors like stack smashing detected.
I have also tried running it with Wine-GE and various different Proton versions (+ GE), none which were stable.
The only thing that has worked at times was running it through Bottles, setting the synchronization to FSync. But even with that, it only lasts a handful of minutes before crashing again.
Reproduction
- Install Crossout
- Launch the game
- Watch it crash most of the time
Edit
I've also gotten it confirmed by someone else that it occurs for them too, and not just me. Their distro is Kubuntu.
@kisak-valve (Apologies, just saw this was a transfer of @vars1ty's post ) I can confirm I get the stack smashing detected - Terminated error message as well.
(Where did you get your full set of logs from, out of curiosity?)
OS: Pop!_OS 22.04 CPU: i9-9900k GPU: Nvidia RTX 2080 RAM: 64GB
I have a full terminal print out of it below from where I launched Steam via the terminal.
*** stack smashing detected ***: terminated
ThreadGetProcessExitCode: no such process 909409
ThreadGetProcessExitCode: no such process 909355
ThreadGetProcessExitCode: no such process 908887
ThreadGetProcessExitCode: no such process 908866
ThreadGetProcessExitCode: no such process 908858
ThreadGetProcessExitCode: no such process 908828
ThreadGetProcessExitCode: no such process 908825
ThreadGetProcessExitCode: no such process 908819
ThreadGetProcessExitCode: no such process 908815
pid 908821 != 908820, skipping destruction (fork without exec?)
Game process removed: AppID 386180 "/home/jkimsey/.steam/debian-installation/ubuntu12_32/reaper SteamLaunch AppId=386180 -- /home/jkimsey/.steam/debian-installation/ubuntu12_32/steam-launch-wrapper -- '/home/jkimsey/.secondary_drive/SteamLibrary/steamapps/common/SteamLinuxRuntime_soldier'/_v2-entry-point --verb=waitforexitandrun -- '/home/jkimsey/.secondary_drive/SteamLibrary/steamapps/common/Proton 7.0'/proton waitforexitandrun '/home/jkimsey/.secondary_drive/SteamLibrary/steamapps/common/Crossout/launcher.exe' -steam", ProcID 909219
ThreadGetProcessExitCode: no such process 909219
ThreadGetProcessExitCode: no such process 908837
ThreadGetProcessExitCode: no such process 908693
ThreadGetProcessExitCode: no such process 908692
Game 386180 created interface STEAMUSERSTATS_INTERFACE_VERSION012 /
Game 386180 created interface SteamController008 /
Game 386180 created interface SteamFriends017 /
Game 386180 created interface SteamInput006 /
Game 386180 created interface SteamUser021 /
Game 386180 created interface SteamUser021 / User
Game 386180 created interface SteamUtils010 /
Game 386180 method call count for IClientControllerSerialized::GetHandleForGamepadIndex : 29086
Game 386180 method call count for IClientUserStats::SetAchievement : 43
Game 386180 method call count for IClientUserStats::StoreStats : 1
Game 386180 method call count for IClientUserStats::RequestCurrentStats : 1
Game 386180 method call count for IClientUtils::RecordSteamInterfaceCreation : 10
Game 386180 method call count for IClientUtils::GetAppID : 15
Game 386180 method call count for IClientFriends::GetFriendByIndex : 33
Game 386180 method call count for IClientFriends::GetFriendCount : 1
Game 386180 method call count for IClientFriends::GetPersonaName : 2
Game 386180 method call count for IClientUser::GetAuthSessionTicket : 1
Game 386180 method call count for IClientUser::GetSteamID : 49
Game 386180 method call count for IClientUser::BLoggedOn : 29171
Uploaded AppInterfaceStats to Steam
(process:909286): GLib-GObject-CRITICAL **: 22:56:22.800: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
(Where did you get your full set of logs from, out of curiosity?)
Via PROTON_LOG=1
@vars1ty Thanks. I have found one common connector here. On Proton 7.0-4 Stable, this event (shown below) always happens before a Stack Smashing crash happens:
644046.945:0350:0354:fixme:advapi:GetCurrentHwProfileA (0000000000112C58) semi-stub
644046.945:0350:0354:fixme:process:GetSystemRegistryQuota (0000000000112CD8, 0000000000112CDC) faking reported quota values
644047.206:0350:0560:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\rsaenh.dll" : builtin
644048.816:0350:0354:fixme:win:FlashWindowEx 000000000011C8B0 - semi-stub
*** stack smashing detected ***: terminated
It seems like that each time the rsaenh.dll is unloaded, a stack smashing event happens that crashes the game. This may be key for any devs who wanna try and figure out how to mitigate this issue. I've tried several of the Proton launch flags, with no avail. The crash log above was captured with PROTON_NO_ESYNC=1, so that's why it's a bit more messy, but has more info (to me it looks like there is more info).
But yeah, hopefully with this info, a fix/workaround can be found. I'm actually not sure why Proton Experimental isn't working, I need to do more testing on that.
Update: just tested with Proton Experimental with the same settings as above, and it's definitely an EAC issue with regards to that. Here's the crash log from just before the crash at startup:
645163.825:0518:0540:trace:seh:RtlRestoreContext returning to 000000007B6325FA stack 0000000011D5D640
645163.825:0518:0540:fixme:iphlpapi:NotifyAddrChange (Handle 0000000011D5E118, overlapped 000034B000304B10): stub
645163.826:0518:0540:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\wlanapi.dll" at 0000000399110000: builtin
645163.826:0518:0540:fixme:wlanapi:WlanEnumInterfaces (0000000000000001, 0000000000000000, 0000000011D5D0B8) semi-stub
645163.831:0518:0540:fixme:winsock:setsockopt Ignoring SO_RANDOMIZE_PORT
645165.851:0390:0394:trace:loaddll:build_module Loaded L"Z:\\home\\southernwolf\\.secondary_drive\\SteamLibrary\\steamapps\\common\\Crossout\\EasyAntiCheat\\easyanticheat_x64.dll" at 00000002F6650000: builtin
*** stack smashing detected ***: terminated
pid 1367949 != 1367947, skipping destruction (fork without exec?)
So yeah, for whatever reason EAC seems to work ok on Proton 7.0-4 (assuming it's not causing the stack smashing there), but it crashes instantly on Proton Experimental.
Replying to https://github.com/ValveSoftware/Proton/issues/1937#issuecomment-1298272954
@JoshuaKimsey - Tested with 7.0-4 and crashes on it too, just that it takes a few minutes. Here's some info about rsaenh though, might try and hand-replace it later today/tomorrow to see if it fixes anything.
Alright I just tried to replace the DLL with one from a brand-new Windows 10 VM, it launched and seemed to work until it crashed. Gonna look for other solutions, though this seems a lot like it's something that either Easy AntiCheat messed up, or Targem really don't know how to code.
Here's a bug report I've made on their tracker (don't expect them to care though), feel free to upvote it.
Cool, I can do that. It's unfortunate that didn't work, but I'm not wholly convinced it's EAC alone doing it. The reason being that last night I was able to play for over an hour straight, with no issues. But, later on when I relaunched the game, it crashed within 10 mins. I feel like if it was EAC, it would crash like it does with Proton Experimental, instantly. But, then maybe not...
IDK, hopefully either Gaijin can fix this, or perhaps the Proton devs can find a work around for it.
Yeah experienced the randomness of it working for hours and then randomly just deciding not to work. I guess either wait for someone to hopefully find a fix for this, since Targem aren't really the most caring developers when it comes to Linux.
XO is having an update today apparently, so let's hope that they do something to fix it. Will edit this message later when I know if it's been fixed or not.
UPDATE: Not fixed.
Dang it... Does it crash instantly or after a few mins?
@JoshuaKimsey - After a few minutes, like before.
Although I might have found a very hacky and weird way of mitigating some of the crashes, no promises though as I'll do some more testing (and I'll probably jinx myself for saying this). Been in-game for I don't know, around 30 minutes? No crashes so far.
Alright restarted the game and it decided to start dying again, just like before.
Yeah. I had the same experience. Occasionally it won't crash and keeps going. Then it does nothing but crash...
@vars1ty What was the hacky way you found to make it work? Figured I could give it a try, if nothing else. I know some people on the Steam discussion forums are talking about Bottles and ProtonGE, but also seemed to have limited success, at best.
@JoshuaKimsey Normal works on Bottles + ProtonGE-38, but there is a problem after the update and this problem memory leak
@JoshuaKimsey - Bottles and ProtonGE only works for about 5 minutes, then it crashes. The "hack" I did was by forcing DXVK to:
- Run DX11.0 (not 11.1 which XO defaults to)
- Spoof GPU PCI Device ID to something random
- Limit the FPS to 144
- Swap GPU Description to "AMD", which is also displayed in-game
- Enable some
nvapiHackwhich reports NVIDIA GPUs as AMD ones - Remove some DX11 barriers
Here's the config file: https://workupload.com/file/RMrBQ8CdZme
Environment variable: DXVK_CONFIG_FILE=/home/USERNAME/dxvk.conf
Runner: Soda 7.0-4
Ran through Bottles from Flatpak
Let me guess, no improvements on this?
For those still with this issue (perhaps you @Zykon88 and @JoshuaKimsey ?) Tested playing for around 2h/3h today and no crashes so far (probs gonna jinx myself when I get on next time). Seems like some update fixed it, here's the config I'm using:
- Bottles from the Arch AUR, for other distros: the non-flatpak version
- Synchronization on ESync for testing (switch to FSync if you can since it has better performance)
- Runner on GE-Proton7-39
- Preload Game Files turned on (package for doing this is
vmtouch) - Bottles & Steam Runtime turned off
- VKD3D on
vkd3d-proton-2.7 - Latest Crossout Client + Launcher update
- No custom environment variables
Edit: Tested restarting the game between the 1h-mark, lasted for yet another hour afterwards until I closed the game.
* VKD3D on `vkd3d-proton-2.7`
A bit off-topic regarding the latest issue, but I know that one of the recent updates introduced dx12, but I couldn't find any way to enable it. Since you mentioned vkd3d, did you find a way to enable dx12 in Crossout?
@user1-github - No, I just have all my runners set to the latest version in case there's any fixes
@vars1ty Ok, that's good to know. I haven't actually tried now in a week or so. What I'm gonna do is test with Proton Stable and Experimental first, then see if I need to explore Bottles and GE. According to your info, you have Bottles installed, but turned off?
@vars1ty I can confirm it is still broken on Proton 7.0-4 and Experimental. I'm now gonna go through and see what I can do with the info you gace.
@JoshuaKimsey No you have to use Bottles with latest Proton-GE from the Runners-tab (in this case, 39). The other runners only caused issues for me, so I guess it varies.
Steam Crossout though seems completely dead, as it refuses to even launch for me
@vars1ty Any chance you could create a tutorial for how to get this setup? I tried using Bottles, but I couldn't figure out how to get it working with Proton-GE inside of it. It didn't work running Steam through Bottles.