wired dll locating problem

[tuli]

I encounter a wired problem when dynamically loading a .dll file under windows xp sp3.


dll.cpp

#include <windows.h>

BOOL APIENTRY DllMain( HANDLE hModule,
					  DWORD  ul_reason_for_call,
					  LPVOID lpReserved )
{
	return TRUE;
}

caller.cpp

int main(int argc, char *argv[])
{
	HMODULE h = LoadLibraryA("c:\\x.dll");
	DWORD gla = GetLastError();
}

when i compile dll.cpp with visual studio 2008, copy the resulting .dll file to c:\\x.dll and step over caller.cpp in VS, h has the base address of the dll and gla is zero.
when i compile dll.cpp with g++ (mingw), copy the resulting .dll file to c:\\x.dll and step over caller.cpp in VS, h is zero and gla is 0x7E.

g++ -shared dll.cpp -o x.dll

ERROR_MOD_NOT_FOUND
    126 (0x7E)
    The specified module could not be found.

Great.

But get this: if i run caller.exe outside of VS, it works just fine IN BOTH CASES!


What wired black magic is going on here?

[VictorN]

But get this: if i run caller.exe outside of VS, it works just fine IN BOTH CASES!
What wired black magic is going on here?

And why would it NOT work "IN BOTH CASES"?
Your code does "work" since it does nothing after trying to LoadLibrary!

[tuli]

by "does work" i imply the library loaded correctly - i modified caller.cpp to dump h and gla to a file. Guess i should have mentioned that.


My best bet is that somehow the init routine (DllMain) doesnt return TRUE with g++ ... and VS somehow takes offense...Though it is beyond me what the problem may be.

I continue to appreciate any input.

[Alex F]

"The specified module could not be found" - this may apply to x.dll or one of its dependencies. How exactly do you run caller.exe outside of VS? Maybe from MinGW command line, in this case x.dll is able to find all its dependencies.

[Paul McKenzie]

by "does work" i imply the library loaded correctly - i modified caller.cpp to dump h and gla to a file. Guess i should have mentioned that.


My best bet is that somehow the init routine (DllMain) doesnt return TRUE with g++ ... and VS somehow takes offense...Though it is beyond me what the problem may be.

I continue to appreciate any input.

Why not place a breakpoint or output a message in the DllMain() function? Then there is no need to guess what is happening when you call LoadLibrary. Just to warn you -- do not put calls to MessageBox() or similar calls to debug DllMain -- actually use the debugger, or use OutputDebugString() to display messages.

In addition, use a tool such as DependencyWalker to see exactly what the difference is between the two DLL's in terms of the dependencies. Both DLLs should theoretically be exactly the same as far as what other modules the DLL is dependent on.

Regards,

Paul McKenzie

[tuli]

You guys were right: the problem was with dependencies.


Apparently MinGW was silently updated, adding an additional sub-sub-dependency. I checked for that but somhow missed it. Sorry about that and thanks for your time!