LoadLibrary - Explicit Linking in an MFC Extension DLL

Posted on 2000-03-09
Last Modified: 2013-11-20
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;

Question by:princejose
  • 2

Accepted Solution

simmvar earned 150 total points
ID: 2600086
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

LVL 30

Expert Comment

ID: 2600122
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,


Expert Comment

ID: 2603160
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


Author Comment

ID: 2627721
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!!

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

Introduction: Load and Save to file, Document-View interaction inside the SDI. Continuing from the second article about sudoku.   Open the project in visual studio. From the class view select CSudokuDoc and double click to open the header …
Exception Handling is in the core of any application that is able to dignify its name. In this article, I'll guide you through the process of writing a DRY (Don't Repeat Yourself) Exception Handling mechanism, using Aspect Oriented Programming.
This video will show you how to get GIT to work in Eclipse.   It will walk you through how to install the EGit plugin in eclipse and how to checkout an existing repository.
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

707 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now