This might be a line of interest:
263319.184:0140:0144:err:module:import_dll Library icu.dll (which is needed by L"S:\\common\\FF7EC\\FF7EC_Data\\Plugins\\x86_64\\FirebaseCppApp-11_9_0.dll") not found
Thanks for the input, but that occurs in both logs. (The game works as normal under Ubuntu 22.04.)
It may be an issue specific to Debian/Ubuntu distributions - https://discourse.ubuntu.com/t/multiple-ubuntu-users-report-issue-with-ffvii-ever-crisis-on-proton/54943.
I also tried Proton 8 and Proton 7 just now - same issue.
No apparent change with Proton 10, but to be expected if the problem is Debian/Ubuntu-specific.
Hey, apologies in advance for the wall of AI text. I'm a novice and have no idea what some of these terms mean. I tried to debug this today with claude code and we tried a few things but never got the loading screen. claude code generated this summary of what we tried, let me know if I can help getting you any other information
Game launches, reaches start screen, connects to Square Enix API successfully, transitions to loading screen, then hangs indefinitely. No crash, no error dialog.
An extensive debug session was conducted tracing Wine internals across multiple Proton versions and system configurations.
WINEDEBUG=+winsock traces show the game successfully:
game-*.app.gl.ffviiec.com, client-masterdata-*.app.gl.ffviiec.com, resources-api-*.app.gl.ffviiec.comAPI calls succeed — Command.ApiNetwork.Api.ApiBase:OnSuccessApi appears in Player.log.
WINEDEBUG=+loaddll confirms every game DLL loads without error, including GameAssembly.dll, UnityPlayer.dll, grpc_csharp_ext.dll, fastaes_universal.dll, etc.
Notable: Cysharp.Net.Http.YetAnotherHttpHandler.Native.dll (a Rust/tokio-based HTTP/2 client) is present in the Plugins directory but never loaded by the game at runtime.
The Octo asset manager initializes with 106,679 asset bundles in its database, but the download directory (octo/d/) remains empty across every launch. The game never schedules asset bundle downloads. Without downloaded assets, the post-loading-screen scene renders as a black screen with no UI content (though click animations still work, confirming the engine is responsive).
The game includes fastaes_universal.dll, a Rust+MinGW compiled AES library used by the Octo SecureFile system. Every launch produces this error in Player.log:
Octo/SecureFile: Secure file is corrupt: S:/common/FF7EC/FF7EC_Data\..\octo\pdb\3001\323173179\octocacheevai
The file is actively written by the game (15MB, modified timestamp updates each run), but the game cannot decrypt it back on subsequent reads. The encryption produces data that fails decryption. This is consistent with the System.Security.Cryptography.CryptographicException: Bad PKCS7 padding. Invalid length 0 reported by other Linux users.
With a fresh Proton prefix (no octocacheevai file exists), the first Octo setup bypasses the encrypted cache and reads the DB directly — this succeeds, and loading screen visuals render correctly. The game then writes a new octocacheevai during that session. On subsequent Octo setup iterations (and subsequent launches), it attempts to read the file back, fails decryption, and falls back to a degraded code path.
This broken encryption likely affects other internal crypto operations beyond just the cache file, which would explain why asset bundle downloads are never scheduled despite successful network connectivity.
The game silently catches and swallows whatever internal exceptions prevent asset downloads from being scheduled.
The game was tested inside a Fedora 41 Distrobox container (glibc 2.40, OpenSSL 3.2.6) sharing the Ubuntu host kernel. Behavior was identical — same SecureFile corruption, same infinite loading screen. This rules out Ubuntu's userspace libraries (glibc, openssl, etc.) as the cause. The issue is in Wine/Proton's precompiled binary or its interaction with the kernel/GPU driver.
| Configuration | Result |
|---|---|
| Proton 10.0-4 | Hangs on loading screen |
| GE-Proton10-34 | Hangs on loading screen |
| Fresh Proton prefix | Loading visuals appear on first launch, then same hang on subsequent launches |
| YAHA DLL removed | No change (DLL was never loaded anyway) |
| Fedora 41 Distrobox (Proton 10.0-4) | Identical behavior to native Ubuntu |
The game's Rust-compiled AES library (fastaes_universal.dll) produces inconsistent encryption/decryption results under Wine. This breaks the Octo asset management secure cache and likely other internal crypto operations, preventing asset bundle downloads from ever being scheduled. The game connects to servers and downloads metadata successfully, but never progresses to downloading actual game content assets — resulting in an infinite loading screen.
never got the loading screen
You mean you didn't get stuck and it loaded normally or you didn't even reach the point of where it gets stuck?
I've yet to see if the same occurs on Ubuntu 26.04 but I have no reason yet to believe anything has changed here.
Sorry, I meant to say I never got past the loading screen. Same issue as the OP, first 3 steps to reproduce (I only have Ubuntu 24.04)
Tried again with opus 4.7 and it figured it out based on my logs (last conversation was with opus 4.6)
The game uses Unity's Ping (ICMP) to verify the server is available before continuing. Ubuntu does not allow unprivileged ICMP sockets via net.ipv4.ping_group_range, which defaults to 1 0 — an empty range that blocks every GID. The ping never succeeds, so the game waits forever.
You can verify if this affects you:
$ cat /proc/sys/net/ipv4/ping_group_range
1 0
Ping: Error performing ICMP transmission. Possibly because of a timeout
~/.local/share/Steam/steamapps/compatdata/2484110/pfx/drive_c/users/steamuser/AppData/LocalLow/SquareEnix/FF7EC/Player.logTest the fix:
sudo sysctl -w net.ipv4.ping_group_range="0 2147483647"
Then relaunch the game. If that lets you past the start screen, make it permanent:
echo 'net.ipv4.ping_group_range = 0 2147483647' | sudo tee /etc/sysctl.d/99-ping-group.conf
Fascinating. I didn't know about that Player.log, but it does indeed appear that Debian/Ubuntu closed down pings between Ubuntu 22.04 and 24.04. I confirm I'm able to download again by allowing pings only for my group ID (1000 in my case).
Not sure if this counts as an implementation fault with the game itself, since it shouldn't become unresponsive like that. But aside from this, the game itself plays fine overall - at least running against vanilla Proton 10.0-4.
proton 10.0-4x2 2026-05ge-proton10-34x1 2026-05PROTON_LOG=1**:x1 2026-05WINEDEBUG=+loaddll`x1 2026-05WINEDEBUG=+winsock`x1 2026-05fastaes_universal.dllx1 2026-05gameassembly.dllx1 2026-05grpc_csharp_ext.dllx1 2026-05native.dllx1 2026-05unityplayer.dllx1 2026-05firebasecppapp-11_9_0.dllx1 2024-10icu.dllx1 2024-10
Compatibility Report
System Information
I confirm:
steam-2484110-ubuntu2204.log (runs normally)
steam-2484110-ubuntu2404.log (gets stuck on connection - eventually forced-closed via Alt-F4)
There are a lot of entries for
fixme:system:NtUserQueryDisplayConfigin the latter, I don't know if that's significant.Symptoms
This may not necessarily be a Proton-specific issue, since it appears to be a connection issue within the game itself (it's a PC port of a mobile phone game) and the connection works fine on Ubuntu 22.04 but not on 24.04 (my observation is a confirmation of the report around July 2024 on ProtonDB - there are a few other reports that also refer to the black loading screen problem).
Reproduction
Unlike Mobius (service since terminated), this game doesn't cope well going back and forth between phone and PC frequently, so I seldom use the Steam port. But if I do use it, I'd prefer to have it work with Proton as I used to back on the older Ubuntu.