We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you a podcast all about Citrix Workspace, moving to the cloud, and analytics & intelligence. Episode 2 coming soon!Listen Now


loadlibrary error, redistributable needed for dll compiled in vs2008 ?

stev75 asked
Medium Priority
Last Modified: 2013-11-20
I have a dll project that creates a com interface in visual studio 2008 on WinXP.

The visual studio idl compiler (7.00.0500) creates the interface header file automatically when compiling.

Trying to load the dll using Loadlibrary()  i get error 126 on a Win2000 system (module not found) and 14001 on another XP system (...dont know what to do about this description in MSDN..).
Besides that Loadlibrary() fails, also using regsvr32 for registering the Com object (with the absolute path to the existing dll of course) tells me, that the module could not be found (error 126).

On another XP system, the regsvr32 app throws a messagebox, telling that loadlibrary() function  failed, because of something like an "application conflict" (error value = ?)

What to do to make the dll get loaded on different windows OS ?

I assume to deliver several mfc dlls, service packs, or to link statically (create a lib) instead of a dll ?

Thanks experts!

Watch Question

Top Expert 2012
You beed to install the Visual Studio 2008 Runtime Redistributable package which you can download from http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en ("Microsoft Visual C++ 2008 SP1 Redistributable Package (x86)")

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts


thanks, i'll try it.
There's another point i would like to figure out>
i have an application that I ported from VS6 to VS2008.
The application compiled in vs2008 runs on machines WITHOUT the vs2008-redist package, except, the dll.
Which are my options to make the dll not need the package ?
- If creating a ".lib" is an option, is it possible to load it like the dll at runtime ?
- if having a.lib, what is different in loading the com interface ? loading without registering is not the problem, but using LoadLibrary(*.lib) is.
? Thanks!
>>>> If creating a ".lib" is an option, is it possible to load it like the dll at runtime ?

Yes, creating a lib can be an option if the now-dll-and-later-lib doesn't need any more dlls, e. g. multi-threaded CRT for .NET. If you have been not really carefully you have run into defaults which make it really difficult to make it run at a WIN2K.

Maybe the following is easier: Try to install the VS2008 on a Win2k (with .NET included). If taht worked you could build your win2k library there. If that doesn't work you most probably was lost somehow.


i was able to create a lib, with the options "MT" or "MTd", which means "multithreaded debug dll"
When I use Loadlibrary(*.lib) it fails with error 193 ("Is not a valid application. ERROR_BAD_EXE_FORMAT" )
- is it possible to load a .lib with "loadlibrary" ? I thought it was not, since .libs are linked to the executable.
In my solution, the project switched from "dynamic dll" to "static library", is now getting really big (which is good) and not built into the .exe. How to handle this file, when i want to access the functions?
>>>> Loadlibrary(*.lib) it fails with error 193
LoadLibrary is for loadings dlls (dynamic link library) only. A static library must be linked to your application by adding it to the linker input modules (or add it to the project tree for a first test). You then can call the functions directly by including the header and calling the functions without pointer.


Hi itsmeandnobodyelse?
In the project settings of the main app (the .exe) , the library for the dll is in the linker input settings anyway.
Now, changing the projext settings of the dll, it compiles as lib. The library now has gone bigger from 100KB to 1.9MB.
 But the execuatable is not bigger. It has the same size than before. I believe, I have to switch another setting ?
2) secondly, i register a com object manually, so I do NOT call CoCreatInstance(). I have an own function which i use to load the COM object manually without registering. In this function, LoadLibrary is used.
Can you please tell me, how I should modify my function, to load the module from the "lib", which was former a dll ?
Please see the code below. I hope it's not confusing.
jkr also handled this here>
Thanks very much for comments.

HRESULT createInstance(BSTR	bstrLibName, REFCLSID rclsid, LPUNKNOWN pUnkOuter, IN DWORD dwClsContext, REFIID riid, LPVOID* ppv) 
	char currentDir[_MAX_PATH];
	_getcwd (currentDir, sizeof (AktVerzeichnis) - 1);
	_chdir (currentDir);
	TCHAR buffer[_MAX_PATH+1] = _T("");
	if (GetModuleFileName(NULL, buffer, _MAX_PATH) == 0)
		MessageBox(0L, "GetModuleFileName error", "", 0);
		return E_FAIL;
	// Load the library (bstrlibname should have the fullpath) 
	CComBSTR strFullLibName = CComBSTR(buffer);
	strFullLibName += CComBSTR("\\");
	strFullLibName += bstrLibName;
	//CString s;
	//s.Format("%s", W2A(_bstr_t(strFullLibName)));
	//MessageBox(0, s, "ibsreport dll module", 0);
	HINSTANCE hDLL = CoLoadLibrary(strFullLibName, TRUE);
	if(hDLL == NULL)
		DWORD err = GetLastError();
		MessageBox(0L, "CoLoadLibrary error", "", 0);
		CString s = buffer;
		s += "\\ibsreport.lib";
		err = GetLastError();
		return E_FAIL;
	// Get the function pointer 
	typedef HRESULT (WINAPI* PFNDllGetClassObject)(REFCLSID  rclsid, REFIID riid, LPVOID* ppv); 
	PFNDllGetClassObject pfnDllGetClassObject = (PFNDllGetClassObject)GetProcAddress(hDLL, "DllGetClassObject"); 
		MessageBox(0L, "pfnDllGetClassObject error", "", 0);
		return E_FAIL;
	// Get the class factory 
	CComPtr<IClassFactory> pFactory;
	HRESULT hr = pfnDllGetClassObject(rclsid, IID_IClassFactory, (LPVOID*)&pFactory); 
	if (hr != S_OK)
		MessageBox(0L, "pfnDllGetClassObject error", "", 0);
		return hr;
	// Create object instance   
	return pFactory->CreateInstance(pUnkOuter, riid, ppv);

Open in new window

>>>> But the execuatable is not bigger. It has the same size than before.
The executable will take only these modules (objects) from library which actuall ywere called. If you former called a dll with LoadLibrary and GetProcAddress and did not change that to direct calls, you may not wonder why the app got not bigger.
>>>> Please see the code below. I hope it's not confusing.
It is not confusing but it is a COM. If you now want to have a static library (I wonder how a com dll was converted to a library?) you need not  provide a COM interface but simple header files and functions. Forget the IUnknown and other stuff and call the functions directly without COM Pointer.


OK  that's right. The interface was intended to be language - independent, therefore it is COM.
But when we have a C++ source as COM client, it makes sense not using it, and therefore have an easier installation... Anyway I would need to change a lot, because the interface is big. Or can I leave COM syntax (e.g. like STDMETHOD declaration...? ) I'll give it a try. Thanks for any further comments! Anyway, I think I should pass some points now.
>>>> Or can I leave COM syntax (e.g. like STDMETHOD declaration...? )

You can leave the interface but not use it. Instead create instances of the classes using new operator and call the (non-COM) member functions directly.
You can also try by setting  option "Use MFC in a static liberary" under project->project settings->Configuration Properties -> General->USE of MFC of VS2008  
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.