Compatibility Report

• Name of the game with compatibility issues: Battle.net (Blizzard's installer/launcher) — not a Steam game, installed via Lutris + umu-launcher outside Steam
• Steam AppID of the game: N/A — non-Steam app run via Lutris/umu-launcher, not distributed through Steam

System Information

• GPU: Apple M1 Max (integrated, G13C)
• Video driver version: Mesa 26.1.4 (Honeykrisp Vulkan driver / OpenGL 4.6 Compatibility Profile)
• Kernel version: 7.0.13-400.asahi.fc44.aarch64+16k (16 KiB page size — getconf PAGESIZE = 16384)
• Link to full system information report as Gist: Not available — Steam's own client doesn't currently function in this environment due to an unrelated, already-tracked bug (AsahiLinux/muvm#131: Steam hangs on "Waiting for network..." inside muvm's microVM despite having real connectivity — see details below). Full manually-gathered system/diagnostic info is included in this report instead.
• Proton version: GE-Proton11-3-aarch64 and GE-Proton11-1-aarch64 (GloriousEggroll builds) — official Valve ARM64 Proton (Proton 11.0 Beta) could not be tested; see "Note on upstream Proton Experimental (ARM64) testing" below for why.

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

Battle.net-Setup.exe renders its "Select a Language" screen correctly but becomes permanently unresponsive to all input (mouse clicks, Tab, arrow keys, Space/Enter) immediately. Two threads pin at ~99% CPU each indefinitely (~197-198% total, sustained for 80+ seconds without change). A WINEDEBUG=+seh trace shows the main thread stuck in an infinite loop:

00d8:trace:seh:dispatch_exception code=6ba (RPC_S_SERVER_UNAVAILABLE) ...
00d8:trace:seh:call_seh_handlers ...
00d8:trace:seh:RtlUnwindEx code=6ba flags=2 ...
00d8:trace:seh:RtlRestoreContext returning to ...
00d8:err:ole:start_rpcss Failed to open service manager

It raises RPC_S_SERVER_UNAVAILABLE, unwinds, and immediately retries the same failing RPC/SCM operation — forever, rather than backing off or surfacing an error dialog. /proc/<pid>/task/<tid>/syscall for both hot threads shows running on every sample, i.e. they're spinning entirely in userspace, never blocked in a syscall.

Full details on everything ruled out, and a second independent test against a different aarch64 Wine stack, are below.

Reproduction

1. On aarch64 Linux (Fedora Asahi Remix 44, 16K-page kernel), install Lutris and add Battle.net via its standard installer script (downloads Battle.net-Setup.exe, runs it through umu-run with PROTONPATH set to a GE-Proton*-aarch64 build).
2. Start the install. The installer window appears and correctly renders the "Select a Language" screen.
3. Attempt to interact with it (mouse click, Tab, arrow keys, Space/Enter) — nothing responds. The window never becomes unusable-looking (no beachball/greyed-out state), it just silently ignores all input forever.

Full details

What I ruled out

All of the following were tested directly and made no difference — the hang is byte-for-byte identical in every case:

• Esync/Fsync: disabled via WINEESYNC=0, WINEFSYNC=0, PROTON_NO_ESYNC=1, PROTON_NO_FSYNC=1 (confirmed applied via /proc/<pid>/environ).
• Windows version compatibility: forced HKEY_CURRENT_USER\Software\Wine\Version = win7 via wine reg add in the prefix before launching.
• Missing RPCSS/SCM service: confirmed services.exe and rpcss.exe were both actually running (via Wine's own auto-start, ole::start_rpcss-triggered) at the moment of the hang — the SCM was up, and the installer still failed to reach it / kept retrying.
• Wayland vs. X11: identical behavior under a KDE Plasma 6 Wayland session and a full Plasma (X11) session.
• Wine prefix state: reproduced identically on a prefix that had been used for prior (failed) install attempts, and separately on a brand-new prefix created from scratch with zero manual intervention.
• GE-Proton version: reproduced identically on GE-Proton11-3-aarch64 (built 2026-07-25) and GE-Proton11-1-aarch64 (built 2026-06-24), a month apart — this is not a one-release regression.

Also fails on an independent aarch64 translation stack

To rule out this being specific to Proton-GE's particular WoW64/FEX integration, I also tested the same Battle.net-Setup.exe against a completely independent aarch64 Windows-compatibility stack: Fedora's wine-11.13-ec1 (ARM64EC, wine-staging + bylaws' ARM64EC patches) with fex-emu-wine-2607 from the lacamar/wine-arm64ec Copr repo, in a brand-new prefix, run directly (not through Lutris/Proton at all).

Result: also fails, but via a different, seemingly-worse mechanism. A clean, single-instance WINEDEBUG=+seh trace shows two genuine EXCEPTION_ACCESS_VIOLATION faults (not just a retry loop), after which the process pins at ~180% CPU indefinitely while Wine's own crash-symbolication code (dbghelp_dwarf) spams Unsupported form for const value / Unhandled Tag type 0xa warnings against ntdll's debug info, apparently never completing a backtrace or presenting a usable crash dialog. services.exe/rpcss.exe auto-start correctly on this build (unlike Proton-GE), so this is not the same RPC/SCM issue — it's a distinct, real crash.

So two independently-built aarch64 x86-Windows-compatibility stacks (Proton-GE's bundled WoW64+FEX, and Fedora's ARM64EC wine-staging+FEX-Emu) both fail to get this specific installer past its first screen, via two different underlying bugs. This looks like a genuine gap in current aarch64/FEX Windows-app emulation more broadly, not an issue isolated to one project's packaging choices.

Note on upstream Proton Experimental (ARM64) testing

I attempted to also test this against Valve's own experimental ARM64 Proton build (Proton 11.0 Beta, built for the Steam Frame) to properly rule this in/out. This required installing the Steam client itself (via the @asahi Copr steam package, which runs Steam inside a muvm microVM). Steam itself never got far enough to install/select a compatibility tool: it hangs indefinitely on "Waiting for network..." even though its own internal connectivity test succeeds (connection_log.txt shows Connectivity test: result=Connected) — client_networkmanager.txt shows Init: failed to create a NetworkManager client on every launch, and Steam's UI appears to gate its "network ready" state on a NetworkManager D-Bus signal that never arrives inside the isolated microVM, regardless of actual connectivity. This matches the open, already-tracked AsahiLinux/muvm#131 ("Steam works on other ARM platforms with Box64 but not on asahi with muvm"). I could not find a workaround that doesn't involve disabling NetworkManager on the host entirely (not viable). So I was not able to complete a clean upstream-Proton-Experimental-ARM64 comparison — Steam itself doesn't functionally work in this environment yet, independent of anything Proton/Wine-related.

Given that, and given the closest matching prior report I could find (ValveSoftware/Proton#9813, closed as duplicate of #7302) describes the same NtGetContextThread-class hang on regular non-ARM Proton, my best guess is that this is a Wine/Proton-level bug that predates and is independent of the aarch64 port, just more consistently exposed there. Filing here rather than GE-Proton's tracker for that reason, referencing #9813/#7302 as related.

Additional context: no working x86_64 fallback exists on this platform

On this system, plain x86_64 community Wine/Proton builds (proton-cachyos, wine-ge, wine-staging, UMU-Proton-10.0-4) cannot run at all, regardless of translation backend (system qemu-x86_64 binfmt or a manually-installed FEX via FEXInterpreter) — both immediately abort with:

<jemalloc>: Unsupported system page size
terminate called without an active exception

This is because these builds' bundled jemalloc assumes 4K pages and aborts outright on Asahi's 16K-page kernel. This makes the aarch64-native GE-Proton*-aarch64 builds (which bundle their own FEX-based WoW64 translation and don't hit this) the only viable runner family on Fedora Asahi Remix today — which is why the RPC hang above is a hard blocker for installing Battle.net/Hearthstone on this platform, with no working fallback runner.

Also noticed (minor, separate bug)

umu-launcher 1.4.4 throws an uncaught KeyError: 'steamrt4-arm64' in umu_runtime.py:_update_umu_platform on every launch, while checking for runtime updates:

File ".../umu_runtime.py", line 479, in _update_umu_platform
    local_ver = versions[name]
KeyError: 'steamrt4-arm64'

It appears the remote version manifest doesn't include an entry for the steamrt4-arm64 runtime name. This is non-fatal — it falls back to the existing local install and the app still launches — but is worth fixing separately.

Request

Has anyone else hit this specific RPC_S_SERVER_UNAVAILABLE / start_rpcss infinite-retry loop? Happy to gather more diagnostics (full debug logs, +relay traces, etc.) if useful.