https://bugs.winehq.org/show_bug.cgi?id=56257
Bug ID: 56257 Summary: ArcheAge r566361-r592955 fail to load game DLL due to hooked LdrLoadDll calling GetModuleHandleA Product: Wine Version: 9.1 Hardware: x86-64 URL: https://archive.org/download/arche-age-24-25-171-bin-6 4/ArcheAge-24-25-171-bin64.zip OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs@winehq.org Reporter: eniw@ardel.eu Distribution: ---
Created attachment 75969 --> https://bugs.winehq.org/attachment.cgi?id=75969 Patch that sets file_name_AtoW alloc=TRUE for LoadLibraryExA & GetModuleHandleExA
ArcheAge revisions 566361 to 592955 have enabled an overridden LdrLoadDll which on first invocation looks up the location of ntdll.dll NtQueryInformationThread through GetModuleHandleA & GetProcAddress and then memoizes it.
This however means that on first LoadLibraryA call that will use the hooked LdrLoadDll, the dll name stored in TEB StaticUnicodeString also gets overwritten by the GetModuleHandleA call made by the hooked loader.
In case of ArcheAge, the name of the DLL that is affected by this is cryaction.dll
Here is the sequence of actions that I observed by following wine's output:
LoadLibraryA("cryaction.dll") LoadLibraryExA file_name_AtoW (DLL name "cryaction.dll" is copied into TEB) LoadLibraryExW load_library LdrLoadDll (hooked) GetModuleHandleA("ntdll.dll") GetModuleHandleExA file_name_AtoW (DLL name is overwritten in TEB, now "ntdll.dll") LdrLoadDll (original) ("ntdll.dll" is loaded instead of "cryaction.dll")
Game revisions newer than 592955 still contain the code, however it has been disabled by a flag similar to the way it was before 566361, potentially part of some debug or testing code. The affected binaries are difficult to get hold of as the official sources will always try to install the latest version on top of what you already have. I uploaded binaries for minimal reproduction for revision 566361 (update 25), one version before (update 24, revision 565940) and the latest at the time of writing (update 171, revision 642866).
To run the binaries successfully, ntdll-Junction_Points from staging needs to be applied, which seems currently broken and needs fixes I outlined in bug 12401 or symlinks in .REPARSE_POINT directory tree manually repaired after launching the game for the first time. In addition to that winetricks vcrun2010 may be required.
To start the game, archeage.exe needs certain flags to be present: bin64-update-25\archeage.exe -t +auth_ip 1.2.3.4 -auth_port 1234 -authtoken test -lang en_us
Expected result would be a dialog box showing "Failed to load game data!", as the game data is knowingly omitted from the minimal reproduction. However with update 25 (566361) binaries, another error is displayed: "Framework dll is invalid, check your version", which happens when there is no export "CreateGameFramework" in the found "cryaction.dll" (that got swapped to "ntdll.dll" at the last possible moment).
Changing file_name_AtoW alloc=TRUE at both LoadLibraryExA and GetModuleHandleExA did restore the expected behavior for the affected versions. This fix is also included as a patch. However I am unsure if this is necessarily the right solution and would like more insight if this is not the case.
Another question is whether this is a legitimate bug worth fixing. Despite the high requirements to reproduce this with wine, it used to be enabled in production builds of the game for around 7 months (2022.03 - 2022.10) with not so insignificant user base on Windows, currently the code is still present in binaries, but disabled behind a boolean flag. I think my biggest fear regarding this is that if this ever gets re-enabled, it would be needed to be looked at again by which the rollout of the fix would be slow, but it could simply be another case of YAGNI.