I have two C++ Visual Studio (16.5.0 Preview 2.0) projects: a library and an application that uses it. The library project produces four .lib files (for x86/x64 and release/debug), which the other statically links against. The application was until recently working fine in all configurations. Then recently I modified the library and rebuilt the .libs, and now when I build the application for x64 with "Use Link Time Code Generation" enabled, it crashes at runtime with an (apparently impossible) access violation. Note that the x86 build works with or without LTCG, and the x64 build works without it ("No Whole Program Optimization"). I've tried clean builds of both solutions and double-checked that I'm linking against the correct .lib.
This probably isn't a lot to go on, but does anyone have an inkling what the issue could be? Could VS's LTCG somehow cause the linker to use the old code?
Related
I have a fairly large project in Visual Studio 2010
I can build the project in both Debug and Release mode, copy the generated exe file along with a custom dll I need for a function in the program to another computer, and the exe file works without any problems
I am trying to make an installer for this project in Visual Studio 2010, following the instructions here: https://www.technical-recipes.com/2011/how-to-create-an-installer-in-microsoft-visual-studio/
I do not get any errors while building the installer, and I get a setup.exe and an msi file as a result, but if I install my program in another computer (not by development machine), when I try to run my program after installation I get a missing api-ms-win-crt-runtime-l1-1-0.dll error
How do I debug this problem? Since I can simply copy my Release or Debug build to the computer and make it work, doesn't it mean all the dll files my program is dependent on already exists in the other computer? And if this already works, why isn't the installer version working? How do I make sure that everything I need for this program is included in the installer?
My project in MFC dialog based and uses one third party library, for which I have both .lib and .dll file available. I need to do this in Visual Studio 2010. My development machine is Windows 10 64 bit Home edition version 1909. The installer I currently create installs my program in Program Files (x86) folder.
Static Linking MFC: It appears this issue was solved by making sure to statically link to MFC libraries. In the VC++ project: enable the setting: "include MFC in a static library". This enables static linking of MFC components, eliminating the dependency on shared dlls.
This is a common "missing runtime error" - there are generic check lists below which include this as one source for application launch problems.
Warning: Generally static linking should be avoided in order to benefit from security updates to shared dll files via other update mechanisms.
Short Version: In Visual Studio Installer Projects, check if the Visual C++ Runtime is available in the Prerequisites list.
See this answer, here is a quick screen shot:
Tools: If your project is large you might want to consider another MSI tool. There are many limitations with Visual Studio Installer Projects.
Merge Modules: There are merge modules to install the Visual Studio C++ Runtime, but it is recommended to use the setup.exe for these reasons.
Visual C/C++ Runtime: You are probably just missing the Visual Studio C/C++ Runtime. It needs to be deployed with your application, it is not on there by default (unless you link statically, in which case it should not be needed). Skim this list quickly for other ideas.
You can download the VC++ redistributables at ("The latest supported Visual C++ downloads"):
https://support.microsoft.com/en-us/kb/2977003
More Information:
More on the Visual C/C++ Runtime
Secondary Links:
Detecting presence of Visual C/C++ runtime on box
Missing Dependencies and check lists
Scan for application dependencies
Installing VC++ Runtime with merge modules
I am building a Qt App but I am having problems when I move the app to another PC. When I run the .exe the it keeps saying it is missing dependencies and once I transfer the missing one another one pops up. I assume that I need to install something on the target pc that contains all of these DLLs.
Some of the missing dependencies so far:
MSVCP140D.dll
vcruntime140d.dll
api-ms-win-core-rtlsupport-l1-2-0.dll
I think that there may be issues with the install of MSVS or MSVC on my build pc as I constantly have to point to things like UCRT manually.
Thanks in advance
Missing Runtime: Those files are obviously part of a runtime that your application needs (Visual C++ Redistributable for Visual Studio 2015 - maybe?), but more than that you seem to have distributed the debug version of your application which will depend on debug versions of runtime dlls (dll name ends with "d" as in MSVCP140D.dll). These are generally only installed on developer PCs, and are not for distribution to client PCs at all.
Release Build: Maybe try to build your application in release mode and try to run that executable on your client systems. The required runtime might already be present on their boxes, just not in debug version.
Static Linking: I suppose you could also try static linking (for the Microsoft runtime: How do I make a fully statically linked .exe with Visual Studio Express 2005?), if that is available to you (I am not up to speed with Qt's handling of this in terms of availability of static linking with different forms of licensing): MSVCP140.dll missing. Just so it is mentioned: thought conceptually the same, static linking is different for Qt (licensing issues?) and the core Microsoft runtimes (see link above). Use a binary dependency checker to investigate how dependencies have changed with new compilation settings.
Remote Debugging: If you need to make a test PC capable of running your application in debug mode (maybe for remote debugging without installing all of Visual Studio): Preparing a Test Machine To Run a Debug Executable.
"Hacky": It seems here is another, "hackier" approach that I would not really recommend: install VC++ Debug Runtime Distributable. For other Visual Studio versions look for the debug_nonredist folder. Debug versions of an application are not redistributable, and debug versions of the Visual C++ library DLLs are not redistributable. Very important.
I have VS2005, VS2008, and VS2010 installed on my Win7 development machine. I have one particular project that uses a 3rd party DLL that gets an exception during the LoadLibrary() call when the EXE project is built by VS2010 (when targeting either the v100 or v90 toolset.) It works perfectly when built by directly VS2005 or VS2008.
According to Li Shao's (of Microsoft) 2009 blog entry:
http://blogs.msdn.com/b/vcblog/archive/2009/12/08/c-native-multi-targeting.aspx
I should be able to open the VS2010 project and change the Platform Toolset from v100 to v90 and then VS2010 will actually use the VS2008 compiler, headers and libraries to build the program. If it is, then it isn't doing it "right" because the DLL will not load when the project is built this way. I tried looking at the build log to verify which compiler is used, but there are no paths or version numbers in my logs, so that was a bust.
This is a plain C (not C++, not MFC, not .NET) project written directly to the Win32Apis. Is there any way for this to work, or am I just stuck using a different compiler for a single project (out of over 100 that comprise the whole system)?
HELP!
Have a look at Daffodil: http://daffodil.codeplex.com/
After installing Daffodil, you'll be able to use VS 2010 to build projects using older versions of the libraries.
I think I've solved it. It seems that, while VS2010 will happily run the VS2008 compiler, linker, etc. VS2010 will NOT leave the project alone. When the project is imported to VS2010 there are some new default settings added to the command line and, apparently, at least one of them is different enough from VS2008 to make the DLL I'm using fail to load.
When I changed the Advanced Linker setting for Data Execution Prevention (DEP) from Yes (the default) to NO, my program started working again! In fact, I no longer even need to compile using the v90 toolset -- the ENTIRE problem was caused by the new default for the /NXCOMPAT linker command line switch. The /NXCOMPAT switch isn't even referenced in the project settings in the VS2005 IDE (where the project was created), but running "link /?" in the VC8 bin folder shows that the switch was known and the default was NO.
Too bad the Visual Studio IDE doesn't include a list of default settings that were in use by a project that have CHANGED in the new version. If that is too difficult, the importer should specify the changed settings using the old default values, otherwise the project was imported incorrectly, wasn't it?
I wrote a C++/CLR Windows Form program and it works fine on the compiler computer but not on any others. The target computers have .Net4 and the C++ redistribution pack. I really don't understand how the settings need to be set and the info on the web concerning this stuff is very confusing for a beginner. How do I need to have my compiler set so that I can get this program to run? If I need to link .dll's how do I go about doing that. Here are the key settings as I know:
The Runtime Library is set to /MDd; MFC:Standard Windows Libaries; ATL:Static Link to ATL; CLR:/clr:pure.
Edit: If I install VS on taget computers I can open the .exe without a problem, not even opening VS or loading any source files. It seems it's still dependent on VS somehow, any idea's on this and how to over come it?
/MDd specifies a dynamic debug CRT, this won't be installed by the standard CRT redistributable MSI
Try putting a release build on the target machine instead.
I know this has been asked in other places and answered, but I'm having issues with MS Visual Studio 2010. I've developed a C++ executable but if I run the Release version on a machine that doesn't have the VC++ runtime library (ie, msvcr100d.dll), I get the "program cannot start because msvcr100d.dll is missing from your computer" error.
This is weird for two reasons:
Why is it trying to link with the debug version of the redistributable?
I tried applying this fix, setting the runtime library setting to /MT instead of /MD (multi-threaded DLL), but that only made the problem worse (if I manually copied msvcr100d.dll, it then said it couldn't find msvcp110.dll).
How can I package the runtime library with my executable so that I can run it on machines that don't have MS VC 2010 or the redistributable installed?
I know it's considered a security risk to include a copy of the DLL since it won't ever be updated, but my goal is just to send this executable to a few friends in the short term.
You definitely should not need the debug version of the CRT if you're compiling in "release" mode. You can tell they're the debug versions of the DLLs because they end with a d.
More to the point, the debug version is not redistributable, so it's not as simple as "packaging" it with your executable, or zipping up those DLLs.
Check to be sure that you're compiling all components of your application in "release" mode, and that you're linking the correct version of the CRT and any other libraries you use (e.g., MFC, ATL, etc.).
You will, of course, require msvcr100.dll (note the absence of the d suffix) and some others if they are not already installed. Direct your friends to download the Visual C++ 2010 Redistributable (or x64), or include this with your application automatically by building an installer.
For me the problem appeared in this situation:
I installed VS2012 and did not need VS2010 anymore.
I wanted to get my computer clean and also removed the VS2010 runtime executables, thinking that no other program would use it.
Then I wanted to test my DLL by attaching it to a program (let's call it program X).
I got the same error message.
I thought that I did something wrong when compiling the DLL.
However, the real problem was that I attached the DLL to program X, and program X was compiled in VS2010 with debug info. That is why the error was thrown.
I recompiled program X in VS2012, and the error was gone.
This problem explained in MSDN Library and as I understand installing Microsoft's Redistributable Package can help.
But sometimes the following solution can be used (as developer's side solution):
In your Visual Studio, open Project properties -> Configuration properties -> C/C++ -> Code generation
and change option Runtime Library to /MT instead of /MD
Usually the application that misses the .dll indicates what version you need – if one does not work, simply download the Microsoft visual C++ 2010 x86 or x64
from this link:
For 32 bit OS:Here
For 64 bit OS:Here
I got the same error.
I was refering a VS2010 DLL in a VS2012 project.
Just recompiled the DLL on VS2012 and now everything is fine.
Debug version of the vc++ library dlls are NOT meant to be redistributed!
Debug versions of an application are not redistributable, and debug
versions of the Visual C++ library DLLs are not redistributable. You
may deploy debug versions of applications and Visual C++ DLLs only to
your other computers, for the sole purpose of debugging and testing
the applications on a computer that does not have Visual Studio
installed. For more information, see Redistributing Visual C++ Files.
I will provide the link as well : http://msdn.microsoft.com/en-us/library/aa985618.aspx