nike4613 / BeatSaber-IPA-Reloaded

A Unity mod injector built for Beat Saber.
https://nike4613.github.io/BeatSaber-IPA-Reloaded/
Other
185 stars 28 forks source link

System.EntryPointNotFoundException: SetPeekMessageHook on Linux #18

Closed Corben78 closed 4 years ago

Corben78 commented 5 years ago

With BS IPA version 3.13.x which gets installed via Mod Assisstant for Beat Saber version 1.3.0 the mods aren't loaded on Linux with wine/proton anymore.

It seems to get loaded, but stops with this message in the log file:

[INFO @ 22:16:01 | _] System.EntryPointNotFoundException: SetPeekMessageHook
[INFO @ 22:16:01 | _]   at (wrapper managed-to-native) IPA.Utilities.CriticalSection+WinHttp.SetPeekMessageHook(IPA.Utilities.CriticalSection/WinHttp/PeekMessageHook)
[INFO @ 22:16:01 | _]   at IPA.Utilities.CriticalSection.ResetExitHandlers () [0x00018] in <5d740ba0e5eb41aba55dc7889c3ff942>:0 
[INFO @ 22:16:01 | _]   at IPA.Utilities.CriticalSection.Configure () [0x0000f] in <5d740ba0e5eb41aba55dc7889c3ff942>:0 
[INFO @ 22:16:01 | _]   at IPA.Injector.Injector.Main (System.String[] args) [0x00067] in <48d88cb1b3d24e2cac71318bd6c46df6>:0 

It was working perfectly with the override winhttp=n,b before this version.

yshui commented 5 years ago

my suspicion is that when we get to the point where BSIPA tries to P/invoke SetPeekMessageHook, wine is loading the builtin winhttp.dll. (i don't know exactly how wine loads dlls, but i think it loads the native winhttp.dll (the proxy) first. when the proxy loads the original winhttp.dll, wine switches to use the builtin one. I suspect wine just returns the builtin winhttp.dll for all further requests).

to prove my suspicion, i use the winhttp=n override instead, and rename the wine builtin winhttp.dll to winhttp_alt.dll, and everything works.

i don't know how would you solve this problem properly though.

yshui commented 5 years ago

i filed a issue to Wine upstream: https://bugs.winehq.org/show_bug.cgi?id=47705

it will be great, if BSIPA developers can provide some more context there

Corben78 commented 5 years ago

Great to hear you found a workaround @yshui! I've tinkered around with getting a native winhttp.dll and renaming it to winhttp_alt.dll as well, but was out of luck. I don't know what's this renaming to _alt is about though.

to prove my suspicion, i use the winhttp=n override instead, and rename the wine builtin winhttp.dll to winhttp_alt.dll, and everything works.

Just to make sure, which one to rename? The one in Steam/steamapps/compatdata/620980/pfx/drive_c/windows/system32, in syswow64, or the one in the games directory? I couldn't get it to work yet, as I get this error then:

Doorstop: Fatal
Unable to load the original WINHTTP.dll (looked from system directory and from WINHTTP_alt.dll)!

Any advice?

Did you install a native winhttp.dll e.g. copied from a Windows install or via winetricks?

yshui commented 5 years ago

@Corben78 i renamed the one in the prefix (which is a "wine fakedll"), and the one in the proton installation (steamapps/common/Proton 4.11/dist/lib64/wine/winhttp.dll.so).

this is not meant to be a work around, this is just me investigating what is going on.

geefr commented 5 years ago

Not sure if it's helpful (I've given up wine for now as steamvr hates me) but strace can always tell you what's being loaded at the expense of a very verbose log, just use strace wine prog.exe &> somehugelogfile

If you look for winhttp.dll in the log it'll show the load, and result of whatever syscalls it's making to do so.

Corben78 commented 5 years ago

Arlight, it works for me too with the changes @yshui did: To not mess with the original Proton version, I copied the folder Steam/steamapps/common/Proton\ 4.11 to ~/.steam/root/compatibilitytools.d/Proton 4.11-BS (if missing create compatibilitytools.d) and created a file compatibilitytool.vdf in that folder, to change the display name of this "custom" Proton version to Proton-4.11-3-BS. compatibilitytool.zip

After doing a fresh Beat Saber install, and selecting this "custom" Proton version, as well as running it once (it has to run once before installing mods anyway), I renamed:

mv ~/.steam/root/compatibilitytools.d/Proton 4.11-BS/dist/lib64/wine/winhttp{,_alt}.dll.so
mv ~/.steam/steam/steamapps/compatdata/620980/pfx/drive_c/windows/syswow64/winhttp{,_alt}.dll

(your folders might be different) With launch parameter WINEDLLOVERRIDES="winhttp=n" %command% the mods do work.

When re-creating the game's proton prefix, you need to rename winhttp_alt.so.dll to the original first.

Though this is not a nice solution, I think it is at least a workaround to play Beat Saber 1.3.0 modded until this is fixed either in BSIPA or wine/proton.

aeikum commented 5 years ago

The simplest thing to do would be to rename your wrapper library so it doesn't have a name conflict with the system library. I'm not sure exactly what's going on here, but application libraries with the same name as system libraries has been a long-time problem with Wine[1,2] and I don't see it being resolved any time soon.

[1] https://bugs.winehq.org/show_bug.cgi?id=43472 [2] https://www.codeweavers.com/about/blogs/elee/2019/8/22/whats-in-a-name

nike4613 commented 5 years ago

Unfortunately, the naming is how I get code running early. I'm looking at completely removing that piece of functionality, as it doesn't seem to be doing what it's supposed to, so it may not be an issue in the future. For now though, if Wine can't/won't fix their loading issue, the winhttp_alt.dll solutions are the best ones. (There is, after all, explicit code to support exactly this case)

Corben78 commented 5 years ago

Hi @nike4613,

where you able to remove the functionality in question for the Beat Saber 1.5.0 adjustments? Atm it seems the workaround with the renaming is still needed.

nike4613 commented 5 years ago

The version we're using with 1.5.0 is still the same 3.13.2 (even the same build). I am working on a new version that consists of major rewrites of large portions of the codebase, so it will likely be adjusted then.

As annoying as the fix may be, at least you don't have to worry about shitty Windows permissions in your install dir ;p, and at least there is a fix.

nike4613 commented 4 years ago

This will likely be fixed by 69c7a889b209f2b07766e210b44e5fb799c8bd86, as that forces Mono to load the right DLL. I will update this when that branch is merged.