Today I fired up Visual Studio 2010 (Visual C++) and started working on a project. The solution contains two projects. One is a static library I am writing, the other is a test application containing unit tests for the library.
Without changing anything from yesterday, the executable no longer links:
LINK : fatal error LNK1104: cannot open file 'mylib.lib'
The static library compiles and links fine. I have not changed the project settings in around a week, and it was linking just fine yesterday.
If I go into the executable project's settings and add a library directory for $(SolutionDir)\debug, I instead get the following link error:
LINK : fatal error LNK1104: cannot open file 'kernel32.lib'
I am not sure what the problem is. I have tried cleaning, rebuilding, and even rebooting my machine. Google turned up some bugs in ancient Visual C++ versions (but I'm using 2010), as well as the possibility that the program is already running. However, it is not running, and a reboot confirms this.
What would cause the linker not to find core libraries such as kernel32.lib, or for that matter, the output directory for my solution?
This is old-fashioned C++, a cross-platform library, not that managed stuff Microsoft added.
I had to check "Inherit from parent or project defaults" in the "Library Directories" dialog. Once I did that, the linker could find all the necessary libraries. I still had to include $(SolutionDir)\debug though.
Include the microsoft SDK directory in project->properties->linker->general->additional library directories.
on my computer it is
D:\Program Files\Microsoft SDKs\Windows\v7.1\Lib
I fixed this problem by disabling "Enable .NET Framework source stepping" (see: "Menu bar / Tools / Options / Debugging / General / Enable .NET Framework source stepping"). Apparently this is a bug in Visual Studio.
Related
I have a project in visual c++ where I am referring some external DLL.
I have already included the lib directory in linker section and mention it in the input section of the linker and also included the same in c/c++ General Additional Include Directories section.
Thus the project compiles successfully but whenever I try to run it; it fails with an error "Application was unable to start correctly" but if I see the output section it seems everything is loaded correctly but against that particular Dll it says that "Cannot find or open the PDB file".
How to fix this error so that I can run my program. It is an MFC program running in Visual Studio 2010.
when I run the program through the Dependency Walker, most of the API-MS-WIN-CORE-HEAP, FILE, and EXT-MS-WIN-SESSION USERMGR -l1-1-0.dll many similar to this are unavailable. I even tried to repair the visual studio it didn't work. Is there any idea how to go about it
0x0000007b sounds familiar to me.
Most likely that is due to 32/64 bit library mixture you are linking with.
Either you are building for x64 and linking with a win32 external library or vice versa.
In your Visual Studio project settings separately configure platform architectures you are compiling for and then you can choose the profile which you are actually compiling for.
I have a Visual C++ solution with static and dynamic libraries, and one executable that uses these libraries. I'm currently upgrading from Visual Studio 2010 to Visual Studio 2015, I also upgraded the SDK version the projects use to 10.0.10586.0 (Windows 10).
Everything compiles and links correctly, except for one linker warning:
uuid.lib(unknwn_i.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
uuid.lib is part of the Windows SDK. It might have been compiled with /GL, but does that mean that every executable that gets linked against this library must use /GL? That would be pretty constraining. By the way, if I switch to Windows SDK version 8.1 (but still using Visual Studio 2015), the warning goes away.
I have a feeling that something else might be wrong here (even though the linker points to a very specific location), because I found zero Google references of this particular error with this particular object file, which is very strange...
Any ideas?
Edit:
The warning is present in both Debug and Release builds
According to link.exe with /VERBOSE, X.obj (and only that object) in my executable project is referencing unknwn_i.obj, that's why it is "pulled in". This project does not use /GL nor /LTCG at all (checked the project properties, each cpp file's properties in the project, and there are no "standalone" property sheets in the solution)
I also tried removing all libraries linked to the exe project from it's linkage list. When only the default ones were linked (kernel32.lib, uuid.lib, etc.), the warning still persisted (aside from tons of unresolved references, but that's because I intentionally removed libraries). So it's not external libraries that cause this issue.
Background:
So I picked up Programming the Windows Driver model and tried to build the very first sample it has using visual studio 2013 Ultimate. While the book seems very reputed, there is no update for the sample code.
I saw some signs to used the older "build" instead of current msbuild / visual studio. But that is another learning I am not prepared to do unless required (especially as I didnt find nmake or build quickly enough and i ll be learning older build processes which I dont need to use).
Problem:
error C1083: Cannot open include file: '\inc\wxp\warning.h': No such file or directory stddcls.cpp
Building the sample gives me this error.
I included the folders for wdm.h and warning.h in the includes path. Wdm.h got resolved, but warning.h continues to throw an error - and I dont even know where warning.h in included/referenced.
I can post the entire code if required.
Yes, I am new to driver development.
If this book is too old to use, pointers to "newer" tutorials of Windows driver dev is appreciated.
In Visual studio
Project -> Properties -> C/C++ -> Advanced -> Forced Include file.
There is a hardlink to warning.h here. This needs to be changed to
C:\Program Files (x86)\Windows Kits\8.1\Include\shared\warning.h and the error goes away!
Another useful link for "Programming the Windows Driver Model" Oney:
http://csserver.evansville.edu/~reising/EE%20356%20Fall%202005/Changes%20to%20files%20from%20Walter%20Oney.pdf
I am facing the following (fairly common) problem: I am running my program in Debug mode in VS2010 and/or VS2012, but at startup it crashes, saying:
The programme can't start because MSVCP100D.dll is missing from your
computer. Try reinstalling the program to fix this problem.
Now I found a number of possible solutions, but none of them work for me:
Compile with /MTd instead of /MDd: actually this does solve the problem, but I am not allowed to: my program is part of a bigger program, and /MD[d] is mandatory.
Install the VS 2010 Redistributable package: This doesn't work because I have VS 2012 installed, so this installer tells me: "A newer version of Microsoft Visual C++ 2010 Redistributable has been detected on the machine."
Finding, dragging and dropping a version of MSVCP100D.dll into the correct directory: I am not dropping unknown DLLs into places where they might interfere with other things.
Last resort: reinstalling VS2010/VS2012: possible, but as it would also mean reinstalling lots of other packages and plugins I need, I'd like to avoid this if it's not absolutely necessary.
Are there any other options left?
The Visual Studio REDIST packages never deploy the DEBUG versions of the CRT files. This is by design.
With VS 2012 or later, the easiest way to deploy the DEUBG versions of the CRT is to install the "Remote Debugging Tools" package on your test machines.
For VS 2012, the latest Remote Debugging Tools package is here
For VS 2013, the latest Remote Debugging Tools package is here.
Another option is to just use application local deployment of the DLL (i.e. copy it into your app directory). Again this is only for testing purposes. For actual deployment of your application, you are required to use the non-debug versions of the CRT.
If this error is happening on your development machine, however, then you have other problems because with VS 2012 installed, you should have the VS 2012 DEBUG CRT on that machine.
UPDATE:: Sorry, I would have expected the debug CRT DLLs to be included in the remote debugging tools package along with the remote debugger bits and the Direct3D 11 Debug Device. Alas, it's not. See Preparing a Test Machine To Run a Debug Executable. You have to either use the MSMs in Program Files (x86) directory in \Common Files\Merge Modules or copy the DLL-side-by-side from Program Files (x86) directory in \Microsoft Visual Studio <version>\VC\redist\Debug_NonRedist\. The VS Team probably assumed you would have already been doing that, but I'll suggest to them to roll it into the remote tools package.
I had a similar issue (the project made in VS 2012 but I was running VS2013) and resolved it by:
Open the project (or the solution ) in VS2013(or the newer one)
Open Project menu and select "Retarget the project" option (it was the first option but after applying it, this option vanished).
Rebuild your solution.
I am new to openCV and C++ and had the same problem using openCV 2.4.10 with Visual Studio Express 2013 on a Windows 7, 32-bit platform. If I made a simple program without using OpenCV, the program ran but when I used OpenCV I got the missing DLL error.
This post made things clear:
I guess the problem I had was not with my Visual Studio but my OpenCV. The OpenCV was compiled on a version of visual studio which required MSVCP110.dll. I could have tried another version of OpenCV or compiled OpenCV again using VS2013 but I was short of time. Instead, I found the dll file elsewhere and placed it in my system32 folder (not sure if that's recommended). This fixed the problem. However as #slater mentioned, I won't recommend downloading the dll from external website due to security issues.
This is a debug runtime DLL. If (and ONLY if!) you just want to run the debug build of your own application on a system without Visual Studio installed, then you can find the missing DLLs in
C:\Windows\System32 (for 64-bit builds)
C:\Windows\SysWOW64 (for 32-bit builds)
Just keep copying DLLs until your executable will run.
If this is NOT what you are trying to do, refer to https://stackoverflow.com/a/27386721/2279059, which is the CORRECT, but less practical answer.
I had the same problem, I found out that the cause is that I used dll compiled with VS2012 in a VS2013 project. JUST downloaded the missing dll and put it in my linker path and wala: the program worked. I downloaded it from http://www.dll-files.com/.
Particulars: My program was working in in release mode but not in the debug mode as it says the MSVCP110D.dll is missing. My code was an opencv image processing program. I put the missing dll in opencv linker path in the VS2013 project options.
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