Click here to Skip to main content
15,920,708 members
Please Sign up or sign in to vote.
3.00/5 (2 votes)
See more:
I tried to load a C++ DLL from a C++ application using LoadLibrary.

I gave it the full path but it couldn't find the DLL (and obviously, the DLL is found where I said it is if a person looks for it using Windows Explorer).

Eventually, the only way I got my application to find the said DLL was to put the application in the same folder as the DLL.

<Rhetorical>
So what's the point of writing the full path then!?
</Rhetorical>

How can this happen, and what can I do to solve this problem?
I really would rather not have to put the application in the same folder as the DLL.


[PS]
Also, COM DLLs in the same folder as the DLL in question cannot find the DLL either.
I suppose the COM doesn't have a strong enough idea as to where it is located with respect to other modules.

[PPS]
...
HMODULE hmDLL = LoadLibrary(_T("C:\\MyPath\\MyDLL.dll"));
DWORD dwError = 0;
if(NULL == hmDLL)
{
	dwError = GetLastError();
}
// break here and inspect dwError
// -> find out dwError = 0x7e
...
Posted
Updated 9-Dec-21 10:29am
v4
Comments
Albert Holguin 19-Jan-12 23:11pm    
Does it work when it's in the same directory as the exe?

After reading the first 4 solutions, here's some information to help you...it has to do with the DLL Search Path [^].

As the article says, the typical search order is
1.The directory from which the application loaded.
2.The current directory. 
3.The system directory. Use the GetSystemDirectory function to get the path of this directory. 
4.The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
5.The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6.The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

So, as you see, it looks in the app directory first, and in your case, didn't find it. Then it looks in the current directory - but still didn't find it, and so on.

Since you gave the full path, it probably found your NAMED DLL, but couldn't find the dependency DLLs becuase if follows the DLL Search algorithm.

However, if you put your EXE in the DLL directory (not generally a good idea) it finds your DLL and all the dependencies (becuse the directory from which the app loaded contains all the needed DLLs).

If you put your dll in the app directory, it finds it, but not the dependent DLLs.

Hope this helps you - be sure to read the entire article.
 
Share this answer
 
Comments
Stefan_Lang 23-Jan-12 5:21am    
Very useful link and explanation. My 5.
The LoadLibrary API succeeds when the DllMain function in the DLL returns TRUE.
So, it looks like the DllMain function is not returning TRUE.
This could be because some module that the DLL needs is not found.
You can debug the DLL and find out what is going wrong.
Or you can use dependency viewer on the DLL to check if it is missing any modules that it needs.
 
Share this answer
 
Comments
PaulowniaK 20-Jan-12 0:16am    
Thanks for the suggestion.
I hadn't thought about DLLMain till now.
It appears there isn't an explicit DLLMain (unless I'm looking for it in the wrong place), so that could cause LoadLibrary to return FALSE.

However, in that case, how would you explain the fact that LoadLibrary works when I
1) copy the EXE to the DLL directory or
2) copy the DLL and all the dependencies to the EXE directory?

(Please also see my replies to other contributors above.)
«_Superman_» 20-Jan-12 0:24am    
It could be a permission issue.
Try moving the DLL to another path like D:\Temp and try again.
Lakamraju Raghuram 20-Jan-12 0:23am    
Specifying DLLMain is optional. But you can specify one and check if the DLL is attaching/loading.
All I needed to do was change the current directory using SetCurrentDirectory.

(And put things back at the end of the function just in case by getting the original directory using GetCurrentDirectory right at the start and calling SetCurrentDirectory again.)

My test application was in one directory and all the DLLs were in a different directory. Although I used the full path to the DLL I needed, any DLLs it depended on could not be found as I didn't (couldn't) supply absolute full paths to those DLLs.

Changing the current directory of the application is one way, but I wonder if whoever built the DLL could have done it a different way so as to not lose track of all the DLLs it depended on?

Anyway, many thanks to hints and suggestions.
 
Share this answer
 
Comments
JackDingler 20-Jan-12 12:00pm    
The SE who wrote the DLL had no way of knowing what path you might copy the DLLs to.
PaulowniaK 22-Jan-12 23:29pm    
Umm.. that's not entirely true... The DLLs are where they were designed to go.
What the original SE didn't know about is where my test App will live. Don't know if that changes anything though...?
JackDingler 23-Jan-12 1:10am    
Not really.

It's not uncommon to change the location of 3rd Party DLLs.
PaulowniaK 23-Jan-12 2:16am    
I think I'm with you...

Although, in this case, it's a "first party DLL" if there is such a word...
Typically, DLLs are linked statically, and in that mode, no path is recorded, just the name of the file. the path searched is determined by windows and primarily by the PATH environment variable.

You might try updating the PATH environment variable, by inserting the path for the DLLs, before calling LoadLibrary(). The environment variables are cached per process, so you won't be effecting system wide changes when you do this.

See the following article for a description of how DLLs are located.
Dynamic-Link Library Search Order
 
Share this answer
 
Of course you need a full path unless the DLL to be loaded is located in the working directory at the moment of calling. We have no idea where did you screw up things. It could be anything: wring file name, insufficient privilege… At least you could provide exception dump, your code sample, etc.

Anyway, the purpose of the full path is so apparent. Without it, how the system would be able to locate the DLL file? And what if you had two or more files with the same file name in different locations — which one to load. Your post sounds like you are not following simple logic, inferring a paradoxical conclusion: logic is wrong. :-)

—SA
 
Share this answer
 
Comments
PaulowniaK 19-Jan-12 21:59pm    
Thanks for your comment, but you may wish to look up the phrase "rhetorical question"...

Anyway...

LoadLibrary returns an empty handle.
Subsequent GetLastError returns 0x7e which means the module is not found.

I have had multiple people check the path and it's correct.
Can't quite see access rites being a problem (especially as I'm on XP).

Still stuck...
Satheesh1546 19-Jan-12 22:08pm    
Copy the dll to the current directory and try again..
PaulowniaK 20-Jan-12 0:06am    
Thanks for your suggestion.
I copied the DLL in question to my EXE directory.
Then checked it using the Dependency Walker (as suggested by Lakamraju Raghuram below) and worked out the missing DLLs.
I copied all the DLLs listed as missing in the Dependency Walker to the EXE directory.
I made sure there were no more missing DLLs identified by the Dependency Walker (except for MSJava and MSVCR80D).
And guess what, it worked!
What I don't get is, I copied over all the necessary DLLs from the same place. It's not like there were any DLLs missing in the first place...???
Lakamraju Raghuram 19-Jan-12 22:28pm    
Open that DLL in Depends.Exe (or any DLL walker) and check if all it's dependencies are available !!!
PaulowniaK 20-Jan-12 0:10am    
Thanks for the suggestion.
I had used Dependency Walker a few times in this investigation.

While the DLL in question was in its original location, the only things the Dependency Walker complains about are MSJava and MSVCR80D, which I believe is not a big deal.

Also, from what I've observed, I don't think it's a matter of missing dependencies. If that was the case, I shouldn't be able to load the DLL even when I copy the EXE to the DLL directory.

(Please see my reply to Satheesh1546 above as well.)
Encountered the same issue, solved by copying the dll to the location that .exe exists
 
Share this answer
 
Comments
Richard Deeming 10-Dec-21 5:02am    
As already mentioned in the accepted solution, posted almost ten years ago. You have added nothing to the discussion.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900