I'm using Visual Studio 2010 to create a 32-bit DLL as a plug-in to a 3rd party app (AviSynth). The DLL was being correctly loaded by the 3rd party app until I tried to use the FFTW (http://fftw.org) DLL. I took the 32-bit FFTW DLL, ran "lib /def:libfftw3-3.def" to create a .lib file, added that as a resource in the project. Made some calls to the functions. It compiles fine, but when I try to load it in the third party tool, it fails.
I've tried putting the FFTW DLL alongside my DLL, and I've also tried using LoadLibrary from inside my DllMain, but it's still not working.
I am able to stop the debugger in the DllMain function and in the function called by AviSynth (AvisynthPluginInit2), but AviSynth claims to be unable to load the DLL after that, and breakpoints at the tops of functions that were called before are no longer hit.
The AviSynth error message is:
LoadPlugin: unable to load "C:\Program Files (x86)\AviSynth 2.5\plugins\xxxMYPLUGINxxx.dll"
Thanks for your help.
The first thing I try when I get something like this is Dependency Walker:
http://www.dependencywalker.com/
It won't catch every possible problem, but it's very quick to check for simple problems (missing DLLs, missing exports). You can also set it to open any number of file-extensions by double-clicking them. I usually set .dll, .ax, .ocx, .sys, .exe.
IMO one of the essential tools for any Windows developer.
ps: if Dependency Walker doesn't find any problems, try to load your DLL with LoadLibrary() and see what GetLastError() returns.
BTW:
and I've also tried using LoadLibrary from inside my DllMain, but it's still not working.
You cannot call LoadLibrary() from DllMain().
The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order.
(The entry-point function is your DllMain)
Turns out that the FFTW DLL had to be in the same directory as the AVS script, not the AVISynth plugin directory. I guess that's the working directory for Virtual Dub.
Anyway, it works now. Thanks for the help!
Related
My application store some data in data only dll files. Those dll files are loaded with LoadLibrary() when needed at runtime and then discarded with FreeLibrary() after finish using them. The main application access the data stored in the dll files using GetProcAddress(). The program is written in C++ and uses WinAPI calls, no MFC or other libraries. It has two versions x64 and x86. It works fine on most systems. My dll files do not call other libraries or depend on anything else. Each is a stand alone file.
Recently, I discovered the program does not work on one machine. this specific one has Windows 10 x64 installed on it. After investigations I found the following:
LoadLibrary() fails with error message "Could not find module". The dll is in same directory with main program.
I replaced the call to LoadLibrary() with LoadLibraryEx() and tried the following falgs:
LOAD_IGNORE_CODE_AUTHZ_LEVEL did not work. The dll could not be loaded.
DONT_RESOLVE_DLL_REFERENCES ... works?? But, Microsoft strongly recommends not to use it.
LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE ... loading the dll succeeds?? But, the call to GetProcessAddress later fails. the program could not access the data in the dll file. So this is not actually working.
I could not find anything wrong with this machine. All other programs are working fine.
I tried the x86 version on this machine and it worked fine using original LoadLibrary().
My installer is dual system and automatically installs x64 version when it finds x64 windows. Normal user can not simply switch to x86 when he gets such error.
My question is how can I eliminate this error and make my program works on any machine:
Should I call LoadLibraryEx() using DONT_RESOLVE_DLL_REFERENCES flag and ignore Microsoft warning?
Is there any way I can get my library loaded with simple call to LoadLibrary()?
If I call LoadLibraryEx() with LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE flag, as recommended by Microsoft, how can I access the data without calling GetProcessAddress()?
Thank you in advance.
I am new to DLL development and appreciated for any help.
I have an existing c++ project and am trying to build it into dll using visual studio 2012. I changed the target extension and configuration type to be dll. I also excluded my main function. When I rebuilt it, the compiler complains:
LINK : fatal error LNK1561: entry point must be defined
When I moved the main function back, I could build the project successfully.
I want to make a dll only because there are functions and objects I need to use for another project, so i don't think I need a main function for the dll. Is having a main function the only solution for this error? Thank you in advance.
Just like a program requires main, DLLs require DllMain, a place to start and handle loading and unloading of the DLL.
Rather than a DLL consider a static library. There is far less overhead, no DllMain and supporting loaders and unloaders, and they are built directly into the compiled executable so you don't have to carry an extra file around and run the risk of clients with out of date DLLs or some malicious tool replacing your DLL with theirs. If you don't need the ability to swap out the the library with a replacement, a DLL is probably overkill.
I've been making a program in Visual Studio 2012, what comes with it is that when I send my application to someone, they need the VS2012 Runtime, which sometimes they don't know where to download or what they need (for normal users "xxx.dll is missing" is very misleading).
I know exactly which dependencies my application requires (fantom.dll [Lego Mindstorms stuff] and the VC++ 2012 Redist).
I would like to show a dialog when these libraries are missing on application startup and provide the user with download links for these libraries.
Is this possible to accomplish?
Yeah you could do something like:
Move all of the code in your binary into a DLL.
Create an EXE which dynamically loads the DLL using LoadLibrary and unloads it with FreeLibrary.
If LoadLibrary fails, check if its due to missing DLLs, if so then display a MessageBox/your custom message and exit.
Of course this means your EXE project must NOT depend on the runtime itself - this shouldn't be an issue since you'll only need to call 3 win32 API's.
No it's not possible but you can create an installer for your program. The error is thrown during the loading of your program, before your code execution...
You can try with that : http://www.codeproject.com/Articles/24187/Creating-an-Installer
I can't speak for testing the VS2012 Runtime dynamically, but you can certainly validate fantom.dll dynamically. Instead of static-linking to the DLL directly, you can dynamically load it instead. You can configure your project to delay-load the DLL at run-time, and then provide a delay-load callback handler that the RTL will call if the delay-load fails. Or you can simply skip the delay-load feature and load the DLL yourself manually by calling LoadLibrary() and GetProcAddress() directly.
Sure, you can verify if a dependency exists on the deployed system. A few things come to mind...
You can see if the assembly is recognized on the running system by calling AppDomain.AssemblyResolve() . Further reading here
Another more primitive option is to call a File.Exists(your assembly path here) test, but I would advise against this as it's a bad practice to require hard-pathed installation locations.
That said, and as others have stated, it's still by far the best approach to create yourself an installation distribution.
How can I catch a missing DLL in a dependent DLL?
For example:
Application is loading a DLL A.
DLL A is loading DLL B.
So if DLL B is not available, application just shows me: DLL A not found.
Any hints where I could find a solution?
At the moment I use dependency-walker to solve this issue, but I need something inside the application, so that the customers must not launch the external tool whenever a DLL is missing.
I'm not entirely clear what your use case is here, but can't your application call LoadLibrary to check if the DLLs are available before launching the "external tool", and if it fails report that the DLL(s) are missing?
You could explicitly load the DLL. You'll get an error/exception if you have a missing dependency.
Perhaps you can statically compile the code in the DLL so the problem is eliminated?
If you're fighting with "DLL Hell" you might also be able to place the DLL's in the file system so windows will load the DLL's you want.
You can parse IAT and implement an algorithm similar with the one used by LoadLibrary to check if dll wil be found. A start in implementing this is ImageNtHeader
I am writing a DLL to plug into another (3rd party) application. The DLL will need to depend on another set of DLLs (for license reasons I cannot link statically).
I would like my DLL to be "xcopy-deployable" to any directory. I would also like not to require adding this directory to the path.
If I just build the DLL the usual way, Windows will refuse to load the DLL, since it cannot find the DLLs next to the current process.
Are there any good options for helping Windows locate the DLL?
To answer some questions:
The DLL is written in C++.
The extra DLLs are QT-dlls.
I would like to place the extra DLLs in the same folder as my plugin DLL. I can get the name of that folder from GetModuleFileName.
The application is Firefox, the DLL is a PKCS#11 security module.
The application loads the DLL using the full path to the DLL (the user supplies it when installing the plugin).
Requiring that the DLLs be placed in System32 or next to the application would work, but it is a bit messy and could cause problems with uninstallers.
LoadLibrary and GetProcAddress would of course work, but is not really feasible in my case. I am using hundreds, if not thousands, of methods in the other DLLs. I really need to use the import-libraries.
I had thought about using delay-loaded dlls combined with SetDllDirectory in DllMain. Have anyone tried anything like this?
I can think of 3 ways.
put the dlls in the same folder as your application (you cannot do this?)
Use runtime linking. LoadLibrary() and GetProcAddress()
Use a manifest http://msdn.microsoft.com/en-us/library/aa374182(VS.85).aspx
But if the dll isn't in the same folder as the .exe, how are you going to know where it is? forget Windows not knowing, how do you know?
you can specify the path of dll as the parameter of LoadLibrary().
Another option is to modify the PATH variable. Have a batch file for launching the main app, and set the PATH=%PATH%;%~dp0. This ensures a minimal footprint, with no additional traces left in the system after running.