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.
Related
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?
I am using visual studio 2010 under Win7-64bit to build an application with openCV. I finished development and build the release version without error. I also successfully run the program in debug mode. I then move the .exe file to other directory in the same computer. I run it in cmd.exe and I got error warning: Error opening file <../../modules/highgui/src/cap_ffmpeg_implhpp:537>
I guess there are some dependence with some libraries of openCV but I don't how to solve it. My final task is that I can use that .exe in another computer under Win7 directly. How to do it?
I found a similar question here. But I don't have .dll file built, so what should I do to solve this problem?
Building an OpenCV app with shared libs (DLLs) require the DLLs to be available (same folder or in lookup path) to the exe when it is run.
If you are using static linking then you don't need any of the OpenCV DLLs to be reachable. However, due to licensing issues, ffmpeg is linked dynamically even when the rest of the libs are linked statically, and thus, you need to have the ffmpeg DLL available for the exe. It is called something like opencv_ffmpeg*.dll.
Note that this is only needed if you are using highgui related functionality.
In my Visual Studio 2008 project, the active configuration is Release, and there are no debug symbols enabled in the Compiler and Linker settings. I'm building an exe file from command prompt:
devenv standalone_cpp.sln /build "RELEASE|WIN32"
There is no reason why a debug dll MSVCR90d.dll should get used at runtime, but it does and crashes. I don't have the slightest clue why only the debug dll gets picked up not the release dll MSVCR90.dll. Can someone please help?
I even tried building my .exe in debug mode hoping that it would not crash, but still it crashes with the same assertion failure _BLOCK_TYPE_IS_VALID(pHead->nBlockUse). Please help before I shoot myself.
Re-install the MSVS2008 Service Pack 1. Your install seems to have gotten corrupted.
I've had this happen -- it manifests with mysterious behavior like this, although I've also seen it manifest with strange "internal errors" when linking large DLLs/EXEs, and sometimes compiling very large projects, or very large translation units. For some reason, re-installing the service pack worked.
Here's a quick link: http://www.microsoft.com/downloads/en/details.aspx?FamilyId=FBEE1648-7106-44A7-9649-6D9F6D58056E&displaylang=en
Another thought might be that you did link debug into your release executable. Even though you built the solution for "RELEASE|WIN32", if any prerequisites (linked libs) were the debug version (either the *.lib was referenced directly, or you referenced the debug path instead of the release path), you'd end up with that mix and the "debug" version of that DLL would attempt to load.
Then, the reason it crashed, is probably that you allocated in a "release" module and deleted in a "debug" module (or vice versa). That won't work, because the allocators are different (since the "debug" versions allocate extra state for sentinels and other "debug checks").
Remember that MSVS2008 will "override" any project/solution settings with those found in Tools==>Options, even if you build from the command line. Check that no debug paths are set there for linking in your release targets. (That was a bad decision by Microsoft because it leads to project/solution files that do not describe what's actually happening, they removed that "feature" in MSVS2010.)
You might also have a look at:
Linking against library in release and .exe in debug crashes in Visual studio
C++ Linking release built library with my debug build
I think #Charley is on the money.
Download Dependency Walker and see what is actually causing the debug DLL to be loaded. If what you say in your question is correct, then it'll probably be another library that you exe is depending on.
I made a program in Visual Studio 2010 on Windows 7 64-bit.
When I try to run it on Windows XP 32-bit I got message that msvcr100.dll is missing. When I try to copy that file from Win7 to WInXP I got message that msvcr100.dll is wrong.
How to set building in VS so msvcr100.dll would not be necessary?
First you need to make sure you're building a 32 bit executable - 64 bit ones won't run on 32 bit Windows.
Then you can either...
Ship the 32 bit redistributables with your application.
Remove the runtime dependency altogether and link statically to the C++ runtimes. To do this, set Project -> Properties -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library to Multi-threaded (/MT).
Linking the runtime libraries statically should help. Go to Project Options -> C/C++ -> Code Generation -> Runtime Library and change the value to Multithreaded or Multithreaded Debug and recompile. This way your application shouldn't depend on the runtime DLLs.
Also don't forget to build a 32bit executable.
The answers above helped me along, but I was still getting the error:
fatal error C1189: #error : Please use the /MD switch for _AFXDLL builds
So to help other who may have, like me, spent way too much time stumbling around in search of a clear solution, I'd like to add the bit of information that solved this issue for me. As it turns out, my project had the wrong "Use of MFC" setting to make use of the answer above.
To put it in clear terms:
Open up the project properties (alt-F7 or Project-menu -> [My Project] Properties) and go to Project -> Properties -> Configuration Properties
If General -> Use of MFC is set to Use MFC in a Static Library
you must set
C/C++ -> Code Generation -> Runtime Library
to either Multi-threaded Debug (/MTd) or Multi-threaded (/MT)
and if
General -> Use of MFC is set to Use MFC in a Shared DLL
you must set
C/C++ -> Code Generation -> Runtime Library
to either Multi-threaded DLL (/MD) or Multi-threaded Debug DLL
I got this answer from the Microsoft community answers website and all credit should go to David Wilkinson.
The keyword here is "redistributable" since this error message may occur when attempting to run a .exe that was not developed on the end-user's PC.
The following is a good (and trusted) source to download redistributables without having to download the entire VC++ package or patch:
https://visualstudio.microsoft.com/vs/older-downloads/#microsoft-build-tools-2015-update-3
In my case I needed the "Visual Studio 2010 VC++ Redistributable" even though we are in year 2022.
enter image description here
Step 1.: Go to this website dll-files.com.
enter image description here
dll-files.com is a great repository of Windows DLL files and has almost all the DLL files that are existent on Windows.
Step 2. Now type there your DLL error in the search window of the website.
Step 3. DLL-Files.com will immediately list out the zip file containing that particular DLL file. Download this zip file to your computer and extract it. The extracted folder will contain the DLL error file.
enter image description here
Step 4. Copy the download DLL file (Only that file) and paste this file in your default system folder based on your operating systems below.
C:WindowsSystem (Windows 95/98/Me)
C:WINNT\System32 (Windows NT/2000)
C:\Windows\System32 (Windows XP, Vista, Windows 7/Windows 8.1/Windows 10)
Windows will ask you whether you want to replace the existing DLL file with the new one. Say yes and let Windows copy the file. Restart your computer and voila, you can now run the game/app that was not opening and giving the DLL error, easily.
There are many other websites which will give you DLL files that you want
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.