http://bugs.winehq.org/show_bug.cgi?id=46697 --- Comment #14 from zyfgs2012 <zyfgs2012@gmail.com> --- Additional affected configuration: ASTLIBRA Revision v1.4.1 startup failure in a DLL hooking the missing ZwQueryDirectoryFileEx export This is downstream compatibility evidence related to bug 46697, not a claim of a regression reproduced on stock upstream Wine. Environment - Android 16 / Snapdragon 8 Elite Gen 5 (ARM64) - DroidDeck 0.4.0, Linux runtime r9 - Proton Experimental ARM64: experimental-11.0-20261014-arm64 - Export absence also checked in DroidDeck-Proton 11-9.1 - An x86-64 Windows game directory labeled ASTLIBRA Revision v1.4.1. The supplied DLL is named steam_api64.dll; its provenance has not been independently verified. This report must not be interpreted as confirmation that an unmodified official Steam build has the same failure. Observed behavior Starting ASTLIBRA.exe from Steam produces a black screen / no visible game window. Two native ptrace captures show a null branch during initialization of the supplied steam_api64.dll. Export inspection Both installed Wine ntdll.dll images export NtQueryDirectoryFile and ZwQueryDirectoryFile, but neither exports NtQueryDirectoryFileEx nor ZwQueryDirectoryFileEx. Inspection of current upstream dlls/ntdll/ntdll.spec also finds the legacy exports but not the Ex variants. Call-chain evidence (RVAs relative to this specific steam_api64.dll) - +0x10E77 resolves "ZwQueryDirectoryFileEx" from "NTDLL". - +0x10E94 calls a hook-installation helper (+0x7A810) with the resolved target. - The missing export results in a null target being passed into a code-decoding / byte-reader path. - At +0x8C5B1, instruction bytes FF 11 (call qword ptr [rcx]) encounter a null callback; the captured slot [RCX] is zero. - The translated native instruction is BLR X11 with X11=0, followed by SIGSEGV at PC=0 / si_addr=0. This evidence alone does not establish a FEX translation bug. Local workaround used to establish the affected path The DLL already has a fallback to the old ZwQueryDirectoryFile hook if installation of the Ex hook reports failure. However, the hook helper crashes on the null target before it can return failure. For this exact DLL only, replacing the five-byte call at RVA +0x10E94 (E8 77 99 06 00) with xor eax,eax and three NOPs (31 C0 90 90 90) lets its existing legacy fallback execute. This is a local binary workaround, not a Wine source patch or an implementation of the Ex API. After that change, the same original Steam entry and Proton runtime initialize DXVK and display the opening sequence and title menu. A fresh normal launch with diagnostic environment overrides removed also succeeds. Long gameplay and full save/load coverage have not been verified. Original DLL SHA-256: 65259d162a4cb9a57abd214723db0555f1c5c8b65dda828f4a641e2083f70e6c Scope and request The DLL's missing null check is an application-side defect. The separate upstream compatibility gap is the missing Nt/ZwQueryDirectoryFileEx API. This case may be additional impact evidence for that gap, even though the application can fall back after correcting its error handling. The same game directory reportedly works on Windows; its exact Windows export/call path has not been captured. No stock desktop Wine reproduction or Wine source-level fix is claimed here. Would implementation and export of both API names belong under this existing issue? The local workaround and any historical stub patch should not be assumed to provide full API semantics. -- 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.