Windows x64: Arena Campaign execute-at-0xE crash

[knightoffmon]

openQ4 version

0.10

Package artifact name

openq4-0.10.0-windows-x64

What kind of report is this?

Defect — something is broken

Device and SoC

Custom Build PC (AMD Rayzen 7 800 + Nvidia RTX 5050)

Windows version

Windows 11 25H2

Which binary did you run?

X64 build (openQ4-client_x64.exe)

Renderer

OpenGL (default)

OpenGL provider

No response

What happened

This would be the perfect way to enjoy Quake 4 without relying on the outdated Steam Release, how ever, I have two fatal problems with it.

• Frame rate unestable even on LowSettings, and that's wild considering I'm using an Nvidia RTX 5050. Which I assume is a lot better than my previous GPU (Radeon RX 560)

• As much I like the idea of having an alternative Quake3 like campaign as an alternative single player mode, the match can't even start because of an error. The console only says this:
  WARNING: could not authorize match disclosure for client 0 (reason 3)
  Note this happens on Multiplayer with bots too.

Does the same thing happen with the x64 build under emulation?

No response

Terminal output and openq4.log

openQ4
version=0.10.0
version_tag=0.10.0
platform=windows
arch=x64
openq4_commit=c3be062f4c2d73a8a64652c468fd1bdefa9dd9e1
openq4_dirty=false
openq4_game_commit=3112fbdea42ab3ba77e70c82ebd10340dbbeb7f3
openq4_game_dirty=false

Reported machine quality tier

No response

Evidence record

• This is a physical-hardware run and I am willing to have it referenced in a Windows ARM64 signoff evidence record.

[knightoffmon]

New Update, it crashed while loading an arena circuit:

openQ4 crash report
Timestamp: 2026-08-12 18:19:02.103
ProcessId: 17128
ThreadId: 8172
CommandLine: "D:\Games\Quake4\openQ4-client_x64.exe" 

ExceptionCode: 0xC0000005 (EXCEPTION_ACCESS_VIOLATION)
ExceptionAddress: 0x000000000000000E
DumpCreated: yes
DumpPath: D:\Games\Quake4\crashes\openq4_crash_20260812_181901_17128_8172.dmp
DumpError: 0x00000000
AccessViolationType: execute
AccessViolationAddress: 0x000000000000000E

RAX=0x000002C04E63F0B0 RBX=0x00007FF7B7D53810 RCX=0x000002BF98105A80 RDX=0x000000D8A89F2490
RSI=0x00007FF7B7D53814 RDI=0x000002BF8DA9F3B0 RBP=0x0000000000000001 RSP=0x000000D8A89F2458
R8 =0x000002BF8DA9F3E0 R9 =0x000000D8A89F24C0 R10=0x000000000000006C R11=0x000000D8A89F2458
R12=0x000002BF8D3167FC R13=0x00007FF7B7CA89D0 R14=0x00007FF7B7CA89D0 R15=0x0000000000000000
RIP=0x000000000000000E EFlags=0x00010202

[themuffinator]

brilliant feedback, thank you. arm64 is still experimental, hopefully your feedback will help to push it to stable

[themuffinator]

The supplied evidence is x64, not Windows ARM64:

• artifact: openq4-0.10.0-windows-x64
• version: platform=windows arch=x64
• crash command: openQ4-client_x64.exe

I have corrected the title. The frame-rate portion is the same high-refresh defect now tracked canonically in #99; I am keeping this issue for the distinct Arena Campaign failure/crash.

The warning is also root-caused. Numeric reason 3 is a role conflict: Arena Duel is intentionally adapted to effective DM, so an active human has MP_MATCH_SIDE_NONE; the disclosure validator nevertheless required every active player to have a team side. That deterministically rejects an ordinary active FFA/Arena player. The fix now accepts that recipient as a public-state-only player—without inventing a team or exposing opponent vitals—and adds active-FFA, neutral-spectator, and team-player coverage. It has passed the focused/competitive contract suites and an x64 MP build; I will link the pushed commit here.

The EXCEPTION_ACCESS_VIOLATION execute-at-0xE crash is not safely attributable from registers alone. Please attach the generated .dmp, matching v0.10 symbols/PDB archive, complete openq4.log, exact Arena card/map, and steps. The disclosure warning can block the match-control view, but Arena disables ready-up and has a bounded opponent-intro timeout, so I will not claim it caused the indirect-call crash without a symbolized stack.

[themuffinator]

I have now exercised the corrected path in an integrated staged build, without user-input automation: a windowed command-driven Arena Campaign match on mp/q4dm1 loaded game-mp_x64, connected the local player, added the authored Bagby bot, completed the opponent introduction, reached live first-person gameplay, and wrote an engine screenshot capture. The previous could not authorize match disclosure ... reason 3 warning did not occur, and there was no fatal/crash diagnostic.

That validates the disclosure fix for the concrete warning, but I am deliberately keeping this issue open. The reporter's execute-at-0xE access violation is a distinct failure and still cannot be attributed without the requested .dmp, matching symbols/PDB archive, full log, Arena card/map, and exact steps. The current run does not prove that independent crash is gone.

The disclosure change is companion commit d56d6deb and will be linked here again with the draft PR.

[themuffinator]

The Arena disclosure fix is now published in draft openQ4-game PR #1, commit d56d6deb.

The active FFA/Arena human is accepted only as a public-state recipient; no synthetic team is assigned and no opponent-private state is exposed. All 36 competitive contracts and the Arena presentation contract pass, alongside the successful windowed live Arena run described above.

This issue remains open for the separate execute-at-0xE crash until the reporter supplies the dump/symbols/log/steps. The draft PR does not claim that unsymbolized crash is fixed.

[knightoffmon]

First time doing an issue on github so I didn't realised it was marked as ARM instead of x64. Guthub presented me a bunch of automated options didn't notice the inconsistency due to being focus on just the issue

[themuffinator]

No problem at all—thanks for clarifying. The report is now correctly tracked as Windows x64, and the Arena disclosure warning has a focused fix in draft openQ4-game PR #1.

I am keeping this issue open for the separate execute-at-0xE crash. When convenient, the generated .dmp, matching v0.10 PDB/symbol archive, complete openq4.log, exact Arena card/map, and reproduction steps will let that crash be symbolized instead of guessed from registers alone.

[themuffinator]

Correction to the earlier Arena validation description: the direct run was controllable combat, but it had not reached live GAMEON scoring. Its screenshot shows the infinite clock and 0–0 score, and the saved log contains competitive rules rejected field 4 (17) followed by introductions complete with no successful countdown handoff. That is the deterministic lifecycle defect now tracked and fixed separately in #110 / openQ4 PR #112.

The disclosure/view-authorization change remains valid but does not fix that transition. It has been split from the unrelated high-refresh work onto current GameLib main as focused openQ4-game PR #3. Its independent review found no defect, and both hosted push/PR matrices are now green (14/14 checks across Windows x64, Linux x64/ARM64 GCC+Clang, and macOS Intel/ARM64).

This issue is now deliberately titled and kept open for the distinct execute-at-0xE crash. Neither the disclosure change nor the #110 lifecycle fix is evidence that the unsymbolized indirect-call crash is resolved.