I’m discovering just how many errors and problems masquerade as “function not found” errors
I’m working on a windows 64bit app declaring a function in an external library.
*** it works fine for compiling as a Windows 32bit app ***
So, I’ve looked at:
- the version of the library, I’ve confirmed that I’m using the 64bit version (at least as supplied)
- the calling convention, thinking 32bit integers vs 64bit integers, etc but then I tried:
- the location of the library. things might be different under 64bit, so I move the library to the root folder of the app, but then I think
- is it finding the library at all? I remove the library entirely and get the same error
So where to go from here? Don’t forget that it all worked fine in 32bit. The parameters to be sent & returned are all explicitly Int32-type stuff and all docs suggest nothing about any 64bit differences with the library… help…
aer you sure its not a 32 bit DLL ?
a 64 bit app wont load a 32 bit DLL and a 32 bit one obviously cannot load a 64 bit one
And that will give you errors like function not found becuase the dll isnt open or loaded
EDIT : is there a command on Windows that WILL tell you if it is / is not a 32/64 bit dll ?
there seem to be a couple ways mentioned on this https://stackoverflow.com/questions/495244/how-can-i-test-a-windows-dll-file-to-determine-if-it-is-32-bit-or-64-bit
Assuming it’s not 32 vs 64 bit mismatch, try dumping a list of the DLL’s exported functions using a tool like DLL Export Viewer. This will let you see all the functions in the DLL and their true names.
Thanks Norman and Andrew for your replies
First, yes, it appears to be a 64bit DLL. I downloaded Dependency Walker and it claims the DLL is 64bit
Second, I used the DLL Export Viewer and it states the function name I’m using is correct
So I’m still at a loss. I expect the “function not found” error is in response to something returned from the OS but it’s a pain that I can’t tell the difference between a DLL being unavailable or using the wrong function name or…
any other ideas?
when you debug quite literally WHERE is the DLL relative to the EXE being built for debugging ?
how do you get it there ?
maybe its not there at the right time (if you copy it manually after starting to debug or something ?)
what does your declare look like ?
You CAN - just then you dont use a declare as it doesnt tell you this
If you resorted to the lower level Windows API’s for loading a library and getting access to its entry points that could tell you all these details
Declares dont - they spare you the gorey details (but also hide some things as you’ve seen)
edit : added this feature request feedback://showreport?report_id=59262
at first it was in a libs subfolder, then I tried putting it right beside the executable
copied via build automation
It should be fine as it’s a soft declare and it’s not required until I interact with the app’s UI after launch.
Also, don’t forget that this all works fine for 32bit compile (and is shipping today) - so most of the fiddly things that could happen have likely been solved
soft declare Function theFunction lib "theLib.dll" ( theList as ptr, byref foundCount as UInt32, listLength as ptr ) as Int32
That’s a good idea:
Declare Function LoadLibraryW Lib “Kernel32” (LibName As WString) As Ptr
Declare Function GetProcAddress Lib “Kernel32” (hModule As Ptr, ProcName As CString) As Ptr
Dim library As Ptr = LoadLibraryW(“MyLib.dll”)
If library = Nil Then MessageBox(“DLL not found”)
Dim procedure As Ptr = GetProcAddress(library, “MyFunctionName”)
If procedure = Nil Then MessageBox(“Function not found”)[/code]
Thanks Andrew, that was useful
Unfortunately I got “DLL not found” no matter what I tried.
I ensured that the DLL was in the same folder as the executable and that it was properly named in the LoadLibraryW call
I reviewed it again with the Dependency Walker utility and found the following errors:
Error: At least one required implicit or forwarded dependency was not found.
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
There are about 12 dlls that make up this library but I did confirm that the function I’m attempting to call is within the dll file I reference in the LoadLibraryW call
So, I tried an earlier version of the manufacturer’s library to see if it was a bad build or something… no dice (same errors in Dependency Walker as well)
I should mention that I can successfully call a dll from a different manufacturer, so it would appear I’m doing something correctly…
Also, do recall that this all works when compiling for 32bits with the 32bit set of dlls that are supplied
These problem dlls are included with working sample C++ code (they claim, I did not compile it myself) and a working build of their demo app…
It sounds like the interdependencies are flummoxing the loading of the library… any ideas?
What does GetLastError return after the failed LoadLibraryW?
ha! I was just looking into that.
It returned 126, which is
The specified module could not be found.
Which sounds like it could be useful and yet sounds about as generic as the error message from Xojo - I can’t tell if it’s referring to the DLL or something internal…
do they also provide all the dependent dll’s ?
if so make sure those are all next to the built exe a well
would seem those errors indicate that the system cannot locate those
You might have a missing 64bit runtime library that the dll depends on, check where you got the app/dll from to see if they have a pre-requisite for the 64bit version of the app/dll, try it after installing the 64bit version of that. Failing that see the following on how to deubg the load failure:
which is the last link on https://devblogs.microsoft.com/oldnewthing/20131127-00/?p=2553
[quote=476241:@Norman Palardy]do they also provide all the dependent dll’s ?
if so make sure those are all next to the built exe a well [/quote]
they seem to provide them (and I locate them all in the same place - beside the exe)
it’s the same group of DLLs (by name at least) supplied with the 32bit set, that all load fine (not to beat a dead horse, just trying to provide A/B comparison info)
In the Dependency Walker utility there’s a long list of DLLs listed (and I mean VERY long - about 500 items), each of which has “Error opening file. The system cannot find the file specified (2)”
These look like OS-level libraries yes?
Dunno what version of Windows you’re on but do you have the c runtime installed ? (If you’re on Windows 8 or newer then you do) I’m pretty sure only Windows 7 needs this installed
I’ve been reading the links that Julian suggested as well as I did a search on the first DLL in the list “API-MS-WIN-CORE-APIQUERY-L1-1-0.DLL” and found some interesting bits:
Dependency Walker utility is old and doesn’t handle the levels of call indirection occurring today
Dependencies does a better job - but also required a Visual C++ redistributable packages download and installation
Dependencies definitely produced a smaller report that called out:
C:\\Windows\\system32\\WSOCK32.dll as having "missing imports"
VCOMP110.DLL as missing entirely
Norman, we’re testing this on Windows 10 64bit
OK that means the C runtime is already installed (Win 10 has it and updates it as part of OS updates)
That’s it Julian. Once the VS2012 redistributable was installed things started working. The dlls all have to be at the exe level, but they work now.
Thanks guys for sticking with this until solved. Living in Xojo land giveth and it maketh tougher sometimes too!
ah an old version of VS
didnt think of that one
I’d just linked the 2015 - 2019 versions