I was trying to figure out why a debug build was blowing up with the "dependent assembly microsoft.vc80.debugcrt could not be found" event error.
After deleting everything (anything not .cpp or .h) and recreating the solution - I still had the problem.
A google search was fruitless and a re-install of VS didn't produce any change.
I did have the dlls in C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_f75eb16c.
I opened the \debug\.exe.intermediate.manifest file and it had 2 (dependentAssembly) entries:
1st: name='Microsoft.VC80.DebugCRT' version='8.0.50608.0'
2nd: name='Microsoft.VC80.DebugCRT' version='8.0.50727.762'
If I delete one and change the other one to
name='Microsoft.VC80.DebugCRT' version='8.0.50727.42'
I can get a build that will start.
Granted I did have VS2008 installed - but what is controlling the versions ? or How can I get the right debug dll version to "stick".
VS2008 was de-installed through the control panel.
EDIT: Found nothing in the registry if DebugCRT is searched for.
the environment path points to the VS8 folders .
There is only 1 DebugCRT folder in the c:\windows\winsxs\policies folder
(8.0.50.727.42)
The c:\windows\winsxs\manifests folder only has the .42 version of .cat and .manifest
The .manifest file (in above manifest folder) has version="8.0.50727.42"
Clarification: the manifest file has 2 "dependentAssembly" entries each with different versions and not the .42. I can delete 1 entry and change the version on the other to match the .42 to get a debug build that starts.
EDIT2:I'm also using boost and inside the DLLs there is the .762 version
The version was picked up by from the Boost DLLs which were a download, pre-compiled version of Boost. Once the libraries were re-compiled (and re-installed) a re-build of the solution produced a manifest with a single version and the program linked and ran.
So -Check the libs and dlls that are imported into the solution for version used.
VS 2008 is VC90 not VC80, so that's not part of the problem. The relation between manifest-requested assembly and SxS-loaded assenbly is found in C:\WINDOWS\WinSxS\Policies. IIRC, "8.0.50608.0" is generated by VS2005 pre-SP1. It's wrong, and should have been 8.0.50727.42, but this is caught by the policy.
I'm not sure how you're getting two manifests. What are your manifest settings?
I'd suggest rebuilding Boost in your particular environment. Also, you could do away with the Side by Side assemblies altogether by linking the CRT statically...
Related
Intro
I have a CMake-based C++ project. Until now I build and ran the project via CLion. Everything worked fine until I tried to run the .exe-file directly (not via CLion).
Problem
When I navigate to the cmake build directory in order to start my program via the executable file, it fails with the following message in the popup: Cannot continue the code execution because libgcc_s so-1.dll was not found. Reinstalling the program may resolve the issue.
I have the following questions
If I interpret the error message correctly, then this dll is missing on my computer. So I ask myself, why does my program still work when I start it via the development environment (CLion), although the error message expressly states that the source code requires this dll?
Is it the fault of my application/source code that the error appears or rather the current state of my computer? If the former, how can I prevent this error from appearing for other users?
What is the best way to fix this error? It's obvious that I need to download this dll, but where is the best place to put it (which directory and environment variable to use on Window)?
Which source is trustworthy to download this dll? I don't want to download any malware under this dll-name.
Optional: What kind of library is that? What functionalities does it offer?
Additional information
I use CMake as my build tool, CLion as the IDE and MinGW as the compiler.
What I have did so far?
I made sure it still works through the IDE.
I found this dll does not exist in the MinGW installation folder.
I searched the web for more information. Unfortunately, there are only pages unknown to me that only offer the download of this dll. That doesn't satisfy me.
I found the cause of my problem: I had two MingGW installations on my machine. Once the installation that comes with CLion and a separate one. The latter did not have the required dll. However, CLion used its own installation, which in turn owns the DLL. So the solution was to remove the separate installation and include the path to the CLion installation's bin/ directory in the PATH environment variable.
This file is part of MinGW-w64 when using SEH as exception model (as opposed to Dwarf or SJLJ). You need to distribute the .dll files your .exe file(s) depend on in the same folder as the .exe file(s).
If you don't have that file, then you probably have been using libraries compiled with different versions of GCC/MinGW(-w64). I recommend building everything with the same compiler to ensure stable binaries.
Tools like Dependency Walker can help you figure out which .dll files your .exe file depends on.
Or use the command line tool copypedeps -r from https://github.com/brechtsanders/pedeps to copy the .exe files along with it's dependencies.
I have many Qt projects in Visual Studio, using the new Qt/MsBuild format provided by the Qt VS Tools. When compiling in my development environment, where I have the Qt VS Tools installed, everything works flawlessly (compiling from IDE and from command line).
We have a computer dedicated to nightly builds, where only the compiler and msbuild are available (no IDE nor Qt VS Tools are installed).
When compiling the projects in such computer we get an error:
QtMsBuild: could not locate qt.targets, qt.props; project may not build correctly.
Followed by several lines such as
e:********\Preferences.h(4): fatal error C1083: Cannot open include file: 'ui_Preferences.h': No such file or directory
(Project contains Preferences.ui).
How can I solve such errors when Qt VS Tools are not installed?
One solution provided by the Tools' creators is to copy %LOCALAPPDATA%\QtMsBuild into each project directory. But we are talking about hundred of projects. Doing manually, and more on, pushing them as part of the project itself doesn't sound very elegant.
One option would be to add a pre-build step that copies it from a common place into each project (and adding a **/QtMsBuild line to each .gitignore file). Again, looks like too much work.
When looking at the .vcxproj file for the Qt project you find this fragment (the reason for the solution provided by creators):
<PropertyGroup Condition="'$(QtMsBuild)'=='' or !Exists('$(QtMsBuild)\qt.targets')">
<QtMsBuild>$(MSBuildProjectDirectory)\QtMsBuild</QtMsBuild>
</PropertyGroup>
So, the simplest solution (without being able to install the tools), is to copy the %LOCALAPPDATA\QtMsBuild directory (from a system with the Tools installed) into the night computer (in any common place, but I decided to keep the location used by the tools) and then setting an environment variable:
set QtMsBuild=%LOCALAPPDATA%\QtMsBuild
PS: do not add double quotes to the variable (at least I had problems with them, so VS couldn't find the files).
Update 9-14-2020
I'm not sure on which version it started, but Qt projects created with (at least) the v2.5.2 Qt VS Tools fails to compile indicating that the Qt version has not been set. To solve so, you can
Copy the Registry entries from a computer with tools installed, located at HKCU\SOFTWARE\Digia\Versions.
If you will rely on a single Qt version (but that may be update globally for all projects), you can skip the Registry and just set the Qt version of all projects to $(DefaultQtVersion) (the same used in past project formats) and define an environment variable pointing to the directory of the version: set DefaultQtVersion=c:\Qt\Qt_5_15_0\Win32, for example.
I had problems in my case setting up $Env:QtToolsPath="$Env:QT_PATH\bin" fixed the problem. (It was not finding qmake for some checks). This, I think, is required when using QtMsBuild v3.3
Not sure if this info is 100% correct but may help someone.
For me to use MsBuild with Qt using QtMsBuild (not installing Visual Studio and/or VS plugins), I need to set up:
Example (PowerShell):
- $Env:PATH="$Env:MSBUILD_PATH;$Env:PATH"
- $Env:QT_PATH="D:\BuildTools\Qt\5.15.1\msvc2019_64"
- $Env:QtMsBuild="D:\BuildTools\Qt\QtMsBuild303" #303 Against visual studio project version
- $Env:QtToolsPath="$Env:QT_PATH\bin" #Support QtMSBuild , At desktop is done by the plug in
- $Env:PATH="$Env:QtMsBuild;$Env:PATH"
- $Env:PATH="$Env:QT_PATH\bin;$Env:PATH"
I hit this and got it working.
I followed #cbuchart 's advice; but needed to do a little more/different.
So here is what I did. I copied %LOCALAPPDATA%\QtMsBuild to my repo. I then edited my .vcxproj with a text editor. I adjusted the line that looks like:
<QtMsBuild Condition="'$(QtMsBuild)'=='' OR !Exists('$(QtMsBuild)\qt.targets')">$(MSBuildProjectDirectory)\QtMsBuild</QtMsBuild>
To be:
<QtMsBuild Condition="'$(QtMsBuild)'=='' OR !Exists('$(QtMsBuild)\qt.targets')">$(MSBuildProjectDirectory)\..\QtMsBuild</QtMsBuild>
Depending on the relative location of where your project(s) are to the copied QtMsBuild directory you might want to adjust this. In my case the .vcxproj was in a directory one level from the directory that contains the QtMsBuild directory I copied.
Next in the QtMsBuild/Qt.props file I added the following:
<PropertyGroup>
<DefaultQtVersion>$(MSBuildThisFileDirectory)\..\Qt5.15.0\msvc2019_64</DefaultQtVersion>
<QtToolsPath>$(DefaultQtVersion)\bin</QtToolsPath>
</PropertyGroup>
That was added right after the opening Project tag in that file.
This was as #cbuchart mentioned something might have changed. I didn't do the Registry idea; but added those lines instead. I think it is possible to add them to a different file that gets imported before Qt.props if desired.
Now as for what this "Qt5.15.0\msvc2019_64" is; you'll need the tools, includes, libraries from a computer with Qt installed in order to build (also DLLs if your build needs to run the executable (i.e. tests)). This might be a lot of files so you can reduce it some if you know what you are doing. It might make sense to have these be put into it's own submodule or something.
After that it should uic/moc files and ultimately build (and run).
I got too. Maybe you need update your visual studio and then restart your computer ...
problem solved. reason: install 'qt vs tools' latest version but the visual studio
not support of it.
I've recently downloaded Assimp and I've run into some troubles.
I've linked the libraries and I can get the program to compile and it runs fine in Release mode; however, the Debug .exe hits me with this error:
The application was unable to start correctly (0xc0150002). Click OK to close the application.
Some more details:
I'm using VS2010 with Target Machine set to x86.
I am using the 32bit debug dll (Assimp32d.dll) that was provided, and I've tried setting runtime libraries to /MT, /MTd, /MD, and /MDd with no luck.
I read from other similar threads that I should run Dependency Walker on the .exe, but I'm not sure what the output means. I'll paste it here if this helps you guys.
Error: The Side-by-Side configuration information for "c:\users\-----\documents\visual studio 2010\projects\AssimpTest\debug\ASSIMP32D.DLL" contains errors. The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail (14001).
Error: At least one required implicit or forwarded dependency was not found.
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Rather than rebuilding the libraries, I downloaded a different set of libraries (it was the SDK installer) and the debug dll's from that are working perfectly.
Just in case anyone has the same problem with the same software, this was the exact name of the installer that worked for me: assimp-sdk-3.0-setup.exe
I ran into the same problem when trying to run a 64-bit project in Debug mode when using Assimp 3.0.
What I did was go to assimp/workspaces/vc9, open assimp.sln in Visual Studio 10, convert the project, then rebuild the 32 and 64-bit dll.
Mind you, you've got to install boost for that as well, and edit the project properties so it points to the boost directory for includes.
There's probably a way to do it using CMake as well, but I found the whole process too cumbersome to bother with in the first place.
My solution was just to link the debug build to the release .dll files. No more issues, and I wasn't that interested in debugging the Assimp library anyway!
I faced the same issue, later on I downloaded the "assimp-sdk-3.0-setup.exe" file & installed it as a standard windows application.
I pointed Visual Studio Solution Include & Lib directories to respective folders from newly installed location, copied DLL to my application location. The problem was resolved. Hope this helps someone.
Cheers.
I'm trying to compile a SDL-program I've written, but when I do, this error shows up:
The program can't start because SDL.dll is missing from your computer.
Try reinstalling the program to fix this problem
I have no idea as to why. I have SDL.dll.
I have put it in the correct folder: C:\Windows\System32.
I have the correct PATHS to all the SDL headers and such as well.
VS says:
Build succeeded: 1
and THEN the error above pops up on screen.
Add it into your debug folder or whatever directory your program is currently located at.
SDL.dll has to either be in the same directory as your application, or in a directory that's in the PATH environment variable.
IfSDL.dll is 32-bit and you're running a 64-bit system you have to place the dll into /Windows/SysWOW64/ rather than /Windows/System32/, which is used for 64-bit dlls.
EDIT:
You probably shouldn't be deploying your DLLs by copying them into the System32 directory, unless they're common libraries that are used by several applications, and even then I would use discretion. For example, an application could update the DLL, which could break other applications that rely on an older version of the library.
Instead, copy the DLLs into the same directory that the executable is being built in. If you're building and executing with Visual Studio it will look for the DLL in the Project directory, where your source files are probably located.
Just place your SDL.dll in the same folder and your problem will be solved.
And to answer to your problem with the PATH, you can specify in visual studio where he will look for executables while debugging. Maybe this isn't set correctly and that's why VS can't find SDL.dll?
I'm trying to run an OpenCV application through Microsoft Visual C++ 2010 Express, and get the following message:
How can I solve this issue?
I agree with Brandrew, the problem is most likely caused by some missing dlls that can't be found neither on the system path nor in the folder where the executable is. Try putting the following DLLs nearby the executable:
the Visual Studio C++ runtime (in VS2008, they could be found at places like C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86.) Include all 3 of the DLL files as well as the manifest file.
the four OpenCV dlls (cv210.dll, cvaux210.dll, cxcore210.dll and highgui210.dll, or the ones your OpenCV version has)
if that still doesn't work, try the debug VS runtime (executables compiled for "Debug" use a different set of dlls, named something like msvcrt9d.dll, important part is the "d")
Alternatively, try loading the executable into Dependency Walker ( http://www.dependencywalker.com/ ), it should point out the missing dlls for you.
In my case, Visual Leak Detector I was using to track down memory leaks in Visual Studio 2015 was missing the Microsoft manifest file Microsoft.DTfW.DHL.manifest, see link Building Visual Leak Detector all way down. This file must be in the folder where vld.dll or vld_x64.dll is in your configuration, say C:\Program Files (x86)\Visual Leak Detector\bin\Win32, C:\Program Files (x86)\Visual Leak Detector\bin\Win64, Debug or x64/Debug.
I take it that is a Vista Window! I often got this when first trying to port a DirectX program from XPsp3 to Vista.
It's a .dll problem. The OpenCV runtime.dll will call upon a system.dll that will be no longer shipped Vista, so unfortunately you will have to to a bit of hunting to find which system.dll it's trying to find. (system.dll could be vc2010 or vista)
This error is also caused by incorrect installation of .dlls (i.e not rolling out)
hth
Happy hunting
I got this error when trying to run my friend's solution file by visual studio 2010 after convert it to 2010 version. The fix is easy, I create new project, right click the solution to add existing .cpp and .h file from my friend's project. Then it work.
Just run .exe file in dependency walker( http://dependencywalker.com/)
and it will point you the missing dlls and download those dll (www.dll-files.com) and paste in the c:windows:system32 and the folder as your .exe and even provide the path of those dll in path variable.
Even I faced same error, I fixed it afterwards...
Two things you need to look into
Whether your system path is correctly set in your environment variables
Check the pre-processors in Project Properties->c/c++->Pre-processors. Check whether you have included _CONSOLE, this was causing error for me. For Some applications you need to include WIN32;_WINDOWS;_CONSOLE;_DEBUG;QT_DLL;QT_GUI_LIB;QT_NETWORK_LIB;QT_CORE_LIB;COIN_DLL;SOQT_DLL;QT_DEBUG;
I got this error while I was working in coin3D Application.
I met such problem. Visual Studio 2008 clearly said: problem was caused by libtiff.dll. It cannot be loaded for some reasom, caused by its manifest (as a matter of fact, this dll has no manifest at all). I fixed it, when I had removed libtiff.dll from my project (but simultaneously I lost ability to open compressed TIFFs!). I recompiled aforementioned dll, but problem still remains. Interesting, that at my own machine I have no such error. Three others comps refused to load my prog. Attention!!! Here http://www.error-repair-tools.com/ppc/error.php?t=0xc0150002 one wise boy wrote, that this error was caused by problem with registry and offers repair tool. I have a solid guess, that this "repair tool" will install some malicious soft at your comp.
It is because there is a DLL that your program is missing or can't find.
In your case I believe you are missing the openCV dlls. You can find these under the "build" directory that comes with open CV. If you are using VS2010 and building to an x86 program you can locate your dlls here under "opencv\build\x86\vc10\bin". Simply copy all these files to your Debug and Release folders and it should resolve your issues.
Generally you can resolve this issue using the following procedure:
Download Dependency Walker from here: http://www.dependencywalker.com/
Load your .exe file into Dependency Walker (under your projects Debug or Release folder), in your case this would be DisplayImage.exe
Look for any DLL's that are missing, or are corrupt, or are for the wrong architecture (i.e. x64 instead of x86) these will be highlighted in red.
For each DLL that you are missing either copy to your Debug or Release folders with your .exe, or install the required software, or add the path to the DLLs to your environment variables (Win+Pause -> Advanced System Settings -> Environment Variables)
Remember that you will need to have these DLLs in the same directory as your .exe. If you copy the .exe from the Release folder to somewhere else then you will need those DLLs copied with the .exe as well. For portability I tend to try and have a test Virtual Machine with a clean install of Windows (no updates or programs installed), and I walk through the Dependencies using the Dependency Walker one by one until the program is running happily.
This is a common problem. Also see these questions:
Can't run a vc++, error code 0xc0150002
The application was unable to start (0xc0150002) with libcurl C++ Windows 7 VS 2010
0xc0150002 Error when trying to run VC++ libcurl
The application was unable to start correctly 0xc150002
The application was unable to start correctly (0*0150002) - OpenCv
Good Luck!
In our case (next to trying Dependency Walker) it was a faulty manifest file, mixing 64 bits and 32 bits. We use two extra files while running in Debug mode: dbghelp.dll and Microsoft.DTfW.DHL.manifest.
The manifest file looks like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- $Id -->
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<noInheritable />
<assemblyIdentity type="win32" name="Microsoft.DTfW.DHL" version="6.11.1.404" processorArchitecture="x86" />
<file name="dbghelp.dll" />
</assembly>
Notice the 'processorArchitecture' field. It was set to "amd64" instead of "x86". It's probably not always the cause, but in our case it was the root cause, so it may be helpful to some. For 64-bit runs, you'll want "amd64" in there.
I faced this issue, when I was supplying the executable folder with a, by the .exe requested DLL.
In my case, the DLL I supplied to the .exe was searching for another necessary DLL which was not available.
The searching DLL was not capable of telling that it can not find the necessary DLL.
You might check the DLLs you're loading and the dependencies of these DLL's.
Here is my solution for this error:
(The Application was unable to start correctly (OXO15OOO20).Click to close the application).
From the Start menu, click Administrative Tools, and then click Windows Server Backup.
Click File, Click Option, and then in Disk Cleanup press Delete files and then press O.K,
and delete till it reaches to 0 byete
No Worry About it just it deletes the amount of disk space on your computer.