Entry Point Not Found error - C runtime library/.NET version?

[Chris35Wills]

Hello,

I've installed TauDEM as per the instructions on Windows 10 by using the TauDEM installer as well as Microsoft MPI (v8.1). I can access Taudem via the command line and can also add the toolbox in Arc. On running a command following the instructions from here using my own DEM (which is a valid GeoTiff) as per:

mpiexec -n 8 PitRemove -z ./ny_crop.tif -fel ./ny_crop_fel.tif

I am receiving an error stating:

PitRemove.exe – Entry Point Not Found

The procedure entry point sqlite3_create_function_v2 could not be located in the dynamic link library     C:\Program Files\GDAL\spatialite.dll.

My installation has the following added to my path - as added by the TauDEM and MPI installers:

C:\Program Files\Microsoft MPI\Bin\
C:\GDAL
C:\Program Files\GDAL
C:\Program Files\TauDEM\TauDEM5Exe

The sptiallite.dll is located as in the error message at C:\Program Files\GDAL\spatialite.dll

I am wondering if the Entry Point error may be linked to the C runtime library or .NET version I have - which versions were used/tested with TauDEM? I wonder if there is a version incompatibility at my end.

[pkdash]

It is probably linked to the C++ runtime library. Have you installed Visual Studio 2017? What do you see when you look at the list of installed programs in terms of Microsoft Visual C++ library?

[Chris35Wills]

Looking at what is installed I have various versions on my machine: 2005, 2008, 2010, 2012, 2013, 2017 - I can't imagine it is good practice to have so many versions installed! Should the most up to date be set as an environment variable?

[pkdash]

For some reason 2015 is missing in your installation which TauDEM should have installed.

[Chris35Wills]

I uninstalled the 2017 version and uninstalled TauDem, then re-ran the installer which this time also installed the 2015 version. Even after a reboot, I'm still getting the same Entry Point error. I also checked for any 2015 version updates (e.g. https://www.microsoft.com/en-us/download/details.aspx?id=53587) which I installed but still no luck...

[pkdash]

Would like to see the version of GDAL that got installed by TauDEM. In the list of installed programs what do you see in terms of gdal?

[Chris35Wills]

I find the following installed after running the TauDEM installer:

GDAL 201 (MSVC 2013 Win64) (typical installation run) Python 2.7 GDAL-2.10 Microsoft MPI 8.1.12438.1084

[pkdash]

GDAL installation seems correct. @dtarb may have be able to help.

[dtarb]

My suggestions are somewhat uncertain. Do you have access to a machine without so many prior visual studio installations. A clean virtual machine with fresh installation of Windows would be ideal. Then install TauDEM there to confirm that it works for your data. Then use whatever dependency tracking tools you can find to see if you can track down differences between a working installation and the one on your computer. This can be painstaking, but I do not know what else to suggest.

It does not seem likely from the error messages, but you should double check the following

1. Try run without the ./ prior to the file names, i.e. mpiexec -n 8 PitRemove -z ny_crop.tif -fel ny_crop_fel.tif The files addressed should be the same but there is a possibility that something related to this is fouling up.
2. Try run with some of the test data from the TauDEM website. This would rule out a problem with your data perhaps in terms of file type or size.

[Chris35Wills]

@dtarb - thanks for your suggestions. I now have a VM set-up - unfortunately I'm getting the same issues. I've run Dependency Walker to look into the contents of spatialite.dll at its location in Program Files, which is mentioned in my entry point error. The output of the analysis is available here. Can you see anything which gives an indication as to what is going on?

[dtarb]

I am a bit stumped. To be clear, you are unable to run any TauDEM function even with test data from my website (to rule out a data file problem).

I do not know how to interpret the output very well. I can see indication of many modules not found, but these all seem to be 32 or 64 bit system modules and I do not know what is causing this.

The TauDEM installer was supposed to add some path entries. Check for C:\Program Files\Microsoft MPI\Bin\ C:\Program Files\TauDEM\TauDEM5Exe C:\Program Files\GDAL C:\GDAL

If these are not there it may indicate that the installer did not set the right (possibly because of not having admin permissions). You could run the installer as an admin to resolve this.

If these are there, there is a possibility that another component on the path has a different and incompatible version of a dll before one of the GDAL ones. Moving GDAL earlier in the path may help. You might also try change the order of the path entries.

There must be a difference between the Win10 platform you are testing on and those I have tested on. I am not sure if we tested on all combinations of 32 bit and 64 bit Windows 10 with and without ArcGIS so there could be (IS) something in our test environment from yours. I do not have time right now to set up a clean test environment, but will do so as soon as I can. Hopefully the above pointers and path information gives you something to go on tracking this down.

[Chris35Wills]

Yes, I am unable to run any TauDEM function using the logan test data. I have tried the following commands (as per the command line user guide) within the local directory of the downloaded data:

mpiexec -n 8 PitRemove logan.tif

Trying other functions also results in the same "procedure entry point sqlite3_create_function_v2 could not be found..." error. I've reordered my path variable to the following (ensuring it contains the paths set-uop by the installer) and still no success:

PATH=C:\Program Files\Microsoft MPI\Bin\;C:\Oracle\32bit\product\11.2.0\client_1\bin;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Novell\ZENworks\bin;C:\Program Files\TauDEM\TauDEM5Exe;C:\Program Files\GDAL;C:\GDAL;C:\Users\chrwil\AppData\Local\Microsoft\WindowsApps;

I also tried bringing the GDAL path declaration forwards but still no luck. I'll keep playing around with it to see if I can get it running. Thanks for your comments up to now.

[GinaONeil]

Hi, I was going to ask about pretty much the exact same issue. I am also using TauDEM on Windows 10 and was getting the entry point not found error for any TauDEM command. Additionally, I was getting the 000732 error when using the TauDEM arcgis toolbox. I _also had many versions of the Microsoft Visual C++ library. I followed along with the steps listed here and still no luck.

Finally, tried moving around the order of the path env variables, as suggested here a couple of days ago. I moved C:\Program Files\GDAL to the top of the path env variables list and this looks like it did the trick. Command line and arcgis functions are now working. Maybe this will work for you as well

[dtarb]

@Chris35Wills going on a hunch try temporarily delete the Oracle entry C:\Oracle\32bit... entry from the path. I do not have anything Oracle related on my computer and Oracle being a database company, it would not surprise me if they use a library that may conflict with the library GDAL uses for SQLite files.

[Chris35Wills]

@dtarb and @GinaONeil I have played around with the system variables again and adapted my system path (rather than my user path) - bringing C:\Program Files\GDAL to the top of my system path has fixed the issue. Success! Thanks for all of your help and comments.

To double check that this wasn't Oracle related, with my original path (where C:\Program Files\GDAL wasn't at the top), I deleted the Oracle entry C:\Oracle\32bit but still TauDEM didn't work.

So to reiterate - problem solved by bringing C:\Program Files\GDAL to the top of my system path

[speedy250]

Thank you @GinaONeil !! (& @Chris35Wills) Solved an unrelated issue for me.

If anyone is searching for fixes to the procedure entry point sqlite3 [...] could not be located in the dynamic link library errors while installing PostGIS, GeoDjango, GDAL libs, on Python 3x, changing the PATH order by sending python and OSGeoW locations to the top of the PATH fixed the problem for me.