gdalalljni.dll: The specified procedure could not be found

[Nathipha]

What is the bug?

I'm always getting the same error when I try to use gdal.AllRegister() (Java 8 in Eclipse with import org.gdal.gdal.gdal;):

Native library load failed.
java.lang.UnsatisfiedLinkError: C:\Program Files\GDAL\gdalalljni.dll: The specified procedure could not be found
Exception in thread "main" java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI.AllRegister()V

With gdal.VersionInfo(); the exception is pretty similar:

Native library load failed.
java.lang.UnsatisfiedLinkError: C:\Program Files\GDAL\gdalalljni.dll: The specified procedure could not be found
Exception in thread "main" java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI.VersionInfo__SWIG_1()Ljava/lang/String;

I followed the install guide here (didn't install filegdb because I don't need it), which was working fine on Win 10 but now on Win 11 I can't get it to work again:

• Install the "...core.msi" file ("generic installer")
• Create the GDAL_DATA, GDAL_DRIVER_PATH and PROJ_LIB environment variables
• Add C:\Program Files\GDAL and C:\Program Files\GDAL\java to PATH
• Download the .zip for the compiled binaries and copy the gdalalljni.dll file into C:\Program Files\GDAL\java
• Add the "gdal-x-x-x.jar" from the same zip to my project (copy to a new "lib" folder, then add add them in the build path)

The .dll does exist in this folder (actually, both directly in "GDAL" and in "GDAL\java") but for some reason it still can't find it!

What I've tried to far:

• Both the latest GDAL version (3.12.1, downloaded yesterday) and the old version (3.11.1, which was working on Win 10)
• Added a VM argument for this JRE, as suggested in a forum and on the geoserver website ("Note on running GeoServer as a Service on Windows"): -Djava.library.path="C:\Program Files\GDAL;${env_var:PATH}")
• Installed the latest MSVC++ redistributable (link)
• Copied the .dll file into the "lib" folder that already contains the .jar, then set the folder as "native library location" (Project - Properties - Java Build Path - Source)
• Exported it as a .jar file and run it with a .bat file (same error, so it looks like it's not even a problem with Eclipse)
• Run the .jar from regular command prompt (run as admin)
• Set full access permissions for the GDAL folder for my specific Windows admin user

None of this worked, I keep getting the same error.

Steps to reproduce the issue

Install the GDAL as described above and run gdal.AllRegister().

Versions and provenance

Win 11, tested with GDAL 3.12.1 and 3.11.1
I downloaded the files for MSVC 2019 x64 from the gisinternals website.

Additional context

No response

[rouault]

I still think this is a usage issue. Make sure the path to the native library gdalXXX.dll (and its dependencies is in the PATH

[Nathipha]

I still think this is a usage issue. Make sure the path to the native library gdalXXX.dll (and its dependencies is in the PATH

Both folders that contain a gdalalljni.dll file are listed in Windows' PATH and I already restarted my PC multiple times, so they should be definitely there:

What dependencies? The GDAL_DATA, GDAL_DRIVER_PATH and PROJ_LIB environment variables are set. Is there anything else?

[rouault]

Both folders that contain a gdalalljni.dll

I meant the native library gdal311.dll or gdal312.dll. gdalalljni.dll is just a bridge between JNI and the native library

What dependencies?

proj9.dll, geos.dll, etc . They are usually in the same folder as gdal3xx.dll

[Nathipha]

I meant the native library gdal311.dll or gdal312.dll. gdalalljni.dll is just a bridge between JNI and the native library

Those files don't exist, neither in "C:\Program Files\GDAL" nor anywhere in the "compiled binaries" zip (at least the file explorer search didn't find them) and I don't remember ever seeing an error mentioning them.

proj9.dll, geos.dll, etc . They are usually in the same folder as gdal3xx.dll

Both of these are located in the main "GDAL" folder.

[rouault]

Those files don't exist

well I don't know the exact name by heart but there's for sure a file somewhere starting with "gdal" and ending with ".dll" other than gdalalljni.dll

[Nathipha]

There are gdal.dll, gdal_wrap.dll and gdalalljni.dll. I just checked my old Win 10 PC and compared the names of all 107 files in the main GDAL folder: They are exactly the same, so three gdal...dll files and no e.g. gdal311.dll. I installed GDAL on it the same way I did on this new Win 11 PC, except that it's working there.
What is this specific dll supposed to do? I googled it but didn't get any results, apart from some shady dll download and exe comparison websites and Google's AI of course also only cited those two as "source".
Are any extra files necessary to use just the basic GDAL with Java? How would you install GDAL to use with Java? Maybe Win 11 just needs an extra step while installing?

Edit: So far I've tested it with two Eclipse versions (including a 2025 version) and IntelliJ IDEA (latest version) and got the same error message with all of them.

[geographika]

@Nathipha - The specified procedure could not be found is probably due to DLLs from different versions of GDAL being mixed up.

I'd suggest downloading https://download.gisinternals.com/sdk/downloads/release-1944-x64-gdal-3-12-1-mapserver-8-6-0.zip unizipping, and running SDKShell.bat to set environment variables and test from there.

This an installation issue rather than a GDAL issue.

[Nathipha]

@Nathipha - The specified procedure could not be found is probably due to DLLs from different versions of GDAL being mixed up.

This is impossible, I downloaded both files from here within less than 5 minutes:
I installed gdal-3.12.1-1929-x64-core.msi, then copied the .dll into the GDAL\java folder and the .jar into the Eclipse project, both taken from release-1929-x64-gdal-3-12-1-mapserver-8-6-0.zip. When that didn't work, then I used the old 3.11.1 files I'd already successfully used on my old Win 10 PC (I downloaded and installed those the same way).

I'd suggest downloading https://download.gisinternals.com/sdk/downloads/release-1944-x64-gdal-3-12-1-mapserver-8-6-0.zip unizipping, and running SDKShell.bat to set environment variables and test from there.

You linked the MSVC 2022 version, while I was always using MSVC 2019. Is there a big difference?
Currently version 3.11.1-1928 (=2019) is still installed. I removed all the environment variables and PATH entries I'd manually added for GDAL, then unzipped the release-1928-x64-gdal-3-11-1-mapserver-8-4-0.zip in a random folder again and ran the SDKShell.bat file:

Setting environment for using the GDAL and MapServer tools.
Hiding the OCI plugin library.
1 file(s) moved.
1 file(s) moved.

Afterwards I restarted my PC. It did, however, not add any new environment variables or PATH entries and I was still getting the same error. I tried again but this time I unzipped it into the GDAL folder - no luck. Third test: .bat started as admin - I didn't get the "moved" message again this time but it still didn't actually add environment variables and it's still not working..
I can uninstall 3.11.1 again and try again with the latest 3.12.1 version but tbh, I haven't got much hope that that'll work because it already didn't the first time.

This an installation issue rather than a GDAL issue.

How do you install it properly on Windows to use with Java? There's the old guide I linked and another one on Stackexchange but I've been following those and if those aren't correct, then I don't know what to do.

[jratike80]

Maybe this GeoServer documentation can help https://docs.geoserver.org/latest/en/user/data/raster/gdal.html. I haven't tried it myself, though. I believe that many GeoServers are running with the GDAL extension successfully.

When it comes to gisinternals and sdkshell.bat, it sets the environment for the current command window only. It does not try to set system wide environment. Open the bat file and see what it does. Or, after running sdkshell.bat run path and you can see what path is was setting.

[Nathipha]

When it comes to gisinternals and sdkshell.bat, it sets the environment for the current command window only. It does not try to set system wide environment. Open the bat file and see what it does. Or, after running sdkshell.bat run path and you can see what path is was setting.

I see, thanks. I checked the GDALShell.bat (directly in the GDAL folder) - VERSION 1:

set SDK_ROOT=%~dp0
set SDK_ROOT=%SDK_ROOT:\\=\%
SET "PATH=%SDK_ROOT%;%PATH%"
SET "GDAL_DATA=%SDK_ROOT%gdal-data"
SET "GDAL_DRIVER_PATH=%SDK_ROOT%gdalplugins"
SET "PROJ_LIB=%SDK_ROOT%projlib"
SET "PYTHONPATH=%SDK_ROOT%python"

The first one is the regular GDAL folder (which I added to PATH), not sure what the second one is but I already set GDAL_DATA, GDAL_DRIVER_PATH and PROJ_LIB to these folders when I first installed GDAL while following the tutorial. There is no "GDAL\python" folder because I didn't install the Python bindings (Python is installed and in PATH). This .bat doesn't open a cmd window.

Maybe this GeoServer documentation can help https://docs.geoserver.org/latest/en/user/data/raster/gdal.html. I haven't tried it myself, though. I believe that many GeoServers are running with the GDAL extension successfully.

I already linked the same website in my first comment because it includes -Djava.library.path, which is supposed to fix the UnsatisfiedLinkError: no gdaljni error (it doesn't). I didn't try their suggestion to use the compiled binaries .zip because I don't want to run a server but that is the last thing I can think of at the moment, so I installed the MSVC 2022 version of 3.12.1 and unzipped the matching binaries directly into the main GDAL folder. The website mentions these:

set PATH=%PATH%;C:\<unzipped_package>\bin;C:\<unzipped_package>\bin\gdal\java
set GDAL_DRIVER_PATH=C:\<unzipped_package>\bin\gdal\plugins
set GDAL_DATA=C:\<unzipped_package>\bin\gdal-data

The binaries' SDKShell.bat however adds more and partially different folder baths:

SET "PATH=%SDK_ROOT%bin;%SDK_ROOT%bin\gdal\python\osgeo;%SDK_ROOT%bin\proj9\apps;%SDK_ROOT%bin\gdal\apps;%SDK_ROOT%bin\ms\apps;%SDK_ROOT%bin\gdal\csharp;%SDK_ROOT%bin\ms\csharp;%SDK_ROOT%bin\ms\java;%SDK_ROOT%bin\curl;%PATH%"
SET "GDAL_DATA=%SDK_ROOT%bin\gdal-data"
SET "GDAL_DRIVER_PATH=%SDK_ROOT%bin\gdal\plugins"
SET "PYTHONPATH=%SDK_ROOT%bin\gdal\python;%SDK_ROOT%bin\ms\python"
SET "PROJ_LIB=%SDK_ROOT%bin\proj9\SHARE"

I didn't add "python", "csharp", "curl" (doesn't even exist), the "ms" folders or the extra "proj9" and in the end I had (VERSION 2):
C:\Program Files\GDAL\bin
C:\Program Files\GDAL\bin\gdal\java
C:\Program Files\GDAL\bin\gdal\apps
in PATH, plus the binaries' versions of GDAL_DRIVER_PATH, GDAL_DATA and PROJ_LIB as environment variables.

While at least gdalinfo --version was working in a regular command prompt with the installed GDAL version (VERSION 1), it doesn't work with this (VERSION 2), instead there's a popup with an error:
The procedure entry point "" could not be located in the dynamic link library "C:\Program Files\GDAL\bin\gdal\apps\gdalinfo.exe".

I added the other paths to PATH too and restarted my PC but no change.

[Nathipha]

What are the minimum required and maximum supported Java versions for using the Java bindings?

I now uninstalled everything again, made sure to delete the GDAL folder, then downloaded only the 3.11.5 binaries (MSVC 2019, x64) from here and set them up as described here:

• Unzipped the archive into a non "Program Files" folder
• This time I didn't install the core.msi
• Added the "release-1929-x64-gdal-3-11-5-mapserver-8-4-1\bin" folder to PATH
• Set "GDAL_DRIVER_PATH" to "release-1929-x64-gdal-3-11-5-mapserver-8-4-1\bin\gdal\plugins"
• Copied the gdalalljni.dll file into the main "bin" folder (there was an error before I did that)
• Created a completely fresh project in Eclipse 2025: I only added the gdal-3.11.5.jar (no sources this time) and set the build path
• System.out.println(gdal.VersionInfo());

Again I got the same error:

Native library load failed.
java.lang.UnsatisfiedLinkError: C:\Program Files\GDAL\gdalalljni.dll: The specified procedure could not be found
Exception in thread "main" java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI.VersionInfo__SWIG_1()Ljava/lang/String;

If I also add "release-1929-x64-gdal-3-11-5-mapserver-8-4-1\bin\gdal\apps" to path, then calling gdalinfo --version in cmd lists an actual procedure entry point ("CPLTurnFailureIntoWarning") in its error popup.

[Nnnes]

I encountered the same error (java.lang.UnsatisfiedLinkError: C:\Program Files\GDAL\gdalalljni.dll: The specified procedure could not be found). In my case it was caused by gdalalljni.dll loading apparently incompatible versions of dependency DLLs from the wrong location; specifically, freexl.dll, geos.dll, geos_c.dll, and libxml2.dll were present in my PATH in an OSGeo4W\bin folder that had precedence over C:\Program Files\GDAL and the existence of any one of them was enough to cause the error when using GDAL 3.12.1. (When I tried the same thing with GDAL 3.10.0, it was the same issue but with a different set of DLLs; I didn't bother figuring out which.)

Possible user solutions (you should only have to do one of these):

• Move C:\Program Files\GDAL to the top of your system PATH (it takes precedence over the user PATH). Might break other programs if they have similar problems.
• Remove folders with conflicting DLLs from your PATH. Try where libxml2.dll etc. in Command Prompt to find them.
• Add a bunch of System.load("C:\Program Files\GDAL\[name].dll"); lines to your Java program before your gdal.AllRegister()/ogr.RegisterAll() to force Java to preload the correct DLLs. Order does matter; for example, geos_c.dll depends on geos.dll so you have to load geos.dll first. Dependencies can generate a dependency tree to help figure out the right order. Here's what worked for me as an example:

System.load("C:/Program Files/GDAL/freexl.dll");
System.load("C:/Program Files/GDAL/geos.dll");
System.load("C:/Program Files/GDAL/geos_c.dll");
System.load("C:/Program Files/GDAL/libxml2.dll");
gdal.AllRegister();
ogr.RegisterAll();

• Build your own gdalalljni.dll to use with the OSGeo4W binaries? Probably not worth the effort

I'm not sure how (or if) this should be addressed in this repo. Maybe there's some build option GISInternals could set.

[Nathipha]

@Nnnes
Thanks for the suggestions!

To be honest, I'd rather not mess with the order, just in case that breaks even more for some weird reason.

I checked the environment variables (I search for it using the search on Win 11's task bar) so many times and already removed anything that might cause any conflict last week. I never installed OSGeo4W and currently there's only stuff like Java, Python and a couple of other things that should not use GDAL (like Conda) left in the list. I don't understand how there could be a conflict.

I ran where gdalalljni.dll and it only found it in the GDAL folder. where gdal.dll found two locations (GDAL folder and LAStools) but only one of them is in PATH.

Is there a reason why you picked these dll files specifically? I tested it with the file it was complaining about, plus the gdal.dll but now it's throwing the same exception for the latter:

System.load("C:\\Program Files\\GDAL\\gdal.dll");
System.load("C:\\Program Files\\GDAL\\gdalalljni.dll");

I also tested your four files but now the exception is back to complaining about gdalalljni.dll.

[Nnnes]

The Java errors don't give very useful information. I did the equivalent of deleting all the DLLs from the OSGeo4W folder and restoring them one by one to see which ones were interfering.

where gdal.dll found two locations (GDAL folder and LAStools) but only one of them is in PATH.

where is only supposed to find things that are in your PATH. I successfully reproduced the error by adding a LAStools/bin folder to my PATH and then fixed it two different ways, first with System.load("C:/Program Files/GDAL/tiff.dll"); and second by deleting tiff.dll from the LAStools folder. Can't say for sure what's happening on your end.

[Nathipha]

Looks like it's a Windows 11 bug:

I ran the set command in command prompt and that one did show the LAStools entry.
Searching for "environment variables" in Win 11's search on the task bar to open the "System Properties" window, then clicking the button in the bottom right corner opens the list with user variables and system variables and in the PATH there that entry did not exist (because I deleted it last week)! I had to add it again, then delete it and now it's actually gone and GDAL is working is expected. Wtf...