World of Warcraft fails to launch

[chrisRidgers]

Platform: Asahi Linux
Version: FC34
Wine Version: wine-10.15 (system default version, exists inside muvm stack)
Proton Version: Proton Experimental

Battle.net runs via Steam/ Proton in Asahi's muvm/ FEX stack. However, trying to launch World of Warcraft nothing happens. Nothing being a process that runs but never get's as far as creating a window - doesn't seem to crash out though. Through steams cli output I can see the process eventually get's shut down if you exit Battle.net and ultimately Steam.

Managed to get some more output from by running proton manually from muvm and FEXBash. Looks like the process is just running the same thing repeatedly until it's killed.

Spoke to the Aasahi community and they suggested opening a ticket here.

So using the following command:

chris@snow:~$ PROTON_LOG=1 STEAM_COMPAT_DATA_PATH=~/.local/share/Steam/steamapps/compatdata/4263109722 STEAM_COMPAT_CLIENT_INSTALL_PATH=~/.local/share/Steam ~/.local/share/Steam/steamapps/common/Proton\ -\ Experimental/proton run ~/.local/share/Steam/steamapps/compatdata/4263109722/pfx/drive_c/Program\ Files\ \(x86\)/World\ of\ Warcraft/_retail_/Wow.exe 

Get's an output of this:

E 310|310 0.000 Failed to remap /proc/pid/cmdline data (prctl failed: result -1, errno 1)
E 310|310 0.030 Failed to remap /proc/pid/cmdline data (prctl failed: result -1, errno 1)
I 310|310 0.156 CLONE_CLEAR_SIGHAND passed to clone3. Returning EINVAL.
I 310|310 0.156 clone: Unsupported flags w/o CLONE_THREAD (Shared Resources), 4100
E 315|315 0.165 Failed to remap /proc/pid/cmdline data (prctl failed: result -1, errno 1)
fsync: warning: a previous shm file /wine-5f71a9-fsync was not properly removed
fsync: up and running.
E 318|318 0.310 Failed to remap /proc/pid/cmdline data (prctl failed: result -1, errno 1)
E 320|320 0.683 Failed to remap /proc/pid/cmdline data (prctl failed: result -1, errno 1)
E 324|324 1.066 Failed to remap /proc/pid/cmdline data (prctl failed: result -1, errno 1)
E 334|334 1.463 Failed to remap /proc/pid/cmdline data (prctl failed: result -1, errno 1)
E 339|339 1.822 Failed to remap /proc/pid/cmdline data (prctl failed: result -1, errno 1)
E 347|347 2.550 Failed to remap /proc/pid/cmdline data (prctl failed: result -1, errno 1)
E 367|367 4.390 Failed to remap /proc/pid/cmdline data (prctl failed: result -1, errno 1)
E 374|374 5.496 Failed to remap /proc/pid/cmdline data (prctl failed: result -1, errno 1)
E 384|384 5.871 Failed to remap /proc/pid/cmdline data (prctl failed: result -1, errno 1)
E 386|386 6.564 Failed to remap /proc/pid/cmdline data (prctl failed: result -1, errno 1)
E 392|392 7.105 Failed to remap /proc/pid/cmdline data (prctl failed: result -1, errno 1)
info:  Game: xalia.exe
info:  DXVK: v2.7.1-505-g6f3a758f7982fc5
info:  Build: x86_64 gcc 14.2.0
info:  Vulkan: Found vkGetInstanceProcAddr in winevulkan.dll @ 0x6ffffc2bfbf0
info:  Extension providers:
info:    Platform WSI
info:    OpenVR
info:  OpenVR: could not open registry key, status 2
warn:  OpenVR: Failed to initialize OpenVR
info:    OpenXR
warn:  OpenXR: Unable to get required Vulkan instance extensions size
info:  Enabled instance extensions:
info:    VK_EXT_surface_maintenance1
info:    VK_KHR_get_surface_capabilities2
info:    VK_KHR_surface
info:    VK_KHR_win32_surface
info:  Found device: Apple M1 Pro (G13S C0) (Honeykrisp 25.2.7)
info:  Found device: llvmpipe (LLVM 21.1.5, 256 bits) (llvmpipe 25.2.7)
info:    Skipping: Software driver
warn:  OpenXR: Unable to get required Vulkan Device extensions size
warn:  DXGI: Found monitors not associated with any adapter, using fallback
info:  Adapter LUID 0: 0:3f8
warn:  DXGI: Found monitors not associated with any adapter, using fallback
E 392|392 8.977 NoExec instruction in entry block: 1431EB814
E 392|398 8.984 NoExec instruction in entry block: 1431C0F60
E 392|392 8.985 PartialDecode instruction in entry block: 1431EBFFB
E 392|398 8.985 NoExec instruction in entry block: 140186A30
E 392|392 8.985 PartialDecode instruction in entry block: 1431EBFFB
E 392|398 8.985 NoExec instruction in entry block: 140189FB0
E 392|398 8.985 NoExec instruction in entry block: 1400DECB0
E 392|398 8.985 NoExec instruction in entry block: 14016D920
E 392|398 8.986 NoExec instruction in entry block: 140180ED0
E 392|392 10.069 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 10.087 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 10.510 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 10.825 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 10.931 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 11.035 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 11.138 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 11.381 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 12.402 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 12.631 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 12.732 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 12.833 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 12.934 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 13.035 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 13.136 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 13.238 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 13.345 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 13.450 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 13.554 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 13.657 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 13.761 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 13.864 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 13.970 PartialDecode instruction in entry block: 1431EBFFB
E 392|392 14.074 PartialDecode instruction in entry block: 1431EBFFB

Which continues until ultimately being killed. Unsure what to test next.

[Sonicadvance1]

That's very interesting. Is this able to be tested without creating a paid account?

[chrisRidgers]

Yes. I've got a battle.net account that I'm logged in with but no paid subscription. If the Wow client works as I remember, launching from battle.net while logged in will launch the game logged in.

If you launch the client without being logged in there's a password auth flow thats built into the game client once its running.

[Sonicadvance1]

Somewhat annoyingly, this is the first game I've encountered that has a native Arm64 Windows build and it downloaded the arm64 version of the client instead. So I'll need to figure out how to get the x86 client to download instead.

[chrisRidgers]

The client downloaded what now, how do I check that?

[chrisRidgers]

$ file Wow.exe 
Wow.exe: PE32+ executable for MS Windows 10.00 (GUI), x86-64, 7 sections

thats the file as downloaded from battle.net... how did you get an ARM file?

[Sonicadvance1]

If you use Arm64 Wine/Proton to run the Battle.Net launcher, it'll detect Arm64 and download the Arm64 WoW client.

$ file Wow-ARM64.exe
Wow-ARM64.exe: PE32+ executable for MS Windows 10.00 (GUI), ARM64, 6 sections

So I just need to make sure to reinstall Battle.Net using x86 wine so it downloads the x86 client instead of the arm64 one. So I can test this bug.

[chrisRidgers]

Bah i can't even get the Battle net launcher to run successfully outside the muvm/fex stack atm.

Would like to test that Wow-ARM64.exe as well.

[Sonicadvance1]

I can confirm at least that this game is doing some gnarly obfuscation and remapping tricks, which is why it is breaking heavily under FEX. Looks like it's doing something like remapping its code as NOEXEC, when it hits the code it deobfuscates it and remaps as executable? Potentially with a copy of the code to a new mapping as well? And then looks like obfuscating again when its done. All of this might also be done with inline code modification as well.

If anything I see why they released an arm64 client, this is going to be a nightmare to untangle and figure out why its breaking emulation.

[chrisRidgers]

Well that's cool to know at least, knowledge is power.

Wonder why its been done like that?

Does the arm64 client actually work? I've not had much luck with running the installer outside of FEX and some of the asahi guys were telling me about some technical wizadry where some arm64-ec applications link out to x86 libraries so it will still need to be run under FEX regardless.

[Sonicadvance1]

Does the arm64 client actually work? I've not had much luck with running the installer outside of FEX and some of the asahi guys were telling me about some technical wizadry where some arm64-ec applications link out to x86 libraries so it will still need to be run under FEX regardless.

I didn't even try the arm64 client as it wasn't interesting to me.

[chrisRidgers]

saw this recently #5133

turtle wow stuff bla bla bla. Is their client completely removed from the blizzard client? Seems like they've managed to via FEX?

[chrisRidgers]

Still interested in this if there's any prodding i can do from a user perspective.

[chrisRidgers]

Does #5453 actually have anything to do with this issue?

I got hopeful but looking at the commentary I'm guessing not?

[FrontMage]

We have already tested a very similar WoW setup on Android/Winlator with FEX, and our end state split into two distinct paths:

1. x86 WoW under FEX/WoW64

   • We were able to force Battle.net to download the x86 WoW client instead of the ARM64 one.
   • However, the x86 client never reached a stable rendering stage.
   • In our case, the failure happened earlier in the execution chain: exception / loader / executable mapping semantics under FEX, rather than in DXVK or rendering.
   • This is the path that feels most similar to what is being reported here, especially given the repeated NoExec instruction in entry block / PartialDecode instruction in entry block messages and the later observation that WoW appears to remap / deobfuscate executable code dynamically.

2. ARM64 WoW under Wine ARM64

   • This path got much further than the x86 client.
   • We could reach successful D3D11 device creation and DXVK initialization.
   • But it still never produced a visible first frame: the game stayed alive with a black screen and never progressed to actual rendering.
   • So for us, ARM64 WoW was not blocked by the same early execution-layer failure; it failed later in the graphics/present path.

We also opened a related FEX issue for the x86-side execution/memory behavior here:

• #5328

From our side, the important distinction was:

• ARM64 WoW: gets through initialization, but black-screens later
• x86 WoW under FEX: fails much earlier, before reaching a stable graphics/rendering state

So based on what is in this issue, this looks much closer to the x86/FEX execution-layer problem than to the ARM64 black-screen path.

@Sonicadvance1 @chrisRidgers