Apex Legends (1172470)

[alosarjos]

Compatibility Report

• Name of the game with compatibility issues: Apex Legends
• Steam AppID of the game: 1172470

System Information

• GPU: RX 5700 XR
• Driver/LLVM version: 20.2.1
• Kernel version: 5.9.3
• Link to full system information report as Gist
• Proton version: 5.13

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

Game launches but ends up with error message because of Easy Anti Cheat, so unplayable.

[esijg]

Same here, minus the error message. It displays the Easy Anti Cheat logo, and then respawn logo, and then silently crashes to the desktop. Sometimes it crashes but Steam thinks it's still running in the background even.

[torokati44]

I didn't even get that... :D Pressed Play, the little update/setup dialog disappeared when it finished, but nothing happened after that... A few moments later the Play button became active again, and that's it. No message, no error, no nothing. Meh...
(Although I installed it on an NTFS partition, which has caused some issues in the past for a few other games, even though it really shouldn't... Most games work perfectly fine on it!)

[alosarjos]

I was able to get to the main menu and even setup the graphics settings. But then it looks like there is a EAC timeout.

[Alimba86]

I had the exact same issue, EAC will throw me out yesterday. Today that I tried again seemed better but I didn't dare to play online.

Other than that it had a bit of a struggle on the first launch, then Steam cached the Vulcan shades so, after that it seems that runs as good as in Windows if not better.

[daigennki]

Same here. After a minute or two, I get thrown out of whatever I was doing, even just the main menu. Until getting disconnected though, I can seemingly do anything just fine, whether it's the firing range or a normal match. I only tried the latter once for obvious reasons though. When I get thrown out, the game gives an error screen with "ERROR: The client is not running the anti-cheat, or has failed the anti-cheat authentication"
There's also some short hangs upon map load, probably because of shader compiles. EAC not working is a much worse problem though.

[rfxDarth]

Seems like something's changed, as I now can spend however much time in menu's and shooting range. A couple days ago, while testing on lutris+origin, I was being kicked out regardless of what i was doing. I'm still getting kicked out from actual games, though.

[ghost]

Alright, I really tried to get this run by taking a deeper dive into Proton's functions. And I think the problem is at a missing implementation of BCrypt. If I look at Proton's Log, there are 9809 lines containing BCryptGenRandom ignoring selected algorithm. If I try to set the crypt32.dll in the winecfg with the prefix of the game to "Native (Windows)", I get an error message that looks like if it's coming from Wine when trying to start the game that says, Could not find Z:/home/lightosk/bigspace/SteamLibrary/steamapps/common/Apex Legends/EasyAntiCheat.dll. I have no idea if that is even related, but it could be. I don't want to interpret too much in here, I could write an essay about what I think could have caused this.

Summed up, the facts that are observable:

• If you start the game, you get kicked out after a minute or so with an EAC error The client is not running the anti-cheat, or has failed the anti-cheat authentication: Authentication timed out (1/2)
• In Proton's log, steam-1172470.log, the errors and messages are mostly normal and known from other games, but a LOT of that is :fixme:bcrypt:BCryptGenRandom ignoring selected algorithm

[ghost]

I just found a bug on Wine's bugzilla about this. It links to a commit on Wine-staging, which is only 11 days ago. I'll try to build this version now and see if Apex works there.

[ghost]

Okay, then it even works less because it fails to find some DLLs of steamclient64.dll. I guess these are provided by Proton and Windows itself only.

[VelorumS]

I'm trying to make the patch work with Proton (by just following the build/install instructions in https://github.com/ValveSoftware/Proton).

The issue is that those patches are against the wine master while the Proton uses wine 5.13.

I've tried to drop in wine 5.21 into Proton build: the game doesn't launch.

Next thing I'll try is to backport the patchset to wine 5.13.

EDIT: the patchset doesn't build cleanly with Proton - cross-compilation of bcrypt.dll fails.

@Lightosk how are you testing this?

[VelorumS]

The fixme:bcrypt:BCryptGenRandom ignoring selected algorithm just says that wine uses the wrong RNG algorithm. At this point can't really tell if it's the cause of the problem.

That bug on Wine's bugzilla is not related to the RNG. That bug is about the fixme:bcrypt:BCryptSecretAgreement errors so it can't be the solution.

[Luis4ever22]

Hoping for a fix! :O

[esijg]

I am pretty sure we'll see some progress on this once Linux 5.11 comes out thanks to Collabora's work on DRM compatability https://www.gamingonlinux.com/2020/10/collabora-expect-their-linux-kernel-work-for-windows-game-emulation-in-kernel-5-11

[VelorumS]

It's not really related to the DRM compatibility.

The anticheat checks for wine specifically and treats it as one of the platforms. But the anticheat server doesn't host the driver modules for this game for the wine platform.

EasyAntiCheat detects Wine as host platform/OS, causing failure to download correct EAC game client/driver modules (avoid exporting 'wine_get_unix_file_name' by name)

My thoughts: EA didn't bother to set up wine support with EAC developers, or EAC developers didn't bother to develop a decent anticheat for wine. And from the wine side it's as usual: need to keep implementing windows.

[Jan200101]

Apex Legends used to be playable on Linux for some time so I suspect it to be a case of Wine support being pulled

[F41S3]

Has there been any progress on getting Easy Anti Cheat and others working as the new linux kernel 5.11 is rolled out?

[DavidHusicka]

Has there been any progress on getting Easy Anti Cheat and others working as the new linux kernel 5.11 is rolled out?

It's not about the Kernel

https://www.reddit.com/r/linux_gaming/comments/l6cam9/syscall_dispatch_and_kernel_511_clarification/

[Gotchfutchian]

Been a couple of months, wondering on development on EAC on proton?

I had a few ideas but im not a developer, im just a nerd with some ideas;
-Decompile and recompile EAC under Winelib?
-Make proton report back to EAC that its just windows instead of wine.
-Patch out EAC (stupid and not worth bugging people with dedicated cheaters)
-Work with EAC devs to help with compatibility but maintain the Anti-Cheat part.

If there is more info I should know about and I might just waste a couple of days testing it out.
(no I refuse to use QEMU/KVM, I dont think I have the power for that assuming it emulates the GPU.)

[leonhma]

Hi, iv'e been trying to make this work, too. What i have found so far, is that during the install, EAC tries to download dependencies. It somehow detects the os as wine and therefore requests the 'wine' version of the EAC client. This version of the client should just be the same as the one used for windows, since thats the entire point of wine. Either EA/Respawn have specifically disabled the wine 'os' or it is an off-per-default option in eac to support wine.

Now for the solution i have already tried (not very thoroughly though) and not succeeded:
If we can use some software like mitmproxy to redirect the eac setup from the wine download URL to the files for windows, the right client might be downloaded. This could be prevented by EAC through checksums, etc. though and it would always be preferred if EAC/Respawn just enabled support for wine.

This is what i found in about three days of research. The infos are mainly from blogposts, logfiles and my creative thinking, but i think this should be rather accurate. Hope it helps.

Here is the python script i tried with mitmproxy in case anyone is interested https://gist.github.com/leonhma/858dced671358f02187b2fa251a18850

Edit: I think it might be good to let Respawn or EAC know of this Problem and how they could fix it.

[VelorumS]

@leonhma you know, about a week ago Valve has announced Steam Deck. It's a handheld PC that's supposed to eventually run all games of the Steam library, and it runs Arch-based Steam OS with Wine/Proton.

More importantly for us, Valve mentioned in their FAQ about Steam Deck that they're working with the BattlEye and EAC anticheat developers to get support for Proton ahead of launch (2022).

[Nix-id]

@leonhma
how i can use your script in proton?
just place in root folder or smt else?

i try to run New World and sems like it have same problem.

[leonhma]

@Nix-id I tried it with lutris and changed the install script so this script may not be very fitting here and would definitely require some additional work.

As @ChipmunkV said, valve will probably push for Linux support by EAC with the release of Steam Deck

[valeth]

There might be some hope as Epic just announced Proton support.
https://dev.epicgames.com/en-US/news/epic-online-services-launches-anti-cheat-support-for-linux-mac-and-steam-deck
Now it's up to Respawn/EA to enable it

[felipecrs]

Season 11 is out... did anyone test?

[Arbitrate3280]

Just did, no changes. EAC still not enabled.

[felipecrs]

Ok... I guess they will wait for Steam deck. Sad :(

[VelorumS]

It doesn't even look like they've updated EAC at all: it's still looking for the wine64 module.

[kaganndemirr]

Steam deck has been delayed to Feb 2022 so maybe enabling eac for Apex delayed too

[felipecrs]

I would not doubt if someone told me that this was the reason Steam deck was delayed, lol!

[Gothfinger]

For everyone experiencing the vsyscall and SMSW errors, as well as apex randomly crashing, I seem to have found a temporary workaround. Adding vsyscall=emulate clearcpuid=514 to the kernel arguments seems to fix the errors and crashing completely. Hope this helps

I tried this and it did not help at all. Game still crashes after ~30 min. Anyhow vsyscall=emulate seems to be the default so not sure if it's even necessary to add this

[AdverseMiller]

If you're on a recent kernel, vsyscall is set to 'xonly' by default, which is the entire reason apex is broken

[Gothfinger]

If you're on a recent kernel, vsyscall is set to 'xonly' by default, which is the entire reason apex is broken

Well it didn't help anything for me unfortunately. My game still crash after roughly 30 min. Completely freezes

[Gothfinger]

Finally managed to get a PROTON_log of the crash that is "only" 2 GB. I'm however not able to upload it since maximum filesize is 25MB.

Anyone can help me here? There is no way to take a smaller log since I have to keep the game running for some time before it crashes and then it will have collected a few Gigs

[ParetoOptimalDev]

For everyone experiencing the vsyscall and SMSW errors, as well as apex randomly crashing, I seem to have found a temporary workaround. Adding vsyscall=emulate clearcpuid=514 to the kernel arguments seems to fix the errors and crashing completely. Hope this helps

I tried this and it did not help at all. Game still crashes after ~30 min. Anyhow vsyscall=emulate seems to be the default so not sure if it's even necessary to add this

For what it's worth GE-Proton9-14 crashes for me with dx12 while GE-Proton9-13 does not.

Maybe try GE-Proton9-13.

[ParetoOptimalDev]

Finally managed to get a PROTON_log of the crash that is "only" 2 GB. I'm however not able to upload it since maximum filesize is 25MB.

Anyone can help me here? There is no way to take a smaller log since I have to keep the game running for some time before it crashes and then it will have collected a few Gigs

Typically either:

• the last few hundered lines of a log file are the most valuable; or
• the first error in a log file happens, then duplicates get spammed over and over, but the first instance was most valuable

Maybe look in your logs for those two patterns and post both if you aren't sure?

[Gothfinger]

Replying to #4350 (comment)

Hi,

I've attached logs of beginning, end and also managed to find the problem section (where I think crash occurred)

steam_log_1172470_END.log
steam_log_1172470_Problem_Section.log
steam_log_1172470_START.log

I think the starting errors are just related to gamemode? But not sure...It was never a problem before
gamemodeauto:

[aASDa213ASD]

Replying to #4350 (comment)

Hey, I didn't have much time to play, however every time I tried - there are couple of things going on.
Let me try to explain it in some handy way.

To begin with - memory usage, so what happens here is seems to me like a memory leak because the longer apex is opened the more RAM it consumes. The maximum amount I've reached was 18Gb of raw memory being consumed by a single process of this game. At some point this game starts to murder my poor hard drive instead of ram and reasonably enough my whole system dies.

Second thing (related to first) - amount of threads. If you look at btop you will notice that sometimes process of apex is called 'MainThrd' or 'wine64'. Feels like it randomly chooses it's name? Anyway, the longer you play - the more threads will r5apex.exe (or any names above) create. Looking at those threads in htop tells me that they don't do much except consuming memory and doing something heavy upon spawn. I'm collecting about 1800 threads before apex starts to behave weird and start killing my hard drive.

Third (related to second) - stutters, every time another junk thread is spawned my frametime successfully drops to 0 for a smaaaaaall millisecond up to the point that it's hard to notice this freeze if you are running 300+ fps. But if you go with something more human like 144 - you will definitely notice these stutters.

I finally decided to run PROTON_LOG="1" and got some fancy things like yours, take a quick look:
apex-stack-traces.txt

Not only I see some EXCEPTION_ACCESS_VIOLATION here, there's this unwind happening every millisecond of lifetime of this process under proton. I didn't analyze any proton logs before in my entirety so I can not really tell if it's "NORMAL" or not. Looking at the rest of my log which is big I can see that problem is somewhat related to 'r5apexpreloader.dll' by looking at this little line at the end of all chaos:
8476.995:01a0:0204:warn:seh:virtual_unwind backtrace: 00006FFFFD733C70: L"r5apexpreloader.dll" + 0000000000003C70.

To add a little more regarding threads (not excluded that this happens only when I close the game since it's at the very bottom of the log):
8477.002:00e0:03f4:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"

Feels like I tried everything to run away from those stutters and other problems but there's nothing I can really do. So let me know if full log file would be good to have. Would be glad to hear anyone who's more competent in the topic.

[Gothfinger]

This fixed everything for me:

vm.max_map_count=16777216

[aASDa213ASD]

16777216

A value of vm.max_map_count=16777216 (16.7 million) is an extremely high setting, and while it may not directly cause harm, it’s quite excessive. You are basically forcing your kernel to be aware of 16 million memory maps (even if they are not yet made). I doubt that you need more than Arch Linux default value of 1048576 (1 million). Also I highly doubt that THIS is what fixed your issue. It lowkey makes no sense to me.

[gofman]

16777216

A value of vm.max_map_count=16777216 (16.7 million) is an extremely high setting, and while it may not directly cause harm, it’s quite excessive. You are basically forcing your kernel to be aware of 16 million memory maps (even if they are not yet made).

I think this is not the case, it is just the limit upon reaching which the kernel will refuse to create more VMAs for the process. So if none of your process tries to use more than 60000 VMAs having this limit as 60001 or 16777216 will make literally no difference.

In case of doubts, you can verify the above by doing 'grep -R max_map_count' in the root of kernel source tree and see all the usages.

[yoohahn]

Replying to #4350 (comment)

Don't think it is a problem either. PopOS's default is set to 2147483642. Have no issues (what I know if at least) with that.

[aASDa213ASD]

After investigating the question a little more there's a need to increase the vm.max_map_count only if your game is crashing. However, default Arch value is already somewhat safe and big enough for most games NOT to crash.
SteamOS uses some insane value like PopOs does that @yoohahn mentioned (MAX INT 5) - 2147483642.
So yeah increase it if it helps, otherwise there's no real need to touch it.

Here's a comprehensive arch wiki page: https://wiki.archlinux.org/title/Gaming
CTRL + F > 'Increase vm.max_map_count'

My stutters were unrelated to apex. Apex has it's own problems but that's a whole different story at this point.

[VelorumS]

Guaranteed freeze on "waiting for players" when loading into the match. One time I've managed to get to character selection, it froze afterwards. One time I've managed to reconnect to the game: froze when quitting to the lobby. One time I've reconnected to the game and it froze immediately while dropping from the dropship.

There is often a black screen instead of the game's main menu.

Worked fine the day before yesterday.

NVIDIA 550.120, X11, Manjaro KDE
Proton 9.0-3 or Experimental bleeding-edge

Both DX11 and DX12 modes.

Nothing different and nothing is happening in console-linux.txt log.

EDIT: the day after there are no freezes.

[disconnect3d]

I can confirm Apex Legends crashing and freezing randomly on Ubuntu 23.04. The reason for this seems to be the default virtual memory pages limit (sysctl vm.max_map_count) as when the Apex Legends process froze, I can see that it hit the limit:

$ ps auxf | grep 62946
user         62946  275  6.1 153387084 8133776 ?   Sl   01:58 105:49  |   |       |               \_ Z:\home\user\.local\share\Steam\steamapps\common\Apex Legends\r5apex.exe -steam

$ cat /proc/62946/maps | wc -l
65532

$ sysctl vm.max_map_count
vm.max_map_count = 65530

Setting the limit to a high number, e.g., via sudo sysctl -w vm.max_map_count = 15000000 seems to fix the problem. Note that Nix and Arch Linux sets it even higher.

(Fwiw I've also tweeted about this here: https://x.com/disconnect3d_pl/status/1848737318103904354)

IMHO Proton should set this setting accordingly when being installed, or, when a game is launched. Or, it could inform pr warn the user to do it themselves.

[kisak-valve]

Changing vm.max_map_count requires privilege escalation. That's out of scope of the Proton project and something for distros or individual users to control at their discretion.

[disconnect3d]

Hmm... does Steam require root privileges on install time? If it does, maybe it would be good to add it there?

Otherwise, is there any logging or popup Proton could do to warn the user? I can see some umip: wine_threadpool[pid] ...: SMSW instruction cannot be used by applocations. logs in dmesg. Could Proton write a warning to dmesg on startup that the vm.max_map_count is likely too low which may cause games to crash or freeze, encouraging users to change the setting?

Interestingly, on the kernel level it seems that a memory map related syscalls would return a -ENOMEM:

• https://elixir.bootlin.com/linux/v6.10.14/source/mm/mremap.c#L673
• https://elixir.bootlin.com/linux/v6.10.14/source/mm/mremap.c#L902
• https://elixir.bootlin.com/linux/v6.10.14/source/mm/nommu.c#L1306

But I can't really see that when the game already freezes. Instead, when tracing it with strace -ff -p <pid> I can see lots of recvmsg with -EAGAIN and then SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x224bbb650} where 0x224bbb650 is address of a private guard page of 4TB (with ---p permissions/mode) and some SIGSYS signals from seccomp with __NR_exit_group syscall (likely unrelated to the crash etc).

Eventually we could also report this to specific Linux distros, or, send a patch to kernel upstream to add a warn_once when the limit is hit (hoping that they will accept it). However, this won't fix the problem for current users and they would have to refer to googling or finding this GitHub issue to resolve it...

[waspennator]

https://x.com/PlayApex/status/1852019667315102151

Linux and Steam Deck support is officially being blocked cause

"In our efforts to combat cheating in Apex, we've identified Linux OS as being a path for a variety of impactful exploits and cheats."

[IcHiAT]

Ouch... Thats why I can`t Play : ((

…

Am 31.10.2024 um 18:56, waspennator ***@***.***> schrieb: https://x.com/PlayApex/status/1852019667315102151 Linux and Steam Deck support is officially being blocked cause "In our efforts to combat cheating in Apex, we've identified Linux OS as being a path for a variety of impactful exploits and cheats." — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[xPakrikx]

this looks like sloppy excuse to implement ea anti cheat. They can run experiment now, statistics before ban and after. Its sinking ship anyway.

[polluxau]

Such a shame.

I wanna thank all of the valve developers who maintained this game on Linux for the past 2 years I think?

I rlly appreciate it :)

[SopaDeMacaco-UmaDelicia]

It was a good run 😢

[Benutzername-gif]

Valve must now finally show determination in supporting SteamDeck and SteamOS and revoke Source engine license from Respawn

[hellp]

Yeah, thanks for everyone who made it possible. ❤️ Really sad about this development, but maybe it's time to move on.

[Nightmayr]

This sucks as a legit player looking to unwind most evenings, but there does seem to be quite a big community that uses Linux to cheat, so unfortunately the action taken is understandable. Really hope Valve can maybe work with some of the major players in the industry to get to a point where publishers have confidence in allowing online multiplayer games on Linux. Thanks everyone for all the work up until now in letting us play while we could

[Benutzername-gif]

There was no Linux cheating or not more than WIndows. They are all out lying about it.

[einCyberSimon]

Well, they posted some update on twitter: https://x.com/Respawn/status/1865148176275247312
If the data they share is accurate (even if not very detailed) I would say that cheating has reduced. I am by far not a fan of the decision to ban Linux players, but apparently it payed off. I just wished there was better communication.

[guillaumeboehm]

Well, they posted some update on twitter: x.com/Respawn/status/1865148176275247312 If the data they share is accurate (even if not very detailed) I would say that cheating has reduced. I am by far not a fan of the decision to ban Linux players, but apparently it payed off. I just wished there was better communication.

Honestly "not very accurate" is a big euphemism... People working with data know how to use data, and a bulls* graph like this doesn't tell anything. If it's not detailed it's because they're better off leaving it vague to make it seem like a big deal... Or they are absolutely incompetent, don't know which one is worse actually.

[Freddycat]

I miss playing this game on linux, it performs so much better without having to deal with windows BS