AfXLoadLibrary fails GetLastError returns 127

my guess is that the 3rd party dll is younger (than the one used when your static library was build) and the prototype of the function searched does no longer fit or the function has been removed. you may compare the versions of the 3rd library dll at the build system and at the system where it doesn't work.

if these are different, you have two choices. either copy the older dll to the folder where your application exe resides. doing so, the LoadLibrary would use this dll rather than a newer version installed. or you try to find out what the newer interface is like and update your library function accordingly. the second way would be much better as with the first it could fail if the dll was registered in windows registry and the entries there do not work with the old dll. another fail is possible if the new dll was used by another program and therefore was already loaded while your program tries to load it.

Sara

The dll is a driver from a 3rd party and we have only one copy of it.

Obervation:
There is another way we access this dll. By a console application.
Win32 App - Static.lib -> AfxLoadLibrary(ABC)

And for my surprise this is working (It is able to load the dll and am able to call the funcitions of dll)

The whole code is a existing legacy code. I am trying to use a new dll instead of the old one, since we changed the driver.

Am trying to debug the issue, will get back soon.

I'd really try that with Depedency Walker, that for sure wil shed in more light. While debugging it, you'll mostly just see that the call fails.
Anyway, since you are saying it works with a console app, this backs up my suspicion that the issue is about Windows versions, since there were quite a few new APIs introduced with the newer ones. So if that whole thing works with a console but does not with a GUI...
Again, in short: Depedency Walker will tell you exactly what's going on when you load the DLL in question.

I did the dependency walker for the 3p dll.

It is pointing out:
MSJAVA.DLL "Error opening file. The system cannot find the file specified (2)"
Can I add this file to the system somehow and would it solve the problem?

Another exercise I did was to simulate the problem using a test MFC application(just a dialog app) instead of my legacy app.
It is working fine.

I don't understand what is that my legacy app is doing extra or not doing something.
Here, I have also been suggested to run a debugging tool to check the difference when it fails and succeeds.

Analysis so far.
1.) Win32App -> static.lib -> AfxLoadLibrary(3rdpartyDll)              Pass

2.) LegacyMFCApp -> static.lib -> AfxLoadLibrary(3rdpartyDll)       Fail

3.) TestMFCApp -> static.lib -> AfxLoadLibrary(3rdpartyDll)           Pass

Thanks for the comments so far..

>>Can I add this file to the system somehow and would it solve the problem?

No, you can ignore msjava.dll, see http://www.dependencywalker.com/faq.html

Can you try to load your 'LegacyMFCApp' in Dependency Walker and then run "Profile.."? The output that is created should offer more info, please post it.

you could open a command window and change to the folder where the 3rd party dll resides and try to start your application from there. if it succeeds now, the problem probably  is caused by another dll in the same folder which has a duplicate somewhere else. by changing the folder it uses the right "version" of the dll. if that is the case, you would need to find the duplicate dll somehow.

I wonder whether your application could not load the 3rd party dll statically. you would need an import lib which might be delivered with the 3rd party dll and where you have to link against (means you have to add it to the linker - input - additional dependencies). if statical linking succeeds and your application starts successfully, the problem would be caused by the dynamic loading which is dependent on the current folder and PATH environment variable. you could try to add the path of the 3rd party dll to the PATH environment variable and start your application again.

Sara

There are no multiple copies of the dll on system. It is a driver and resides in system32.
The vendor of the drive has instructed to use AfxLoadLibrary and GetProcAddress to use any API.

I will try to do dependency walker of the LegacyMfcApp tomorrow morning.
It is our main master control app which intern calls many MFC apps. I expect the profile output would be huge.
I will also do this for the successful MFC app, I think the comparison may be helpful too.

Dependency walker for LegacyMFC application resulted in yellow for INETCOMM.DLL (also msjava.dll, but ignored).

But I think I might have found the actual problem.

I used the properly working application (win32 app) and tried to call the DLL's APIs.
For some APIs it returned an error. The vendor error code explanation says "exported function not getting loaded from library".

So this probably explains why it was failing for the LegacyMFC app even at the AfxLoadLibrary (Somehow the call to AfxLoadLibrary was detecting the non-availability well ahead as compared the cases where it actually loaded without a).
I fail to understand that why was the behaviour of AfxLoadLibrary different in different cases for the same dll.
I will go back to my vendor for some explanation.

Thanks to jkr and Sara for patiently answering to my problem.