"java.lang.UnsatisfiedLinkError: C:\[...]\.sable\natives\sable_rapier_x86_64_windows.dll: The specified procedure could not be found" when loading a map in single user #1616

Activity

1. takeda

   added

   type: crashSomething crashes my gameSomething crashes my game

   on Oct 8, 2026
2. takeda

   changed the title [-]java.lang.UnsatisfiedLinkError: C:\[...]\.sable\natives\sable_rapier_x86_64_windows.dll: The specified procedure could not be found when loading a map in single user[/-] [+]"java.lang.UnsatisfiedLinkError: C:\[...]\.sable\natives\sable_rapier_x86_64_windows.dll: The specified procedure could not be found" when loading a map in single user[/+] on Oct 8, 2026
3. takeda commented on Oct 8, 2026

   

   takeda

   on Oct 8, 2026

   Last edited by takeda

   Author

   More actions

   I used this tool to get better insight:

   It shows these calls missing:

   • in bcryptprimitives.dll I appear to not have ProcessPrng
   • in kernel32.dll I appear to not have GetSystemTimePreciseAsFileTime

   Since those are system libraries, it suggests me that maybe the fix would actually be to build the library using Windows 7 compatible Rust to target that platform.

   Is that an option?

   Looking at rust perhaps using the target x86_64-win7-windows-msvc would do it?
   https://doc.rust-lang.org/rustc/platform-support/win7-windows-msvc.html
4. Enderlais commented on Oct 8, 2026

   

   Enderlais

   on Oct 8, 2026

   Last edited by Enderlais

   More actions

   this translation layer / kernel extention fixes it btw

   https://github.com/i486/VxKex

   it adds some dlls from windows 10 and redirects the calls to these dlls. thats how they did it. it works. if you define java to always use the compatibility layer instead of the vanilla dll files
5. takeda commented on Oct 8, 2026

   

   takeda

   on Oct 8, 2026

   Author

   More actions

   This looks great, but antivirus scan lights up as a Christmas tree:

   https://www.virustotal.com/gui/file/7db81065591ab62f2086af84ff5cbf0d021589715024ba893e22a74f6c8708cd

   I understand there cold be false positive, but this is too much.

   I see people raised issues on repo which were closed. Some suggestions are that the current repo owner purchased the code from original author and injected malware into it.

   I am still hoping that maybe this can be easily resolved by telling rust to build it for windows 7. I don't have rust dev experience or working rust setup on windows but if I find some time I can try. But even if I succeed and post a working dll, how then you can trust I didn't injected anything into it. I would love if the author would officially support it (if it is an easy change of course)
6. Enderlais commented on Oct 8, 2026

   

   Enderlais

   on Oct 8, 2026

   More actions

   i understand the concern. it is impossible for the kernel extention to not be detected since it is redirecting windows specific dll files into its own. so it will be detected regardless. i dont know anything about anny code beeing bought, i have no idea about that. i used this under my server regardless since it is a pure minecraft server and so nothing senistive could be lost (it sat behind its own firewall). for me it worked. and since it is open source and the nature of dlls, kernel extentions and such i categorized it as a false positive.

   but its maby an interesting thing to bulid mod support from if we cant fix it otherwise
7. takeda commented on Oct 9, 2026

   

   takeda

   on Oct 9, 2026

   Last edited by takeda

   Author

   More actions

   @Enderlais Yes I saw that this is a kernel module so it might have false positives, but it still is weird. First of all I saw someone comment that this is only the file, once is installed you don't even get any warnings anymore. Which actually raises all red flags, it's not the installer that should alert it should be the installed app.

   Second, I saw comments that you're free to compile and will get the same warnings. The problems I see is that the source includes build tools that are already compiled and when I sent them for scan they also show being infected with something. Why would the installer have false positives?

   Then there's the whole thing with the original author disappearing (I misread that it was bought by someone), not only on github but also deleted account on msfn.org, then another one (i486) showing up that seems to still be in contact with the original author, and supposedly original was doxed etc. it's so weird.

   People on msfn.org were also asking why not provide a portable version (i.e. without self extracting installer, so they can inspect the individual files if they are malicious or not), but that was ignored.

   Anyway, I bit the bullet and actually I got it to work without any emulation framework. It was a bit a adventure with it for me as I don't have experience with gradle and rust and then there was additional surprises, like the mod reverting the dll on start, and when I made it read-only it crashed with no permissions. So I had to build the whole mod.

   But it worked!

   Here are the changes I made (for someone experienced it probably would be 5 minutes took me a bit longer):

   $ git diff
   diff --git a/sable_rapier/build.gradle b/sable_rapier/build.gradle
   index da279f2..f7268d7 100644
   --- a/sable_rapier/build.gradle
   +++ b/sable_rapier/build.gradle
   @@ -27,7 +27,7 @@ def freebsd(arch) {
    }
   
    def windows(arch) {
   -    [triple: "${arch}-pc-windows-msvc", suffix: "", arch: arch, os: "windows", ext: "dll", lib: false]
   +    [triple: "${arch}-win7-windows-msvc", suffix: "", arch: arch, os: "windows", ext: "dll", lib: false]
    }
   
    def supportedTargets = [
   @@ -107,7 +107,7 @@ def windows(arch) {
   
    def commandLineForTarget(target) {
        if (target.triple.contains('msvc')) {
   -        [project.ext.xWinCargo, 'xwin', 'build', '--target', target.triple + target.suffix].flatten()
   +        [project.ext.xWinCargo, '+nightly-2026-01-29', 'xwin', 'build', '-Z', 'build-std', '--target', target.triple + target.suffix].flatten()
            // support meme platforms, this does nothing by default because the target is disabled
        } else if (target.triple == 'aarch64-unknown-freebsd') {
            [project.ext.zigbuildCargo, 'zigbuild', '-Z', 'build-std', '--target', target.triple + target.suffix].flatten()
   diff --git a/sable_rapier/src/main/resources/natives/sable_rapier/sable_rapier_binaries.zip.l4z b/sable_rapier/src/main/resources/natives/sable_rapier/sable_rapier_binaries.zip.l4z
   index 6c60b19..a58b9c5 100644
   Binary files a/sable_rapier/src/main/resources/natives/sable_rapier/sable_rapier_binaries.zip.l4z and b/sable_rapier/src/main/resources/natives/sable_rapier/sable_rapier_binaries.zip.l4z differ
   diff --git a/sable_rapier/src/main/rust/container/xwin/Dockerfile b/sable_rapier/src/main/rust/container/xwin/Dockerfile
   index 3167083..837add6 100644
   --- a/sable_rapier/src/main/rust/container/xwin/Dockerfile
   +++ b/sable_rapier/src/main/rust/container/xwin/Dockerfile
   @@ -5,6 +5,7 @@ ARG RUST_VERSION
    RUN rustup default ${RUST_VERSION}
    RUN rustup target add x86_64-pc-windows-msvc
    RUN rustup target add aarch64-pc-windows-msvc
   +RUN rustup component add rust-src --toolchain nightly-2026-01-29-x86_64-unknown-linux-gnu
    RUN cargo xwin cache xwin
   
    WORKDIR /

   Though, since as it is it requires me to basically rebuild the mod every time it would be updated, I'm wondering if @ryanhcode would be able to add support for Windows 7. I believe build for win7 also should work on 8, 10, 11, but I understand that technically *-win7-windows-msvc is Tier 3 as Windows 7 is EOL (which means it is still there but no longer being built nightly so we need to build it ourselves. It doesn't seem to add much extra time to build though).

   I can provide the mod I created but the same concerns apply, but at least it isn't a kernel module.