I have an error that I suspect might be caused by different versions of the CRT being loaded on two computers running Windows 7. How do I determine which version of MSVCR90.dll in the winsxs folder is being loaded?
My program is a DLL being loaded by another EXE. It is compiled using Visual Studio 2008 SP1.
As Al Kepp answered, you can use Dependency Walker, "Depends.exe". For DLLs that are dynamically loaded, the best way is to profile the application as it loads your library.
In Dependency Walker open the EXE, not your DLL. Then click "Profile-->Start Profiling". If the application requires arguments you can provide them in the window that opens, otherwise just click "Ok" to launch the program. Once the program is open, use it in the normal way so that it loads your DLL. Now that your DLL is loaded, you should be able to browse the tree in Dependency Walker to see which versions of the CRT are being used.
If you can't see the version, ensure that the full paths are shown in the tree by clicking the "C:\" button.
You can also see which version of the CRT the application or library is requesting by checking the manifest, which is generally, but not always included in the DLL or EXE. in Visual Studio, click "File->Open->File..." and select the EXE or DLL. Open the RT_MANIFEST resource and you should see some XML which lists the CRT as a dependency and the version.
Most applications using these language libraries in DLL files use simply the latest version of those DLL in Windows directory. If you for some reason need some specific version, the easiest what you can do is probably to put those correct files to the same directory as your exe.
You can use Dependency Walker application to see which DLL files are loaded into your process on startup. You can download it from Microsoft site for free.
Related
Recently I switched from mingw to msvc compiler for my Qt app.
I am using Qt5.8. The msvc debugger is from the windows 10 kit (though I develop on Win7 and Win8.1) and the compiler from the vc++2015 build tools.
I can run the app locally, but I can't run it on a different, clean computer.
I know that I have to copy the compiler specific dll's to the application's executable directory. All the other dlls are found by windeployqt. Still I don't get it to work. I can't ship vc_redist packages the user has to install, due to the requirement to be able to load the app from a pendrive. On the dev machine there are several dlls of the same name, how can I figure out which ones are actually used by the compiled app?
Questionable dlls is especially api-ms-win-crt-runtime-l1-1-0.dll.
On the deployment I got those errors:
I also tried Dependency Walker and showed the full paths. I assume the first hierarchy level is the important one, that's why I've hidden deeper hierarchies. I am wondering why the full path shows the dir System32 because isn't this the 64-bit files folder?? I did not target any specific one but my app must be running on x86. Is this a misunderstanding?
EDIT
According to another question and this Microsoft blog update it worked for me when I additionally included all dlls from this folder C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x86. There is also a file named ucrtbase.dll. I have no idea why DependencyWalker showed different ones.
You can use tools such as Dependency Walker to see which DLL is used by any other DLL or exe file.
Edit: You can also take a look at Determining Which DLLs to Redistribute on MSDN
Also you could use static linkage to link against the MSVC runtime (i.e use /MT switch instead of /MD (see https://msdn.microsoft.com/en-US/library/2kzt1wy3.aspx). However this would also mean rebuilding Qt, but it would also give you the opportunity to build a static version of Qt, meaning that you would not need to ship any DLL alongside your exe. You can find more info on Qt wiki: Build Standalone Qt Application for Windows
I have written an application in Visual Studio 2013 that relies on a DLL called WSTP32i1.dll. Both the dll and its associated .lib file are included in the project and it compiles and builds without error. However, when I run it, I get this:
Putting a copy of the DLL in the application folder doesn't help. When I check the Solution Explorer, the DLL appears to be marked "Does not participate in build," which seems wrong but I'm not sure what to change it to.
Any suggestions?
Solution Explorer tree contains source files (cpp, h, rc etc.) used to build executables. Item Type property defines how this file will be processed. DLL is not a valid source file and IDE does not know how to process it. That is why it "Does not participate".
The standard (and the easest) way to link import library is to add reference to DLL project in Common Properties / References page of application project. By default, all DLL and EXE files of your solution are built in the same $(SolutionDir)$(Configuration) directory, so everything is ready to use without any adjustments and post-build events.
If your DLL is built in another solution, make sure that it is placed in the same folder as EXE file, or DLL's folder is specified in PATH environment variable.
I wrote a tool that many users would use on their computers. I noticed however, that users who do not have visual studio installed, cannot open my executable. The error says that msvcp100.dll is missing. I found in internet a redistributable package from microsoft, that should apparently provide these dlls. My question is: is there another way to bypass this problem? Something like an option in the project properties?
Yes, you can change a compiler setting to link the C++ standard library classes into your program instead of having a dependency on the DLL. Right-click your project in the Solution Explorer window, Properties. Switch to the Release configuration (upper left). C/C++, Code Generation, Runtime Library setting. Select /MT.
Only do this when you only have a single monolithic EXE. When you use your own DLLs then you really need msvcr100.dll and msvcp100.dll so that the runtime library gets shared between all modules.
It is part of C++ runtime and the target machine needs it. THere are couple of ways to address it.
Please check following link from Microsoft MCVCP100.DLL
I'm not a a very experienced Windows developer, so I hope this all makes sense.
I created a Managed Assembly DLL using Visual Studio 2010. The DLL (Plip.dll) contains a C++ class that is using System.IO.SerialPort class to do some simple communication over a serial port.
In a second Visual Studio project I created a simple GUI that uses the class found in Plip.dll. In my GUI project I have the line : #using "Plip.dll" . In the Project Properties I set the 'Resolve #using References' value to the correct location of Plip.dll. The GUI builds just fine. If I copy the GUI.exe and Plip.dll to the same folder, the GUI runs just fine on my computer.
The problem I am having is that when I copy both files to a second computer, I cannot get the GUI executable to run. I get the following error : "System.IO.FileNotFoundException. Could not load file or assembly "Plip.dll" Vesion=.... ". I get this error even though both the exe and dll are located in the same folder.
Any suggestions on how to resolve this issue? Is there some option I need to set in my GUI project to load the DLL correctly at run time?
I suppose the problem is not the Plip.dll, but it's dependencies.
Use Dependency Walker on the second computer to see if it needs any other dll's (they might be installed in System folder or in %PATH% on your development computer, but not on the other).
If this second computer doesn't have Visual Studio installed, you are probably missing Microsoft Visual C++ 2010 Redistributable Package (you need to install it on the other computer)
Also make sure that you compile in Release because debug builds need debug dependencies.
I found the answer to this problem to be much simpler than Dependency Walker (but admittedly, that was fun to look at).
In my case, the issue was a mis-match between the .DotNet versions in the DLL and with the application's .net version. This was caused by building the "class library" using .DotNet 6.0 (dot net core?).
Instead, the entire class needed to be re-built using "Class Library (.NET Framework)"
enter image description here
I wrote an article on this problem.
https://keyliner.blogspot.com/2022/09/visual-studio-c-linked-dll-exception.html
How can we trace a compiled application from windows 7. I can see in the event viewer that some DLL files which my program is trying to fetch are causing problems but I can't figure out why.(This is with qtcored4.dll)
You can solve DLL loading problems with Dependency Walker, either by looking at the exe (just open it) or tracing DLL load process by starting profile.