I am trying to debug some shared library problems on a machine with dozens of shared libraries with the same name. I need to find the one .dll out of 10 identically names file that is working correctly.
When we moved computers the program seems to load the wrong dll.
On the working computer I want to figure out exactly which dll the program choose. I was able to get the name of the dll displayed but not the full path.
Does anybody know how to display the full path?
You do actually want to download and run Dependency Walker. Opening your application in this program will display all its dependencies, show their paths (and you can display the full paths) and reveal those DLLs it can't find.
If some of your DLLs are loaded dynamically, just use the profile option to actually execute the application.
This will additionally show those dependencies which are loaded at a later stage within your program.
I'd recommend using Process Explorer.
This will let you see loaded DLLs (even dynamically loaded ones), as well as other useful information such as sockets, security, environment variables, threads and strings, all without launching a debugger.
Related
qgif4.dll, qjpeg4.dll, qtiff4.dll all implement these functions:
qt_plugin_instance
qt_plugin_query_verification_data
dumpbin possibly isnt smart enough to see if any functions in qgif4.dll, qjpeg4.dll, qtiff4.dll could be called and thus are needed by the application.
To be precise: I ran dumpbin and it said our exe doesn't depend on any of the above dlls's, but my manager still has doubts whether or not the qjpg4.dll is needed. Is there a way to tell for sure before shipping?
Of course we need to supply all dlls needed by our app. But we want to supply what is essential only, since the app has to run on a stripped down embedded version of Windows XP with size constraints: all is run from virtal RAM disk.
Those are Qt plugins. They are loaded on the fly by Qt depending on which image formats you use in your Qt code.
You should be able to deduce which ones are needed by looking at which image formats you load with Qt code.
You can also run your program while Process Monitor is running. It will trace, among others, all loaded DLLs, so you will know that those loaded DLLs are needed (needed for the code you ran during that session. This method does not guarantee that some other code of the program that you did not execute in that session does not depend on an other image plugin)
I have a very frustrating problem, I'm debugging my code, and for complete Call Stack I need to get symbols for msvcr120.dll (msvcr120.i386.pdb).
The thing is, that I can't get it.
tried loading it from MS Symbols Servers, result:
SYMSRV: http://msdl.microsoft.com/download/symbols/msvcr120.i386.pdb/16F5E2EF340A453ABC8B8F67DC6FD8082/msvcr120.i386.pdb not found
http://msdl.microsoft.com/download/symbols: Symbols not found on symbol server.
tried downloading manualy symbols packages for various Windows versions from MS, downloaded aprox. 2GB, got symbols for msvcr from 90 to 110, and two 120 (from Win 10 package):
msvcr120.i386.coresys.pdb
msvcr120_clr0400.i386.pdb
So, is there a way to get "msvcr120.i386.pdb" ?
In order to get the proper PDB for the file, you need to know which module is actually loaded. If you create a crashdump (.DMP) of the program while running (which you can do with taskmanager), it should show you the exact file loaded, including it's full path. You can also use a tool like dependency walker, which may do a better job at finding the full path.
Once you have the path, you can then specifically try to force-load symbols for that module by right-clicking, loading, and pointing to the exact file in question. That should get the proper hash and load the correct PDB from the MS symbol store into your local cache.
What's likely happening is that the program you're running either has a manifest calling out a specific SxS version of the DLL, OR your program has crashed enough that Windows has placed it in "compatibility mode". Either way, that means the program and VS are finding different versions of the DLL, thus the problem you're having. You can also see this when your program crashes on a different machine than the one you're debugging on, especially if they're not both exactly in the same place for windows updates.
If you do dev work regularly, you should disable Windows automatically putting things into compatibility mode. It will save you lots of headaches down the road.
I'm working on a keylogger. Here I found an implementation that loads current keyboard in runtime. The problem is that no keyboard libraries from win8 or win7 are loaded correctly. But I managed to find one US keyboard library that works fine.
So, now, I would like to add that library to resources and to use it when I'm loading keyboard.
My question is, how do I navigate to that resource dll when calling LoadLibrary()?
If you really want an exe instead of installer, you can bundle a dll as resource. ReadResource and write it to file disk(some temp path, such as appdata\local\temp); and then runtime load it, here is the link about runtime load library; Finally you need to delete it.
My basic issue is this: my program (MyProgram.exe) has a dependency on a DLL from another program (OtherProgram), and I'm trying to avoid repackaging a new DLL every time OtherProgram updates. I'd like to have MyProgram.exe link in OtherProgram's DLL when it launches, but I'm not completely sure that Windows allows for this. So if there is some kind of workaround that would also be acceptable.
And just for some background, the platform is Windows 7 x64, and MyProgram.exe runs fine when I create a symlink in the MyProgram.exe project directory to the DLL in OtherProgram's install directory. When I try to run it without the symlink, I get the "program can't start because OtherProgramDLL.dll is missing from your computer" error.
Any advice or links to relevant info is greatly appreciated!
EDIT: Clarification: the DLL is not linked at compile-time, this issue crops up at runtime
There are two types of dynamic linking in the Windows world:
Load-Time linking is when a DLL is loaded automatically when your program starts up. Windows finds this DLL using a specific algorithm I'll discuss below.
Run-Time linking is when you specifically load a DLL by calling LoadLibrary in your code. Similar rules apply as to how the library is found, but you can specify a fully-qualified or relatively-qualified path to control the search.
In the case of Load-Time linking, MS recommends that your program's DLLs are stored in and loaded from the same directory where your application is loaded from. If this is at all workable, this is probably your best option.
If that doesn't work, there are several other options, outlined here. One is to leverage the search order by putting the DLL in either the working directory or the directory where the application was loaded from.
You can change the working directory of an application by:
Create a shortcut to your application.
Bring up the shortcut's properties
Edit the "Start in" property with the directory where the DLL is located.
When you launch your application using the shortcut, it will load the right DLL.
Other options for load-time linking include:
Adding a manifest to your application which specifies where your dependent assemblies are, or,
Setting the PATH.
You could use LoadLibrary, but you would need a way to guarantee the DLL's location. This Wikipedia article provides good example on how to use the DLL after it has been loaded.
You can add the directory where the dll is located to the PATH environment variable.
I have struggled with the same problem and also found a dead end with the suggested methods like LoadLibrary, SetDllDirectory, Qt's addLibraryPath and others. Regardless of what I tried, the problem still remained that the application checked the libraries (and didn't find them) before actually running the code, so any code solution was bound to fail.
I almost got desperate, but then discovered an extremely easy approach which might also be helpful in cases like yours: Use a batch file! (or a similar loader before the actual application)
A Windows batch file for such a purpose could look like this:
#echo off
PATH=%PATH%;<PATH_TO_YOUR_LIB>
<PATH_TO_YOUR_APP_EXE>
/edit: Just saw #SirDarius comment in Luchian's answer which describes that way, so just take my batch code bit as a reference and all credits go to him.
I have the same problem with one application I am working on.
I do not want to use runtime loading because there are tens of functions I would need to manually create function pointer for.
Mr Dibling's mention of manifest file opened a new door for me but I sadly found out that the oldest version of windows that supports the feature is Windows 7. It won't even work on Vista.
Long story short, a friend familiar with Windows Application development told me to look up Delay-Loaded DLL, which turns out to solve the problem perfectly with minimal effort. It delays the loading of DLL library to either the point you manually do, or the first time its function is called. So you just need to add your DLL path to the search path before that happens, where SetDllDirectory helps.
Here is the steps to make it work:
1) Specify the DLL to be delay-loaded to linker, either through your makefile, cmake or VS property page (Linker->Input of VS2015)
2) Call SetDllDirectory at the beginning of your program, before any call to the DLL is made.
Delay-loaded DLL is supported all the way back to VC6.
SetDllDirectory is supported after XP SP1.
Use Symbolic Links to the 3rd Party Executables
I found the approach advocated by Aaron Margosis useful. See:
Using NTFS Junctions to Fix Application Compatibility Issues on 64-bit Editions of Windows
Essentially, create symbolic links to each of the dependent 3rd Party executables. Place these symbolic link files in and amongst your own dependent executable files. Except for filename changes to the targets, the 'soft' symbolic links will resolve the load-time dependencies even as the target of the links are changed by future updates.
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.