Hello @daro-almeida, we're using one issue report per unofficially supported game title, so I've gone ahead and transferred this issue report to https://github.com/ValveSoftware/Proton/issues/458#issuecomment-5240785974.
ge-proton11-3x1 2026-08PROTON_LOG=1x1 2026-08WINEDEBUG=+winsockx1 2026-080xc00000a3x1 2026-08
Compatibility Report
System Information
I confirm:
Symptoms
Black screen for 60-120+ seconds and no audio when loading into a level (also happens on level exit). Enough to time out friends trying to join co-op while stuck on the loading screen.
Cause: Magicka tries to contact two backend hosts that don't exist anymore -
opstm.paradoxplaza.comand a GameSparks endpoint (live-g347409i9fs2.ws.gamesparks.net), AWS GameSparks was shut down. That part's expected and not really Proton's fault.What is a bug: the actual delay comes from Wine's winsock layer,. Non-blocking
connect()always returns NTSTATUS0xC00000A3(STATUS_DEVICE_NOT_READY, not even a networking code) no matter what it's connecting to - dead external host, localhost, a LAN device with nothing on the port, even a destination with a hard firewall reject in front of it. All identical. Meanwhilecurl/pinginside the same Steam Runtime sandbox connect fine to all of the above, so it's not SELinux/firewall/sandbox networking. Also reproduces on a fresh prefix, so not prefix state either.Stronger evidence it's a Wine bug and not a real failure: on one socket, right after
connect failed, status 0xc00000a3is logged,getpeername()/getsockname()on that same socket succeed. That shouldn't be possible on an actually-failed connect. The real outcome only shows up much later asWSAECONNRESET/broken pipe, way after the bogus failure was already reported.Reproduction
WINEDEBUG=+winsock PROTON_LOG=1 %command%$HOME/steam-42910.logforconnect failed, status 0xc00000a3- same result regardless of destinationgetpeername/getsocknameright after - they'll succeed despite the logged failuremagicka-proton-log-excerpt.txt