Can't find DLL in search path
ImageAnalyst
but when it comes time to call the function in the DLL it throws an
error "File not found: pgOverlay.dll"
I've put that DLL in the app's folder (where the source code, the exe,
and all the rest of the project files are), in the \Windows\system32
folder, in the \Windows\system folder, and in the \Windows folder. It
didn't matter where I put it, it wasn't found in any of those places.
Here's how it's declared in the vb bas module:
Declare Function pgovlCreateOverlayFile Lib "pgOverlay.dll" (ByVal
sFilename As String) As Long
Also, just to make sure that the function is in the DLL with the right
name and arguments, I checked it with Dependency Walker and the
function is in the DLL and I'm calling it correctly. (Besides the
error was about the DLL file not being found, not about some kind of
calling/argument error.)
Note there's no path hard coded into the declaration. I'm using
Windows Xp.
Any idea why it's not finding it in the folders that it's supposed to
be looking in?
Where the heck is it searching for it?
Ralph
> My VB6 app uses a custom written dll. The app runs (launches) fine
> but when it comes time to call the function in the DLL it throws an
> error "File not found: pgOverlay.dll"
>
>
> be looking in?
> Where the heck is it searching for it?
In the case where you have checked the obvious, then it is likely it is not
"pgOverlay.dll" that the Windows Loader can't find, but rather some
component pgOverlay is dependent on that can't be found.
-ralph
ImageAnalyst
missing.
Ralph
> But wouldn't this be revealed by dependency walker? It showed nothing
> missing.
Yes, usually.
Occasionally, runtimes don't show up in Dependancy Walker. What language /
development tool was the Dll written in?
We are talking about a 'standard' DLL here, correct?
If it is an ActiveX Dll then it has to be registered, and accessed by early
binding or automation, ie, you don't use the Declare functions.
-ralph
ImageAnalyst
I did manage to find the source code (it's not mine - I didn't write
it). It's written in C++. It does call some ActiveX DLL's from a
third party package, which I have and which are registered. When I
try to register this pgOverlay.dll, it says "pgOverlay.dll was loaded,
but the DllRegisterServer entry point was not found. This file can
not be registered." As I understand it, not all DLL's NEED to be
registered, although some can be (though I'm not sure why this is
unless it's just to find things that aren't anywhere in the search
order).
I'm going to try to hard code the path to this DLL in the ...\Release
folder and see if that works, just as a test to see if it runs - I
don't want to leave the path hard coded in there permanently. I'll
post back....
ImageAnalyst
ImageAnalyst
I had to put the pgOverlay.dll file in the folder where the ActiveX
DLL's that it calls live. And I had to hard code the path to that
folder into the declare statement even though that folder was on the
PATH envinronment variable. I guess I can live with putting the
pgOverlay.dll into that folder but I hoping to not have the folder
hard coded into the declare statement. But if I take out that path I
get the same error about it not finding the DLL. Any explanation for
that, or how I can remove the hard coded path (since I'm not sure my
end users installed the Aphelion ActiveX DLL's in the same folder name
that I did)?
Thanks,
ImageAnalyst
What I have so far:
'--------------------------------------------------------------------------------------------------------------
' Declare the pgOverlay functions that are contained in the
pgOverlay.DLL file.
' It seems that if the pgOverlay file does not reside in the same
folder as the
' Aphelion ActiveX DLL's, then it can't find pgOverlay.DLL,
' even if pgOverlay.DLL is in one of the folders on the normal search
order (folders that Windows looks in to find it).
' If pgOverlay is not in the Aphelion/Program folder, then even hard
coding the full path to pgOverlay.DLL won't help it work
' Note: "C:\PROGRA~1\Aphelion\Program" is in the PATH Environment
variable.
' This DOES NOT work, even if pgOverlay.dll is in the Aphelion\Program
folder which is in the PATH Environment Variable
' and where the Aphelion ActiveX DLLs are.
Declare Function pgovlCloseOverlayFile Lib "pgOverlay.dll" (ByVal
lngFilePointer As Long) As Long
Declare Function pgovlCreateOverlayFile Lib "pgOverlay.dll" (ByVal
sFilename As String) As Long
' This DOES work, as long as pgOverlay resides in the folder "c:
\program files\Aphelion\Program"
' which is where the Aphelion ActiveX DLL's live.
'Declare Function pgovlCloseOverlayFile Lib "c:\program files\Aphelion
\Program\pgOverlay.dll" (ByVal lngFilePointer As Long) As Long
'Declare Function pgovlCreateOverlayFile Lib "c:\program files\Aphelion
\Program\pgOverlay.dll" (ByVal sFilename As String) As Long
Ralph
> Well I did get it to work (but not in the way I had hoped).
> I had to put the pgOverlay.dll file in the folder where the ActiveX
> DLL's that it calls live. And I had to hard code the path to that
> folder into the declare statement even though that folder was on the
> PATH envinronment variable. I guess I can live with putting the
> pgOverlay.dll into that folder but I hoping to not have the folder
> hard coded into the declare statement. But if I take out that path I
> get the same error about it not finding the DLL. Any explanation for
> that, or how I can remove the hard coded path (since I'm not sure my
> end users installed the Aphelion ActiveX DLL's in the same folder name
> that I did)?
> Thanks,
> ImageAnalyst
>
>
> What I have so far:
>
Which I'm glad to see. Just wrote a wordy reply that contained mostly items
which we can now eliminate. <g>
Found a reference to this being a problem if the system %PATH% variable is
too long, however, it appears to be O/S specfic and repaired. For grins why
not move the Aphelian folder up close to the front of the PATH EnvVar
string.
Make sure you have only one copy of "pgOverlay.dll" on the box. Temporarily
rename the others, as the search routine will bail on the first one if
finds. It appears that it is not actually "pgOverlay.dll" that is the
problem, but finding the components it depends on after you find it.
Warning Exotic Possiblity and Air Code follow... <g>
Since Vista, various security changes in the O/S, (and new C++ compiler
options are availble) to prevent a DLL being called outside of certain
contexts.
What other environments or applications is this DLL used for?
For grins create a simple VB Exe and use the WinAPI to test.
Private Declare Function GetModuleHandle Lib "kernel32" Alias
"GetModuleHandleA" _
(ByVal lpModuleName As String) As Long
Private Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" _
(ByVal lpLibFileName As String) As Long
Private Declare Function GetProcAddress Lib "kernel32" _
(ByValhModule As Long, ByVal lpProcName As String) As Long
Private Declare Function FreeLibrary Lib "kernel32" _
(ByVal hLibModule As Long) As Long
Public Function IsExported(ByVal ModuleName As _String, _
ByVal ProcName As String) As Boolean
Dim hModule As Long
Dim lpProc As Long
Dim FreeLib As Boolean
' check to see if module is already loaded
hModule = GetModuleHandle(ModuleName)
If hModule = 0 Then
hModule = LoadLibrary(ModuleName)
FreeLib = True
End If
' check to verify it's exported.
If hModule Then
lpProc = GetProcAddress(hModule, ProcName)
Exported = (lpProc <> 0)
End If
' unload library if we loaded it here.
If FreeLib Then Call FreeLibrary(hModule)
End Function
This will use the LoadLibrary process directly thus generally removing any
subtle nuances the VB Declare Function statement might have on a new O/S.
Plus if you cannot get around using a fullpath with the VB statement, this
process will allow you to access the library/functions building a dynamic
path at runtime. It will be easier if you also create a typelib for the Dll.
-ralph
ImageAnalyst
Thanks for much for your help. It's working now. I still had a
version of the pgOverlay.dll in the Windows folder and when I didn't
have the full name in the "Declare" statement it apparently was using
that instead of the version in the Aphelion\program folder (because
Windows is earlier in the PATH environment variable and search
order). Now, I know from before (thankfully due to your hint) that my
VB6 app must use the pgOverlay.dll in the Aphelion/program folder
because that is where the dependent activeX DLLs live. So once I got
rid of the version in the Windows folder (which is earlier in the path
than the Aphelion\program folder) then it was now using the proper DLL
in the proper location (the Aphelion/program folder) and it all worked
fine.
I'm still not exactly sure why my DLL had to live where the dependent
ActiveX DLL's live (because those DLLs' folder was on the path), but
hey, as long as it's working...
Thanks again for taking the time to help me with this!
P.S. The path was very lengthy - maybe around 400 characters or more:
C:\Program Files\Notes5;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%
\System32\Wbem;%SystemRoot%\system32\nls;%SystemRoot%\system32\nls
\ENGLISH;c:\program files\ixos\ixos ecd viewer\bin;C:\Program Files
\Hewlett-Packard\OpenView\service desk 4.5\client\bin;C:\Program Files
\MATLAB\R2009b\runtime\win32;C:\Program Files\MATLAB\R2010a\runtime
\win32;C:\Program Files\MATLAB\R2010a\bin;C:\Program Files\MATLAB
\R2009b\bin;C:\Program Files\Common Files\Adobe\AGL;C:\Program Files
\TortoiseSVN\bin;C:\Program Files\Microsoft SQL Server\90\Tools\binn
\;C:\Program Files\QuickTime\QTSystem\;C:\PROGRA~1\Aphelion\Program
I guess it needs cleaning - I don't even use Notes anymore for email -
it's been uninstalled! I'm using Windows XP. Is there are limit to
the length of the PATH environment variable in WinXP?