[solved]LoadLibrary unable to load a library even when given a full path

Question

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 19-Jan-12 15:22pm

PaulowniaK

Updated 9-Dec-21 10:29am

v4

Add a Solution

Comments

Albert Holguin 19-Jan-12 23:11pm

Does it work when it's in the same directory as the exe?

6 solutions

Solution 2

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.

Posted 19-Jan-12 18:09pm

«_Superman_»

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.

Solution 3

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.

Posted 19-Jan-12 21:21pm

PaulowniaK

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...

Solution 4

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

Posted 20-Jan-12 5:46am

JackDingler

Solution 1

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

Posted 19-Jan-12 15:50pm

Sergey Alexandrovich Kryukov

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.)

Solution 6

Encountered the same issue, solved by copying the dll to the location that .exe exists

Posted 9-Dec-21 10:29am

Myelin Sheath

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.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

krmed · Accepted Answer · 2012-01-20T07:34:00

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.

[solved]LoadLibrary unable to load a library even when given a full path

6 solutions

Solution 5

Solution 2

Solution 3

Solution 4

Solution 1

Solution 6

Add your solution here

Preview 0

Existing Members

...or Join us