LoadLibrary - Explicit Linking in an MFC Extension DLL

I have an Extension DLL inside which I am trying to load another DLL with the usual LoadLibrary()(Explicit Linking). But LoadLibrary() fails with an error code 126 which says

If anyone about to suggest me that the DLL I am trying to load might not be in the search path, I had tried giving the full path of the DLL in LoadLibrary() too.The result is the same.

Are there any restrictions in loading a library from an Extension DLL. If not then whats the problem here.

I am attaching my code here.

HINSTANCE       hLib;
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;


extern "C" int APIENTRY
DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
      // Remove this if you use lpReserved

      if (dwReason == DLL_PROCESS_ATTACH)
            TRACE0("CONVERTER.DLL Initializing!\n");
            // Extension DLL one-time initialization
            if (!AfxInitExtensionModule(ConverterDLL, hInstance))
                  return 0;

            // Insert this DLL into the resource chain
            // NOTE: If this Extension DLL is being implicitly linked to by
            //  an MFC Regular DLL (such as an ActiveX Control)
            //  instead of an MFC application, then you will want to
            //  remove this line from DllMain and put it in a separate
            //  function exported from this Extension DLL.  The Regular DLL
            //  that uses this Extension DLL should then explicitly call that
            //  function to initialize this Extension DLL.  Otherwise,
            //  the CDynLinkLibrary object will not be attached to the
            //  Regular DLL's resource chain, and serious problems will
            //  result.

            new CDynLinkLibrary(ConverterDLL);
      else if (dwReason == DLL_PROCESS_DETACH)
            TRACE0("CONVERTER.DLL Terminating!\n");
            // Terminate the library before destructors are called
      return 1;   // ok

extern "C" _declspec(dllexport) BOOL MyFunction(long,char** szParam)

  int             ret;

  #ifdef __cplusplus
      int (WINAPI *MYDLL) (char *,char *,char,short);
      int (WINAPI *MYDLL) (char *,char *,char,short);
  DWORD errcode=GetLastError();
      MYDLL= (int (WINAPI *)(char *,char *,char,short)) GetProcAddress( hLib, "_MYDLL@16" );
            ret=(*MYDLL)(szParam[0],szParam[1],"NATIVE",11);  // nonzero return indicates error    
    FreeLibrary(hLib);   }
      AfxMessageBox("The DLL MYDLL.dll missing in the directory specified!!");
            CString szError;
            szError.Format("The Error Code is %d",errcode);
  return TRUE;

Who is Participating?
simmvarConnect With a Mentor Commented:
Hi princejose

The module not found error comes because in your dll MYDLL you would have exported the function MYDLL with the extern "C" _declspec so it will not have any decorated name as _MYDLL@16 so if your function name is MYDLL call it as "MYDLL" in the function name in the GetProcAddress().

wishing you success

With regards

Hi simmvar,

princejose told LoadLibray() fails, not GetProcAddress()...

Hi princejose,

Check the path of the dll. To load the dll without a specified path the dll must reside in one of the following directories:

1. The path from which the application's executable is loaded
2. The current working directory
3. For NT the window's SYSTEM32 directory
4. The window's SYSTEM directory
5. The windows directory
6. any directory set with the PATH environment variable

Best would be to change the dll's project settings to build the dll directly to the applications debug/release directory.

you should even check for following reasons (from MSDN):
Windows 95: If you are using LoadLibrary to load a module that contains a resource whose numeric identifier is greater than 0x7FFF, LoadLibrary fails. If you are attempting to load a 16-bit DLL directly from 32-bit code, LoadLibrary fails. If you are attempting to load a DLL whose subsystem version is greater than 4.0, LoadLibrary fails. If your DllMain function tries to call the Unicode version of a Win32 function, LoadLibrary fails.

hope that helps,

Hi prince


please check whether your dll is a regular dll or not and the mfc dlls are staticallty linked or shared if shared then check whether u have all the mfc dlls reqd. the mod_not_found could be for a another dll used by your dll

princejoseAuthor Commented:
Hi Zoppo and Zimmvar & Others,

 Sorry for the delay in commenting about your suggestions. I had found a temporary solution to my problem here. When I keep the dll to be loaded(MyDLL.dll) in WinNT/System32 dir it gets loaded by my extension dll. But the mystery remains why it does not load the MyDLL.dll when it is placed in the same directory as where the extension dll lies.

Well I thought the dll search sequence suggested by Zoppo was correct.

1. The path from which the application's executable/Extension DLL is loaded

2. The current working directory
3. For NT the window's SYSTEM32 directory
4. The window's SYSTEM directory
5. The windows directory
6. any directory set with the PATH environment variable

But you can see that MyDLL is placed at path 1 as explained above. But LoadLibrary still does not load MyDLL.dll. Another part of this problem is that if I just make an application/exe and keep MyDLL at the same place as exe it loads MyDLL. But not in case of an Extension DLL.

Is there any such restrictions for extension DLLs that the dlls and extension dll tries to load should be in System32 dir. I donot think so.

So if any of you can figure out, it will be great and very helpful...

Thank you very much!!
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.