Extensive Bug Report: Clair Obscur: Expedition 33 — Instant Platform-Level Hard Reboot on AMD RX 9070 XT (Navi 48/gfx1201) via Proton on Linux

(Note: I have sent the exact bug report listed below to the developers through official sources - my intention is to address this with all sources that may be able to provide fixes.)

System Specifications

1. Presenting Problem

Clair Obscur: Expedition 33 (AppID: 1903340), launched via Steam with Proton on EndeavourOS, consistently causes the entire system to perform an instant, silent hard reboot. The reboot occurs with no kernel panic, no logged fault, and no visible warning. It happens both within seconds of launching the game and during extended gameplay sessions, with no apparent pattern tied to specific in-game actions or scenes.

No other titles reproduce this behaviour. FurMark sustained 100% GPU load indefinitely without incident. Elden Ring with ray tracing enabled runs without issue. The crash is specific to this title.

Two distinct crash phases were identified during investigation:

Phase 1 — Pre-menu crash (RESOLVED): The game aborted before displaying the main menu. Root cause: Wine called mfplat.dll.MFGetConfigurationDWORD, an unimplemented function in Wine's internal (builtin) Media Foundation stub. Captured via PROTON_LOG=1. Resolved by installing native Windows Media Foundation DLLs into the Proton prefix, replacing Wine's stub with the real implementation.

Phase 2 — Gameplay and menu crash (UNRESOLVED): Following the Phase 1 fix, the game loads and plays, but causes an instant platform-level hard reboot at unpredictable intervals ranging from seconds to several minutes. This crash bypasses every kernel-level fault capture mechanism that was tested. It is the subject of this bug report.

2. Diagnostic Tools and Findings

Kernel and System Logs

• journalctl -b -1 -p err
  Initial log capture after crash. Returned only routine noise: RDSEED32 CPUID warning (cosmetic silicon bug on Zen 5, unrelated), SATA power management warnings, routine amdgpu sysfs attribute errors, KDE/Plasma dbus warnings. No crash-related entries. Established that the log cutoff was clean — no panic, no driver timeout, no GPU reset message.

• journalctl -b -1 -p warning..emerg --no-pager | tail -150
  Broadened filter to capture warnings. Found one meaningful entry: x86/split lock detection: #DB: CHTTPClientThre/15961 took a bus_lock trap at address: 0xf39bdc54. This indicated a networking thread (likely Epic Online Services) performing unaligned atomic memory operations, causing a whole-bus lock. Investigated as a potential cause but ruled out: removing network access via Steam Offline Mode produced no change in crash frequency.

• sudo journalctl -b -1 | grep -iE "mce|hardware error|panic|fatal"
  Returned only false positives: DRM panic handler registration messages (a feature name, not an event), xkbcomp "not fatal" advisory warnings, and Steam's Chromium launch flags containing the string "Fatal" in a flag name. Zero real MCE events, hardware errors, or panics confirmed.

• journalctl -b -1 | grep -iE "pcie|aer|corrected error"
  Returned standard PCIe topology enumeration and ACPI _OSC handoff messages from boot. No AER events, no corrected or uncorrected errors. Confirmed PCIe link health; ruled out physical slot/connection issues.

• PROTON_LOG=1 (Steam launch option)
  Generated a detailed Wine runtime log at ~/steam-1903340.log. Two key findings:

  • wine: Call from X to unimplemented function mfplat.dll.MFGetConfigurationDWORD, aborting — the definitive cause of Phase 1 crash. The word "aborting" confirms Wine hard-terminated the process rather than recovering. The preceding line confirmed mfplat.dll was loading as "builtin" rather than "native."
  • err:service:device_notify_proc failed to get event, error 1726 — confirmed as generic noise appearing at process shutdown; not a cause.
  • fixme:mf and fixme:mfplat entries — indicated additional incomplete Media Foundation component stubs (including colorcnv.dll), which failed to fully register even after partial MF installation.

Hardware Error Reporting

• sudo rasdaemon -r -f
  Installed rasdaemon and read all CPER (Common Platform Error Record) data written by platform firmware. Result: zero hardware error events of any kind recorded across all previous crashes. This is a critical finding: it confirms that platform firmware is not going through any standard ACPI/GHES hardware error reporting pathway before issuing the system reset. The reset is not a response to a logged hardware fault in the conventional sense.

• /sys/fs/pstore/ (pstore/ramoops)
  Kernel boot parameters ramoops.mem_size=0x400000 ramoops.console_size=0x200000 were added to reserve a memory region for panic messages that survive reboot. Following crash: pstore directory was empty. This definitively confirms the kernel panic handler never executed. The system is not experiencing a kernel panic — the reset happens before any OS-level fault handler can respond.

• sysctl kernel.panic and sysctl kernel.panic_on_oops
  Both confirmed as 0 (halt on panic, not reboot). Despite this, the system reboots instantly. This is only possible if the reset is issued by something with authority above the kernel — either the BIOS watchdog or a hardware/firmware subsystem operating below the OS.

• dmesg | grep -iE "iommu|amd-vi|dmar|gart error|io page fault"
  IOMMU confirmed active in Translated (strict) mode. PPR (Peripheral Page Request) feature enabled. No io page fault entries present — because those would only appear at the moment of crash, which the system never survives long enough to log. Tested iommu=pt (passthrough mode) and amd_iommu=soft (software emulation) as kernel parameters; neither changed crash frequency, ruling out IOMMU fault escalation as the specific trigger mechanism.

• dmesg | grep -i netconsole
  Attempted to stream kernel messages in real-time to a second device over UDP via netconsole. Failed: both MAC addresses resolved as ff:ff:ff:ff:ff:ff (broadcast, ARP resolution failure), and the interface was wireless (wlp9s0). Netconsole is not supported over WiFi. No second wired connection was available, so real-time kernel message capture was not achievable.

Vulkan and Driver Information

• vulkaninfo --summary
  Confirmed active Vulkan driver. Used to verify that AMDVLK was genuinely in use (showing DRIVER_ID_AMD_OPEN_SOURCE) during dedicated AMDVLK testing, distinguishing it from RADV (which shows DRIVER_ID_MESA_RADV). Both drivers were confirmed individually and both produced identical crash behaviour.

• lspci | grep -i vga
  Identified the dedicated GPU as AMD Radeon RX 9070 XT (Navi 48, rev c0) and the integrated GPU as AMD Granite Ridge Radeon Graphics. This was a late-stage finding that reframed the entire investigation: the RX 9070 XT is an RDNA 4 GPU with VCN 5.0, released in early 2025, with known instability in Linux driver support specifically around hardware video decode.

Stress Testing

• FurMark (GPU stress test)
  Ran at 100% sustained GPU load. System remained completely stable throughout. Thermal management, power delivery, and general GPU functionality all confirmed healthy. This ruled out hardware defects, cooling failures, and marginal PSU capacity as causes.

Summary of Diagnostic Hypothesis

The combination of: empty pstore (no kernel panic), zero CPER records (no firmware hardware error reporting), kernel.panic=0 irrelevance, and amdgpu.vm_fault_stop=2 having no effect collectively indicates that the system reset is being issued at the Platform Security Processor (PSP) level — a separate ARM core embedded in AMD CPUs/GPUs that operates independently of the OS and can issue hard platform resets in response to internal faults it detects. This pathway is completely invisible to the Linux kernel, which is why no diagnostic tool is able to capture anything before the reset completes.

The most likely trigger is a malformed GPU command or invalid memory operation generated by the game's UE5 rendering pipeline on the Navi 48 (gfx1201) architecture, which is sufficiently new that certain command patterns may expose firmware-level bugs not yet addressed in released AMDGPU firmware or driver code.

3. Software and OS-Level Solutions Attempted

All of the following were tested without success. The crash and reboot continued at the same frequency in all cases.

• Full system update (sudo pacman -Syu) — Confirmed system fully current before diagnosis began. pacman.log review showed no kernel, Mesa, or amdgpu firmware updates near the onset of crashes; only sof-firmware and archlinux-keyring updates were present, both confirmed irrelevant.

• Multiple Proton versions — Tested Proton 9.0-4, Proton Experimental, GE-Proton9-27, and several other builds. No variation in crash frequency or behaviour between versions. Ruled out Proton version as a variable.

• Steam Offline Mode — Launched game with no network access to rule out Epic Online Services (EOS) networking thread involvement (following the bus_lock trap finding). No change. Ruled out EOS as cause.

• Memory map limit increase (sudo sysctl -w vm.max_map_count=1048576) — Standard Proton/Vulkan workaround. No change.

• Steam Overlay disabled, then re-enabled — Disabling initially had no effect; re-enabling was subsequently required to prevent an additional crash at the logo-to-menu transition, suggesting the Overlay provides runtime components the game depends on at initialisation.

• SteamDeck=0 launch option — Documented community workaround for this title. No change.

• ClairObscurFix ASI plugin — Community-developed compatibility plugin for this title. No change to crash behaviour.

• -dx11 launch option — Forces DX11 path through DXVK rather than DX12 through VKD3D-Proton. Tested both before and after Phase 1 fix was applied. No change. Confirmed that both translation layers (DXVK and VKD3D-Proton) crash identically.

• RADV_DEBUG=nofastclears — Disables an RADV render optimisation. No change.

• VKD3D_CONFIG=no_upload_hvv — Disables a VKD3D-Proton GPU memory management feature known to cause crashes on some AMD systems. No change.

• RADV_DEBUG=zerovram — Forces RADV to zero VRAM before each allocation, a documented fix for UE5 games on Linux. No change.

• RADV_DEBUG=nocompute — Disables the Vulkan async compute queue. No change.

• RADV_DEBUG=llvm — Switches RADV's shader compiler from ACO to LLVM, producing different compiled GPU binaries. No change.

• VKD3D_CONFIG=no_pipeline_cache — Forces VKD3D-Proton to ignore all cached pipeline state objects and recompile fresh each launch. No change.

• AMD_VULKAN_ICD=AMDVLK — Replaced RADV entirely with AMD's official closed-source Vulkan driver (confirmed working via vulkaninfo --summary). Crashed identically to RADV. This is a critical negative result: two completely independent Vulkan driver implementations produced identical crash behaviour, ruling out either driver as the specific cause and placing the fault below the Vulkan layer.

• LIBVA_DRIVER_NAME=fakedriver — Attempted to force software VAAPI decode by providing a nonexistent driver name. No change (this was later understood to be irrelevant as the game's video decode goes through DXVA2/D3D rather than VAAPI).

• WINEDLLOVERRIDES="mfplat=n,b" — Required configuration to ensure Wine uses native mfplat.dll rather than falling back to its internal stub. Necessary companion to the Phase 1 fix; does not affect Phase 2 crash.

• protontricks 1903340 mf — Installed Windows Media Foundation DLLs into the Proton prefix. Partially resolved Phase 1 by installing mf.dll, but did not install native mfplat.dll correctly (mfplat.dll still loaded as "builtin" per Proton log).

• mf-install-proton script (colin969/mf-install-proton) — More complete MF installation than protontricks verb. Installed native mfplat.dll successfully. Combined with copying mfplat.dll directly to the game's Win64 executable directory to bypass Proton prefix symlink structure, this fully resolved Phase 1.

• protontricks 1903340 vcrun2022 — Installed Visual C++ 2022 runtime to complete the game's prerequisite installation (which does not run automatically under Proton). Required for stable Phase 2 testing.

• colorcnv.dll registration — Attempted manual registration via regsvr32; failed. colorcnv.dll handles colour space conversion in the Media Foundation video pipeline and remains unregistered. Partial MF pipeline issue persists.

• Shader cache deletion (~/.steam/steam/steamapps/shadercache/1903340/fozpipelinesv6/) — Deleted 721MB Fossilize pipeline cache to force full recompilation. No change to Phase 2 crash.

• Fresh Proton prefix — Deleted ~/.steam/steam/steamapps/compatdata/1903340/ entirely and rebuilt from scratch. No change after reinstalling MF components.

• Game file integrity verification — Confirmed via Steam. No corrupted files detected.

• Main menu MP4 video files renamed to .bak — Prevented the game from loading pre-rendered menu background videos. No change to crash frequency. Confirmed that crashes are not solely triggered by the video decode pipeline and persist during general 3D rendering.

• linux-lts kernel (6.12.x) — Switched from standard kernel. No change.

• linux (standard Arch kernel) — Tested in addition to LTS. No change.

• linux-mainline — Most recent upstream kernel, installed from AUR. No change. Confirmed that no available kernel version resolves the crash.

• mesa-git → stable Mesa 25.x — Switched from bleeding-edge development Mesa to stable release. No change.

• linux-firmware force reinstall — Reinstalled to ensure latest VCN 5.0 firmware blobs (shipped via linux-firmware for Navi 48). No change.

• gamescope nested compositor — Launched game inside gamescope to bypass KWin entirely and provide an independent rendering/display pipeline. Phase 2 crash persisted identically inside gamescope.

• X11 session — Partially tested; Wayland-specific bugs ruled out as cause since crash persists inside gamescope (which has its own display pipeline independent of both KWin and X11).

• iommu=pt kernel parameter — Switched IOMMU from strict translated mode to passthrough, removing DMA validation. No change.

• amd_iommu=soft kernel parameter — IOMMU in software emulation mode. No change.

• amdgpu.gpu_recovery=0 kernel parameter — Disabled amdgpu's GPU hang recovery handler. System still rebooted instantly rather than freezing, confirming the reset does not originate within the amdgpu driver's own fault handling.

• amdgpu.vm_fault_stop=2 kernel parameter — Instructs amdgpu to stop the offending process on VM fault rather than resetting. No effect; system still reboots instantly. Confirmed fault is not being handled at the amdgpu driver level.

• kernel.panic=0 and kernel.panic_on_oops=0 — Both already set to 0 (halt on panic). System still reboots instantly. Confirmed: not a kernel panic.

• pstore / ramoops — Configured via kernel parameters; empty after every crash. Confirmed: kernel panic handler never executes.

• BIOS watchdog disabled — Disabled hardware watchdog timer in BIOS. System still reboots instantly. Ruled out BIOS watchdog as reboot mechanism.

• kdump — Attempted; no kdump service unit present on EndeavourOS/Arch. Setup incomplete.

4. Hardware-Level Solutions Attempted

All of the following were tested without success.

• EXPO profile disabled (RAM) — Disabled XMP/EXPO memory overclocking profile in BIOS, forcing RAM to JEDEC default speed and timings. No change. Ruled out marginal RAM stability.

• PBO disabled (CPU) — Disabled AMD Precision Boost Overdrive in BIOS, removing automatic CPU frequency boosting. No change. Ruled out CPU overclocking instability.

• Curve Optimizer disabled (CPU) — Disabled per-core voltage offset tuning. No change.

• GPU power limit reduced — Reduced GPU power consumption via system settings. No change. Ruled out GPU power delivery as a factor.

• BIOS watchdog timer disabled — Disabled the motherboard's hardware watchdog. System still rebooted instantly after game crash. Confirmed the reboot mechanism is not the BIOS watchdog.

• BIOS updated to latest version — Updated motherboard firmware to the most recent available AGESA revision for the B650/AM5 platform. No change.

• Audio output changed (DAC switched) — Tested with different audio output hardware. No change. Ruled out audio driver interaction.

• Fake secondary monitor via sudo modprobe vkms — Created a virtual second display using the VKMS kernel module and enabled it in KDE Display Settings, with both the real monitor and the virtual monitor each tested as the primary display. A community workaround reported to resolve video-element-related crashes on the RX 9070 XT. No change.

• CPU, RAM, and GPU all simultaneously at stock settings — All three tuning systems disabled simultaneously. No change. Confirmed hardware instability from overclocking is not a factor.

5. Working Theory

Based on the complete body of evidence collected, the following is the most coherent explanation consistent with all observations:

Clair Obscur: Expedition 33's UE5 rendering pipeline issues a GPU command or memory access on the Navi 48 (gfx1201/RDNA 4) architecture that triggers a fault in the AMD Platform Security Processor (PSP), resulting in an immediate, unconditional platform-level hard reset that bypasses all OS and firmware error reporting infrastructure.

Supporting evidence:

• Zero CPER records in rasdaemon: Platform firmware is not going through the standard ACPI hardware error reporting pathway before resetting. This is only consistent with a PSP-initiated reset, which operates outside standard error reporting.
• Empty pstore: The kernel panic handler never executes, meaning the CPU is reset before any OS-level fault response can occur.
• kernel.panic=0 irrelevant: A setting that prevents kernel panics from rebooting the system has no effect, because this is not a kernel panic.
• amdgpu.vm_fault_stop=2 irrelevant: The amdgpu driver's own fault handler never gets to respond, because the reset happens at a level below the kernel driver.
• BIOS watchdog disabled, still reboots: Eliminates the BIOS watchdog as the reset mechanism.
• Both RADV and AMDVLK crash identically: Two completely independent Vulkan driver implementations crash in the same way. The only common layers below both are the amdgpu kernel driver, the VCN 5.0 GPU firmware, and the PSP. The fault originates in one of these.
• Both DX11 (DXVK) and DX12 (VKD3D-Proton) crash identically: The fault is not in either D3D translation layer.
• FurMark is stable: General 3D rendering and power delivery are healthy. The fault is triggered by something specific in this game's command stream, not by general GPU load.
• Main menu video files renamed, crashes persist: The crash is not solely caused by the video decode (VCN) pipeline and persists during general rendering.
• RX 9070 XT (Navi 48) is an early 2025 release: RDNA 4 Linux driver support is immature. VCN 5.0 in particular has documented instability on Linux in the community, including confirmed system crashes tied to hardware video decode on this specific GPU generation.

The most precise remaining hypothesis is that this game's UE5 command stream — possibly in combination with the partially broken Media Foundation pipeline (colorcnv.dll unregistered, video decode path incomplete) — causes the Navi 48 GPU hardware to enter a state that the PSP considers a critical fault, triggering an unconditional system reset. This is a firmware or driver bug, not a user-configurable issue. It requires a fix in one or more of: the amdgpu kernel driver, the Navi 48 GPU firmware (shipped via linux-firmware), or VKD3D-Proton's handling of UE5's specific D3D12 command patterns on gfx1201 hardware.

Report compiled following extensive user-side diagnostic investigation. All standard user-accessible remediation paths have been exhausted. An upstream code fix is required.

dxdiag_linux_equivalent.txt

76561198127768424.zip