C++: Our installer refuses to load our application's resources DLL (module not found) [XP only]

Question

Basically, when our software runs under Windows 7, it works: the call to LoadLibrary() succeeds, and life is good.

But when the same software is run on an XP box (latest patches), the call to LoadLibrary fails, returning NULL, with an error code that specifies module not found.

I have tried forcing it to use the UNICODE version LoadLibraryW instead of the LoadLibraryA version for our app.

I have tried making sure that the install folders are mapped through a local drive letter.

And I've verified the pathname is in fact accessible from the executing machine (i.e. the error produced indicates what path it is trying to load, and I use that string to actually find the file).

The weird thing is that this code runs correctly when compiled on VS 2008 SP2.

It also works fine when the client machine is Windows 7.

It only fails if it is compiled + linked by VS 2010 and if it run on an XP client.

I'm at a total loss as to what in the world could be going wrong.

To add weirdness to the stew:

If I fire up my XP VM on my development box and run this code in debug build in VS2010 under XP, it works correctly!

In fact, under my XP VM, the standard (release) build also runs correctly!!!

It's just when run from a true XP box that it fails (I've tried a couple of XP machines so far, both fully patched).

Any thoughts?!
I'm beginning to run out of credible ideas. :(

Answer 1

I would examine differences between your toolset and platform combinations.

For example the VS2008 vs VS2010 distinction is less important than what SDK you're using. Different SDKs could be targeting different msvc runtime libraries.

Is it possible you have the VS2010 runtime library installed on your XP VM and not the other XP platform?

You might also try the 'depends' utility on the non-working platform to determine missing dependencies.

Answer 2

You said you've made sure that the pathname is accessible ... have you tried adding the dll's directory to the PATH environment variable just to see if that works? That way you can confirm it's just failing to locate and try to sort out the problem from there.

I recently just went through this problem on my own project. I even tried specifying a full filepath to LoadLibraryA and it returned that error code. The problem was a search path issue with LoadLibrary trying to find dependancy DLL's of the DLL I was loading. So perhaps your resource DLL also has some DLLs that LoadLibrary doesn't know how to get to.

Answer 3

Another common problem is when you load "a.dll", which has a dependency on "b.dll". If there's a problem with "b.dll" you'll sometimes get a failure indicating it can't load "a.dll". Which is true but not helpful.

There are several applications that can tell you the dependencies of a dll.