http://bugs.winehq.org/show_bug.cgi?id=60255 Bug ID: 60255 Summary: ntdll: NtQuerySystemInformation(SystemPerformanceInformation) causes unhandled page fault (execute access to NULL) on native Win64 app Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: ntdll Assignee: wine-bugs@list.winehq.org Reporter: atayksll@gmail.com Target Milestone: --- Distribution: --- # Summary Unhandled page fault (jump to NULL instruction pointer) immediately after `fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION`, reproducible with SpaceEngine (beta 0.990.48.2034) on startup. Same crash occurs across three different Wine-derived runtimes. # Environment - Distro: Fedora Linux (KDE Plasma 6, Wayland) - Kernel: 7.1.10-200.fc44.x86_64 - GPU: AMD Radeon RX 5600 XT (Navi 10), Mesa 26.1.6 (git-ffa422e53d), RADV/radeonsi, ACO - CPU: Intel Core i7-10700F (16 threads) - RAM: 32 GB - Wine builds tested (all produce the identical crash): - wine-experimental.bleeding.edge.11.0.411656.20260810 (TkG Plain) - Wine 11.0 stable - Proton (added SpaceEngine.exe as a non-Steam game) - Application: SpaceEngine beta 0.990.48.2034 (native Win64 build, not DXVK/vkd3d — game uses Wine's built-in OpenGL translation directly) # Reproduction steps 1. Install SpaceEngine (Win64 beta build) into a 64-bit Wine prefix. 2. Launch `SpaceEngine.exe` from its `system` folder. 3. The launcher/splash appears for under a second, then the process crashes with no dialog. # Observed behavior With `WINEDEBUG=+loaddll` the process log shows normal startup: all core DLLs load, `SpaceEngine.exe`, `SDL2.dll`, `openvr_api.dll`, etc. all load successfully as `native`, OpenGL context creation succeeds, and the game's own log (`se.log`, included below) shows OpenGL init, SDL init, and SDL_mixer init all completing normally before entering its hardware-detection ("INITIALIZING LOADER") step. The crash consistently happens at this exact point, right after: ``` 00ec:trace:loaddll:build_module Loaded L"C:\windows\system32\dinput8.dll" at 00006FFFFDB70000: builtin 015c:fixme:avrt:AvSetMmThreadCharacteristicsW (L"Pro Audio",...): stub 00ec:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION wine: Unhandled page fault on execute access to 0000000000000000 at address 0000000000000000 (thread 00ec), starting debugger... ``` No further trace lines appear between the `fixme` line and the fault, which suggests the fault happens inside ntdll's own handling of this info class rather than after control returns to the application. Register dump (identical register values and stack contents reproduced across separate runs and separate Wine builds): ``` rip:0000000000000000 rsp:000000000010f8e8 rbp:0000000000000000 rax:0000000000000000 rbx:0000000000000000 rcx:0000000000000000 rdx:0000000000000000 rsi:ffffffffffffffff rdi:0000000000000004 r8:00000000ffffffff r9:0000000000000000 r11:0000000000000000 r12:0000000000001000 r13:0000000140d8f2a8 r14:0000000000000003 r15:0000000000000001 Backtrace: =>0 0000000000000000 (0000000000000000) 0000000000000000: -- no code accessible -- ``` `r13` (0000000140d8f2a8) consistently points to a fixed static offset inside `spaceengine.exe`'s own address space (module base 0000000140000000), the same value across every crash, on every Wine build tested — behavior is fully deterministic. # se.log excerpt (SpaceEngine's own log, up to the last line printed before crash) ``` INITIALIZING LOADER [MT] Number of CPUs: 16 [MT] Worker threads: 14 [MT] Total RAM: 31997 Mb [MT] Available RAM: 26908 Mb [MT] Max SE RAM: 8192 Mb ``` No further lines are ever written to se.log after this point — the crash happens before the next planned log line. # What has been ruled out - GPU/Vulkan driver stack: `vulkaninfo` runs cleanly and correctly identifies the RX 5600 XT via RADV. - `GL_ARB_bindless_texture`: hiding it via `MESA_EXTENSION_OVERRIDE=-GL_ARB_bindless_texture` had no effect on the crash (ruling out the known AMD bindless-texture driver bug class as the cause here). - `openvr_api.dll`: this is a hard load-time import of the executable; removing it just fails earlier with `STATUS_DLL_NOT_FOUND` rather than avoiding the real crash, so VR init isn't the trigger. - Wine build/runner choice: identical crash (same register values, same crash address) on wine-experimental TkG bleeding-edge, wine-11.0 stable, and Proton. # Question / request Is `SystemPerformanceInformation` handling in `ntdll`'s `NtQuerySystemInformation` known to be incomplete or buggy on x86-64 Linux hosts in a way that could produce this kind of null-pointer-execute fault rather than a clean error return? Happy to provide the full debug logs, `se.log`, or test further patches/builds if that would help narrow this down — this crash is 100% reproducible on this hardware. generated via claude. it did all the work finding this bug while trying to fix space engine for me. sorry. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.