I'm getting this error when I try to run my app:
I checked and there is no reason that I can see that it wouldn't be able to find libnlopt-0.dll. Here it is (note GlassModelCalcualator is the DLL that uses libnlopt-0.dll), in the GlassModelCalcualatorDLL folder:
and in the debug folder of GlassModelCalcualatorDLL:
I have a different program that has a console which uses GlassModelCalcualator.dll and that also has this issue. To fix that, I had to put libnlopt-0.dll in the Debug folder of GlassModelCalcualator.
I'm assuming this is not the same problem here since you can clearly see that libnlopt-0.dll is in GlassModelCalcualator's Debug folder.
Any ideas?
Windows will follow a hierarchical order when searching for dll's.
You could place your dll in the same directory as the exe or even in the Windows system folders (only if you're absolutely sure you want to keep this dll forever as there's no cleanup)
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
Related
VS2017, SDK/WDK, C++ project
we have a c++ solution (driver) that is shared across developers via Team Foundation Services - visualstudio.com (now called azure devops?).
When I perform a get latest source code, and want to rebuild the solution I get two MSB3030 errors:
"Could not copy the file "C:\path of my colleague his file" because it was not found."
I found it strange that I saw on one of the two errors a path of my colleague his pc. He works on C:\ I'm working on E:\
Unloading the project, I saw he path being set here:
<ItemGroup>
<FilesToPackage Include="C:\path of my colleague\foo.xml" Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<PackageRelativeDirectory>
</PackageRelativeDirectory>
</FilesToPackage>
We cannot get this solution to build because of the MSB3030. First we have to clean the specific projects individually, rebuild it, then build another project etc.. a few steps to perform manually in the correct order , trial and error, drinking coffee, throwing bananas to the pc and praying that a monkey outputs the code correctly.
Has anyone seen somehting similar regarding MSB3030 errors?
On my pc I see the path of my colleague, but he doesn't see my path (strange!).
C:\Program Files (x86)\Windows
Kits\10\build\WindowsDriver.common.targets(1699,5): error MSB3030:
Could not copy the file 'C:...' because it was not found.
I've set the Any CPU to x64 because it doesn't make any sense for c++.
C++ Windows Driver MSB3030 could not copy the file '' because it was not found
The reason for this issue is that the path of the ItemGroup is an absolute path in the project file:
<ItemGroup>
<FilesToPackage Include="C:\path of my colleague\foo.xml" ...>
...
</FilesToPackage>
</ItemGroup>
Regardless of whether your colleague has added this file to source control, when you pull the code from the TFS server to your local and put the code in a different local folder, the absolute path will bring you a lot of trouble, you need to manually check the code on the TFS server for this file and you need to modify the absolute path of this file in your project. But this problem will reappear after your colleague updates after you submit your code. Because an absolute path cannot be assigned to two different paths C:\ and E:\.
To resolve this issue, you need to change the absolute path to a relative path in the source code. Generally, we prefer to add this file to the Solution/Project folder, then use the MSBuild Macros $(SolutionDir)/$(ProjectDir) to specify it.
Check Common macros for build commands and properties for some more details.
Hope this helps.
After finishing my C++ program (on windows os using codeblocks)(using libcurl) when i try to launch the program from the executable it displays an error saying that i can't start the program because libcurldll is missing,reinstall program then retry. I don't think any line of code is needed here,it's just a configuration and logics problem,any ideas,would be great !
Please note that,running it from the codeblocks's console works fine.
Common issue with DLLs or SOs is that the executable needs to know where they are.
A common solution is to place the DLL library in the same folder as the executable:
Find the libcurldll file.
Find the folder containing your executable.
Copy the libcurldll file into the folder containing your executable.
I'm making a program in visual c++. The program relies on some dll files, which I don't want to place in system32. Now the dll files is in the same folder as my .exe, but i would like to move them to a sub folder. The problem is, if I move the files, my application fails to start and comes with this error message:
MyProgram.exe - Unable to Locate Component
This application has failed to start because myDll.dll was not found. Re-installing the application may fix the problem.
I have had the same problem before, where if found a solution, which included adding something to the registry, but i forgot how it worked, and now I can't find the guide again.
Can someone please help me?
There is more than one way to solve this problem. As other mentioned you can modify search path for your application in registry. Sometimes, you don't have rights to write to the registry, or you cannot do it for other reasons, then you can set dll path explicitly, the WinAPI function for that is SetDllDirectory, see MSDN.
Sounds like you're after the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths key. See here for complete information. In short, a string called Path points to a DLL search path. For example if your application was called "MyApp" a .reg file like this would do the trick:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppPaths\MyApp.exe]
#="C:\\Program Files\\MyCompany\\MyApp\\MyApp.exe"
"Path"="C:\\Program Files\\MyCompany\\MyApp\\DLLs"
I believe this is the article you are looking for:
http://www.codeguru.com/Cpp/W-P/dll/article.php/c99
Each application can now store it own path the registry under the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
The use the application path, set a key for your application, using ONE.EXE from the example above:
HKEY_LOCAL_MACHINE...\CurrentVersion\App Paths\ONE.exe
Set the (Default) value to the full path of your executable, for example:
C:\Program Files\ONE\ONE.exe
Add a sub-key named Path
I'm writing a wrapper program that loads Winamp input plugins. I've got it working well so far with quite a few plugins, but for some others, I get an error message at runtime when I attempt to call LoadLibrary on the plugin's DLL. (It seems to happen mostly with plugins that were included with Winamp.) A dialog appears and gives me the error code and message above. This happens, for example, with the in_flac.dll and in_mp3.dll plugins (which come with Winamp). Any ideas on how I can remedy this situation?
EDIT:
This basically iterates through the plugins in a directory and attempts to load and then free each one. Some plugins produce the error I mentioned above, while others do not.
wstring path = GetSearchPath();
FileEnumerator e(path + L"in_*.dll");
while(e.MoveNext()) {
wstring pluginPath = path + e.GetCurrent().cFileName;
MessageBoxW(NULL, pluginPath.c_str(), L"Message", MB_OK);
HINSTANCE dll = LoadLibraryW(pluginPath.c_str());
if(!dll) {
pluginPath = wstring(L"There was an error loading \"") + wstring(e.GetCurrent().cFileName) + L"\":\n" + LastErrorToString();
MessageBoxW(NULL, pluginPath.c_str(), L"Error", MB_OK);
continue;
}
FreeLibrary(dll);
}
Starting from Visual Studio 2005, the C/C++ runtime MUST be put in the Windows side-by-side cache (C:\windows\WinSxS), so putting the CRT DLL's next to your exe doesn't work anymore (with one exception, see later).
You MUST also refer to the CRT DLL's via a manifest file. This manifest file is generated by the linker and will have a name like myexe.exe.manifest or mydll.dll.manifest. Distribiute this manifest with your application/DLL or link it in the exe/dll using the mt command.
The side-by-side cache and the manifest file system were introduced in Windows XP and are mainly intended to solve the DLL hell and to increase security.
Not referring to the CRT using a manifest or not putting the CRT in the side-by-side cache will generate error 6034.
If you still want to put the CRT DLL's next to your application, you could also use private assemblies, which means creating a kind of mini-side-by-side cache in the folder of your application. You can find additional information on MSDN.
there can be many reason... put your code here for clarification... one of the many solution might be is
Rebuild your application with a manifest. Building an application with Visual Studio automatically puts the manifest into the resulting EXE or DLL file. If you are building at the command line, use the mt.exe tool to add the manifest as a resource. Use resource ID 1 if building an EXE, 2 if building a DLL.
Also, you may try adding this into the code:
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'\"")
I'm including python.h in my Visual C++ DLL file project which causes an implicit linking with python25.dll. However, I want to load a specific python25.dll (several can be present on the computer), so I created a very simple manifest file named test.manifest:
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<file name="python25.dll" />
</assembly>
And I'm merging it with the automatically embedded manifest file generated by Visual Studio thanks to:
Configuration Properties -> Manifest Tool -> Input and Output -> Additional Manifest Files
-->$(ProjectDir)\src\test.manifest
python25.dll is now loaded twice: the one requested by the manifest, and the one that Windows should find through its search order.
Screendump of Process Explorer http://dl.dropbox.com/u/3545118/python25_dll.png
Why is that happening and how can I just load the DLL file pointed by the manifest?
After exhaustive battle with WinSxS and DLL redirection, here's my advice for you:
Some background
Various things can cause a DLL file to be loaded under Windows:
Explicit linking (LoadLibrary) -- the loader uses the current activation context of the running EXE file. This is intuitive.
Implicit linking ("load time linkage", the "auto" ones) -- the loader uses the default activation context of the depending DLL file. If A.exe depends on B.dll depends on C.dll (all implicit linkage), the loader will use B.dll's activation context when loading C.dll. IIRC, it means if B's DllMain loads C.dll, it can be using B.dll's activation context -- most of the time it means the system-wide default activation context. So you get your Python DLL from %SystemRoot%.
COM (CoCreateInstance) -- this is the nasty one. Extremely subtle. It turns out the loader can look up the full path of a DLL file from the registry using COM (under HKCR\CLSID). LoadLibrary will not do any searching if the user gives it a full path, so the activation context can't affect the DLL file resolution. Those can be redirected with the comClass element and friends, see [reference][msdn_assembly_ref].
Even though you have the correct manifest, sometimes someone can still change the activation context at run time using the Activation Context API. If this is the case, there is usually not much you can do about it (see the ultimate solution below); this is just here for completeness. If you want to find out who is messing with the activation context, WinDbg bp kernel32!ActivateActCtx.
Now on to finding the culprit
The easiest way to find out what causes a DLL file to load is to use Process Monitor. You can watch for "Path containing python25.dll" or "Detail containing python25.dll" (for COM lookups). Double clicking an entry will actually show you a stack trace (you need to set the symbol search paths first, and also set Microsoft's PDB server). This should be enough for most of your needs.
Sometimes the stack trace obtained from above could be spawned from a new thread. For this purpose you need WinDbg. That can be another topic, but suffice to say you can sxe ld python25 and look at what other threads are doing (!findstack MyExeModuleName or ~*k) that causes a DLL file to load.
Real world solution
Instead of fiddling with this WinSxS thing, try hooking LoadLibraryW using Mhook or EasyHook. You can just totally replace that call with your custom logic. You can finish this before lunch and find the meaning of life again.
[msdn_assembly_ref]: Assembly Manifests
I made some progress for the understanding of the issue.
First let me clarify the scenario:
I'm building a DLL file that both embeds and extends Python, using the Python C API and Boost.Python.
Thus, I'm providing a python25.dll in the same folder as my DLL file, as well as a boost_python-vc90-mt-1_39.dll.
Then I have an EXE file which is a demo to show how to link to my DLL file: this EXE file doesn't have to be in the same folder as my DLL file, as long as the DLL file can be found in the PATH (I'm assuming that the end user may or may not put it in the same folder).
Then, when running the EXE file, the current directory is not the one containing python25.dll, and that's why the search order is used and some other python25.dll can be found before mine.
Now I figured out that the manifest technique was the good approach: I managed to redirect the loading to "my" python25.dll.
The problem is that this is the Boost DLL file boost_python-vc90-mt-1_39.dll that's responsible for the "double" loading!
If I don't load this one, then python25.dll is correctly redirected. Now I somehow have to figure out how to tell the Boost DLL file not to load another python25.dll...
Dependency Walker is usually the best tool for resolving this kind of problem. I'm not too sure how well it handles manifests though...
Where in this entangled mess is the actual process executable file?
Two possibilities come to mind:
You are writing a Python extension DLL file. So the Python process is loading your DLL file, and it would already have its own python25.dll dependency.
The EXE file loading your DLL file is being built with header files and libraries provided by the DLL file project. So it is inheriting the #pragma comment(lib,"python25.lib") from your header file and as a result is loading the DLL file itself.
My problem with the second scenario is, I'd expect the EXE file, and your DLL file, to be in the same folder in the case that the EXE file is implicitly loading your DLL file. In which case the EXE file, your DLL file and the python25.dll are all already in the same folder. Why then would the system32 version ever be loaded? The search order for implicitly loaded DLL files is always in the application EXE file's folder.
So the actual interesting question implicit in your query is: How is the system32 python26.dll being loaded at all?
Recently, I hit a very similar problem:
My application embedding Python loads the python32.dll from a known location, that is a side-by-side assembly (WinSxS) with Python.manifest
Attempt to import tkinter inside the embedded Python interpreter caused second loading of the very same python32.dll, but under a different non-default address.
The initialisation function of tkinter module (specifically, _tkinter.pyd) was failing because to invalid Python interpreter thread state (_PyThreadState_Current == NULL). Obviously, Py_Initialize() was never called for the second Python interpreter loaded from the duplicate python32.dll.
Why was the python32.dll loaded twice? As I explained in my post on python-capi, this was caused by the fact the application was loading python32.dll from WinSxS, but _tkinter.pyd did not recognise the assembly, so python32.dll was loaded using the regular DLL search path.
The Python.manifest + python32.dll assembly was recognised by the DLL loading machinery as a different module (under different activation context), than the python32.dll requested by _tkinter.pyd.
Removing the reference to Python.manifest from the application embedding Python and allowing the DLL search path to look for the DLLs solved the problem.