AfXLoadLibrary fails GetLastError returns 127

I have a MFC application which links a static library (.lib) which intern loads a 3rd party dll.
The MFC application and the static lib are compiled in VS 2005 (We plan to upgrade to VS 2010 ). The dll is built on VS2010.

MFC App -> Static.lib -> AfxLoadLibrary(ABC)

Though we are upgrading to VS2010 shortly, would like to know if, the difference in the version of compilers of the dll and .exe, is actually the problem.

Please help me solve this experts.

Who is Participating?

Improve company productivity with a Business Account.Sign Up

jkrConnect With a Mentor Commented:
Error 127 is

# The specified procedure could not be found.

This suggest that you are loading a DLL that refers to a function in another DLL which could not be found. Try the Dependency Walker ( to identify both the function and the DLL.

I suspect that the DLL you are loading requires a more recent version of Windows or the CRT or MFC respectively.
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.

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

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.
Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

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.
BasaveshAuthor Commented:
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

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.

BasaveshAuthor Commented:
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.
BasaveshAuthor Commented:
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.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.