Update after more debugging — narrowed to two distinct problems.
msvcp140.dll being loaded by the x86-64 processWINEDEBUG=+loaddll on the x86-64 probe shows:
trace:loaddll:build_module Loaded L"C:\\windows\\system32\\MSVCP140.dll" ... : native
=>0 0x006ffff96a14b4 in msvcp140 (+0x714b4)
0x006ffff96a14b4 msvcp140+0x714b4: ldr x8, [x8]
The prefix's system32/msvcp140.dll is Aarch64 (PE32+ ... Aarch64), and it is being
loaded into the x86-64 process, where it faults. (system32/vcruntime140_1.dll is x86-64,
system32/msvcp140.dll / vcruntime140.dll are Aarch64 — mixed.)
Workaround that removes the crash: place an x86-64 msvcp140.dll / vcruntime140.dll /
vcruntime140_1.dll next to the exe. Wine then loads those from the app dir
(Loaded L"Z:\\...\\MSVCP140.dll" ... : native, x86-64) and the xrCreateInstance crash goes away.
With the x86-64 runtime in place, the loader runs and reports:
err:openxr:get_vulkan_extensions Could not create key, status 0x2.
RuntimeInterface::LoadRuntime skipping manifest file C:\openxr\wineopenxr64.json, negotiation failed with error -6
RuntimeInterface::LoadRuntimes - failed to load a runtime
... XR_ERROR_RUNTIME_UNAVAILABLE (XrResult -51)
wineopenxr.dll loads as builtin. The failure is in get_vulkan_extensions
(Could not create key, status 0x2).
This was captured headless (proton run with no display/Vulkan). I'm now re-testing through
Steam with a display and SteamVR active, and will update with the result.
Resolved on my side with a workaround — confirming this is real and reproducible.
Workaround: ship the x86-64 msvcp140.dll / vcruntime140.dll / vcruntime140_1.dll
next to the x86-64 exe (so the app dir wins over system32). With that in place, the mod now
initializes OpenXR fully through Proton + SteamVR:
stage=openxr_instance
OpenXR runtime: SteamVR/OpenXR version=2.18.1
stage=openxr_headset
Finger tracking: available, unobstructed motion: available
Headset: SteamVR/OpenXR : cv, positional tracking: reported
stage=openxr_graphics_requirements
stage=openxr_view_configuration
stage=openxr_actions
stage=openxr_ready
xr_resolution ... width=1728 height=1728
call_thunks ... allocated=6fff4c260000 error=0
No crash; the game runs in VR at 1728x1728.
The earlier err:openxr:get_vulkan_extensions Could not create key, status 0x2 was a headless
artifact (proton run with no display/Vulkan); it does not occur in a normal Steam launch with a
display and SteamVR active.
So the actionable bug is: an x86-64 process is loading the Aarch64/ARM64EC
C:\windows\system32\msvcp140.dll (and vcruntime140.dll), causing an access violation in
native ARM64 code (ldr x8,[x8], read from 0x0). Shipping the x86-64 runtime works around it.
system32/vcruntime140_1.dll is already x86-64 while msvcp140.dll/vcruntime140.dll are
Aarch64, so the prefix's system32 is mixed.
Final status: the workaround fully resolves it end-to-end.
With the x86-64 msvcp140.dll / vcruntime140.dll / vcruntime140_1.dll next to the exe,
the app now initializes OpenXR and runs in VR via Proton ARM64 + SteamVR, e.g.:
stage=openxr_instance
OpenXR runtime: SteamVR/OpenXR version=2.18.1
stage=openxr_headset
Headset: SteamVR/OpenXR : cv, positional tracking: reported
stage=openxr_ready
eye=0 width=1728 height=1728 eye=1 width=1728 height=1728
The get_vulkan_extensions ... status 0x2 error I mentioned earlier was indeed a headless-only
artifact (no display/Vulkan) and does not occur in a normal Steam launch.
An x86-64 process loads the Aarch64/ARM64EC C:\windows\system32\msvcp140.dll and
vcruntime140.dll and faults (EXCEPTION_ACCESS_VIOLATION, read from 0x0, ldr x8,[x8]).
system32 is mixed: vcruntime140_1.dll is already x86-64, while msvcp140.dll /
vcruntime140.dll are Aarch64. Providing the x86-64 versions in the app dir is the workaround;
ideally Wine would resolve the WoW64 (x86-64) MSVC runtime for x86-64 processes.
Happy to provide more logs / re-test a fix.
Hello @jesse-chelin, 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/4001#issuecomment-5952344655.
proton 11.0x1 2026-10proton 11.0-2cx1 2026-10proton experimentalx1 2026-10WINEDEBUG=+loaddllx1 2026-10msvcp140.dllx4 2026-10vcruntime140.dllx3 2026-10vcruntime140_1.dllx3 2026-10wineopenxr.dllx1 2026-10
[ARM64 / Steam Frame] x86-64 Windows OpenXR apps crash in xrCreateInstance under Proton ARM64
Summary
On SteamOS for Steam Frame (aarch64), x86-64 Windows OpenXR applications running under
Proton ARM64 (WoW64 / FEX) crash while creating the OpenXR instance. Proton's
wineopenxrruntime appears to load and even connect to SteamVR, but
xrCreateInstancefails/crashes.Environment
20260928.6175029, kernel6.18.0,aarch64experimental-11.0-20260924-cache-arm64(also reproduced withproton-11.0-2c-arm64)libwow64fex.so,libarm64ecfex.so/opt/steamvr/bin/linuxarm64/vrclient.so); host OpenXR~/.config/openxr/1/active_runtime.json -> /opt/steamvr/steamxr_linuxarm64.jsonActiveRuntime:C:\openxr\wineopenxr64.jsonSteps to reproduce
Concretely, the CircuitLord TF2 VR mod ships a probe:
TF2VR/tools/xr_probe.exe.xr_probe.exe --inventoryinside the Titanfall 2 prefix.Expected
The OpenXR instance is created and the runtime/headset is reported.
Actual
The probe prints the runtime manifest path and then stops at the instance stage:
The full application (Northstar + the VR plugin) crashes inside
xrCreateInstance:~/.local/share/Steam/logs/vrserver.txtshows Proton's wineopenxr DID connect to SteamVR, thenthe process drops:
Notes
like a crash in the loader↔wineopenxr negotiation path on ARM64 (possibly FEX/ARM64EC related),
not a missing-runtime misconfiguration.
ActiveRuntimeboth resolve correctly.Attached
environment.txtxr_probe_output.txtengine.txt(the mod's staged init log)northstar_crash.txtvrserver_excerpt.txtLogs
environment.txtxr_probe_output.txtengine.txtnorthstar_crash.txtvrserver_excerpt.txt