I work on a machine with win 7 32bit on visual studio 2010.
I tried to run in release mode a code that work fine on other computer(win7 64bit), and the following message came up:
The program can't start because msvcp80.dll is missing...
I tried looking up at threads dealing with this problem. tried to install diffrent Redistributable runtime versions. tried to copy those files(msvcp80.dll,msvcm80.dll, msvcr80.dll) to the project dir. and some diffrent things I don't even realised what I'm doing.
maybe some other ideas?
OK
thanks for your answers.
before i started the project i confirm all the build dll are 32bit.
I work on a 'opencv' project and narrow the problem to this one: the only problem occurred on opencv_imgproc230 lib function (like cvtColor, GaussianBlur)' what cause me to check with the program above(the_mandrill's link) the includes at this dll. it's include(or point I guess) for msvcp100.dll what seems reasonable because i work on VS10 enviroment.but even though it's screams for msvcp80.dll what belongs to VS80 I think.
by the way, when i manually include (msvcp80.dll,msvcm80.dll, msvcr80.dll) it's screams:
"R6034 An application has made an attempt to load the c runtime library incorrectly..."
It's seems that it's need to tell him to work with the VS10 version(for this dll's/runtime library)
Install Dependency Walker and run in 'Profile' mode (f7) which will show you the dlls it's looking for and failing to find.
This just means that you link agains MSVC C runtime dynamically.
So you have to install the so called redist package.
msvcp80.dll -> VC 8 -> VS 2005
X86 – http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en
X64 - http://www.microsoft.com/downloads/details.aspx?FamilyId=90548130-4468-4BBC-9673-D6ACABD5D13B&displaylang=en
The dlls where installed to a central place by the redisrt package and should be resolvable after installation.
Can you check to see if your dlls are 32bit ? Maybe you have the 64 bit versions.
See How can I test a Windows DLL file to determine if it is 32 bit or 64 bit?.
See this question.
You mentioned that you've installed the VC8 redistribute packages, but you may have missed the "correct" one.
You probably want: Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update
Related
A client has recently given me some work involving their (old) VB6 program. I've successfully installed VB6 in a VM with Windows XP (32 bit), and it works just fine. The problem is when I try to open the client's program. The following messages pop up:
crystl32.ocx could not be loaded--Continue Loading Project?
FM20.DLL could not be loaded--Continue Loading Project?
After that there are a bunch of warnings cause of crystl32.ocx.
So I tried to register the dependencies with regsvr32, but it said that the modules couldn't be found, even though they were right there. Googling the problem took me to download Dependency Walker and find which dll files were needed for those files, which were:
msvcr100.dll
IEShims.dll
wer.dll
crpe32.dll
After downloading these dll files, I tried registering the first one, but it said that the "dllregisterserver entry point was not found". So I tried to unregister it first, but it couldn't find the module.
I've reinstalled VB6 several times, to no effect. Any ideas on how to make this work?
Crystl32.ocx and Crpe32.dll are Crystal Reports run time files.
FM20.DLL is Microsoft Form 2.0 Library with some standard GUI controls like label, text box, check box etc.
Msvcr100.dll is a part of
MS Visual C++ 2010 Redistributable Package
If there is an installer of your client's program you should run it before opening the source code with VB6 IDE. That way you’ll get all the dependencies required by VB6 program.
If not, please post the vbp file of your VB6 application.
thanks for all the help! The solution in the end was the installation of the CR 4.6 that the client later provided me with (as #BrianMStafford suggested), of VB6 SP6 and of Office 2007, together with SP3.
With that I've managed to get the project running, so thanks to everyone!!
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 have a problem with our executable. I'm running this C++ 32-bit executable on my Windows 7 64-bit development box that also has all those Microsoft applications (Visual Studio 2008 + 2010, TFS, SDK, Microsoft Office)...
And it's still running just fine.
Now I got the client installation of the very same program and was asked to test it with a clean Windows 7 installation. Thus I got one Windows 7 64-bit VMware and updated it to Windows 7 SP 1 (the very same version my developer box is tuning).
But while on my developer box everything is fine the program does not work with the VMware (30 days trial) box.
The x86 Dependency Walker is telling me that the following DLL files are missing:
API-MS-WIN-CORE-COM-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
DCOMP.DLL
GPSVC.DLL
IESHIMS.DLL
I googled for those API-MS-WIN-... DLL files and found they should actually already be part of Windows 7 (some sites claiming the belong to Windows 8 and Windows Server 2012 though).
I already tried the suggested fixes I found, which are:
running 'sfc /scannow'
installing Visual Studio 2008 SP1 runtime executables
But that didn't solve anything. :-(
Side note: My development box does not have them either, and does not seem to need them. For example, the user32.dll on my box does not link against one of those, while the installation on the VMware does.
Any idea on how to fix this issue?
I tried to find a suitable download / fix on the Microsoft pages, but I failed.
After solving my issue I wanted to report what I found out, and I can't post this as an answer because the question has been closed.
Actually all the DLL files reported missing by the Dependency Walker tool, namely those
* API-MS-WIN-CORE-...
type DLL files were not part of the actual problem.
In my case the registration of three OCX files was missing and after that everything was just fine, BUT Dependency Walker tool still listed all the very same DLL files as before even when the program was just running fine now.
The gist of it: As someone elsewhere stated, the tool is a bit dated by now and does not always work properly with a newer OS. Thus keep an eye open and don't get mislead by missing 'API-MS-WIN-CORE-COM-L1-1-0.DLL', ... the problem probably lies entirely elsewhere.
This problem is related to missing the Visual Studio "redistributable package." It is not obvious which one is missing based on the dependency walk, but I would try the one that corresponds with your compiler version first and see if things run properly:
Visual Studio 2015
Visual Studio 2013
Visual Studio 2010
Visual Studio 2008
I ran into this problem because I am using the Visual Studio compilers, but not the full Visual Studio environment.
Going to dare to inject a new link here: The latest supported Visual C++ downloads. Stein Åsmul, 29.11.2018.
I just resolved the same problem with C++ Qt 5 and Windows 7 64 bits with MSCVC 2012.
In the beginning I thought it was a MSVC/Windows DLL file problem, but as BorisP said, the problem was in my project dependencies. The key is "How to know your project dependencies in Qt 5?".
As I didn't find any clear way to know it (Dependency Walker didn't help me a lot...), I followed next the "inverse procedure" that takes no more than 5 minutes and avoid a lot of headaches with DLL file dependencies:
Compile your project and take the executable file to an empty folder: myproject.exe
Try to execute it, It will retrieve an error (missing DLL files...).
Now, copy all the DLL files from Qt (in my case they were in C:\Qt\Qt5.1.1\5.1.1\msvc2012_64_opengl\bin) to this folder.
Try to execute again, it will probably works fine.
Start to delete progressively and try every time your executable still works, trying to leave the minimum necessary DLL files.
When you have all the DLL files in the same folder it is easier to find which of them are not valid (XML, WebKit, ... whatever..), and consequently this method doesn't take more than five minutes.
I just resolved the same problem.
Dependency Walker is misleading in this case and caused me to lose time. So, the list of "missing" DLL files from the first post is not helpful, and you can probably ignore it.
The solution is to find which references your project is calling and check if they are really installed on the server.
#Ben Brammer, it is not important which three .ocx files are missing, because they are missing only for Leo T Abraham's project. Your project probably calls other DLL files.
In my case, it was not three .ocx files, but missing MySQL connector DLL file. After installing of MySQL Connector for .NET on server, the problem disappeared.
So, in short, the solution is: check if all your project references are there.
As mentioned, DCOMP is part of the VC++ redistributables (implementing the OpenMP runtime) and is the only truly missing component. All the rest are false reports.
Specifically API-MS-WIN-XXXX.DLL are API-sets - essentially, an extra level of call indirection introduced gradually since Windows 7. Dependency Walker development seemingly halted long before that, and it can't handle API sets properly.
So there is nothing to worry about there. You're not missing anything more.
A better alternative to find the truly needed DLL files that are missing (if that is indeed the problem) is to run Process Monitor and step backwards from the failure, searching for sequences of failed probes for a specific DLL file in all the system path.
I also ran into this problem, but the solution that seems to be a common thread here, and I saw elsewhere on the web, is "[re]install the redistributable package". However, for me that does not work, as the problem arose when running the installer for our product (which installs the redistributable package) to test our shiny new Visual Studio 2015 builds.
The issue came up because the DLL files listed are not located in the Visual Studio install path (for example, C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist) and thus had not been added to the install. These api-ms-win-* dlls get installed to a Windows 10 SDK install path as part of the Visual Studio 2015 install (e.g. C:\Program Files (x86)\Windows Kits\10\Redist).
Installing on Windows 10 worked fine, but installing on Windows 7 required adding these DLL files to our product install. For more information, see Update for Universal C Runtime in Windows which describes the addition of these dependencies caused by Visual Studio 2015 and provides downloads for various Windows platforms; also see Introducing the Universal CRT which describes the redesign of the CRT libraries. Of particular interest is item 6 under the section titled Distributing Software that uses the Universal CRT:
Updated September 11, 2015: App-local deployment of the Universal CRT is supported. To obtain the binaries for app-local deployment, install the Windows Software Development Kit (SDK) for Windows 10. The binaries will be installed to C:\Program Files (x86)\Windows Kits\10\Redist\ucrt. You will need to copy all of the DLLs with your app (note that the set of DLL files are necessary is different on different versions of Windows, so you must include all of the DLL files in order for your program to run on all supported versions of Windows).
This contribution does not really answer the initial question, but taking into account the hit-rate of this thread I assume that there are quite a few people dealing with the problem that API-MS-WIN-CORE- libraries cannot be found.
I was able to solve a problem where my application refused to start with the error message that API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL is not found by simply updating Visual Studio.
I don't think that my build environment (Windows 7 Pro SP1, Visual Studio Ultimate 2012) was messed up completely, it worked fine for most of my projects. But under some very specific circumstances I got the error message (see below).
After updating Visual Studio 11 from the initial CD-Version (I forgot to look up the version number) to version 11.0.61030.00 Update 4 also the broken project was running again.
This solved the issue for me:
Uninstall the Visual Studio 2010 redistributable package if you have it installed already, and then install Microsoft Windows 7 SDK.
I solved the problem. When I registered the OCX files, I ran it with the Command Window that had been executed as an administrator.
For anybody who came here, but with a Photoshop problem: my solution was to uninstall the MS VC++ redistributable first x86 and 64 both. Then install one appropriate to the Windows version and architecture (86 or 64).
Installation of SQL Server Management Studio 2014 on a freshly installed Windows 7 resolved this problem at our client after a two-day ridiculous battle.
I came here with this problem occurring, after trying a fresh Windows 7 OEM install, upgrading to Windows 10.
After some searching of Microsoft forums and such I found the following solution which worked for me:
Replace C:\Windows10Upgrade\wimgapi.dll with the one from C:\Windows\System32\wimgapi.dll
I suggest also checking how much memory is currently being used.
It turns out that the inability to find these DLL files was the first symptom exhibited when trying to run a program (either run or debug) in Visual Studio.
After over a half hour with much head scratching, searching the web, running Process Monitor, and Task Manager, and depends, a completely different program that had been running since the beginning of time reported that "memory is low; try stopping some programs" or some such. After killing Firefox, Thunderbird, Process Monitor, and depends, everything worked again.
I had the same problem. After spending hours searching on the web, I found a solution for me.
I copied the file combase.dll file (C:\Windows\System32) to the release folder, and it resolved the problem.
Just to confirm answers here, my resolution was to copy the DLL that was not loading AND the ocx file that accompanied it to the system32 folder, that resolved my issue.
Hey guys so I made a small program in visual c++ 2008 so that other people could use.
I sent the exe that was located in the debug folder of the project to my friends.
When they tried clicking it this is what they got:
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.
Does anyone know how I can fix this?
Maybe a build/compile option in Microsoft Visual Studios 2008/2010?
Or will they have to download something?
First step is to do a "Release" build. When you do a debug build your are linked to the Debug version of the CRT (C Runtime). Windows definitely does not come with the debug CRT (unless your friends install VS2008 also) and you are not allowed to redistribute the Debug CRT version.
Simply doing a release build may be enough. VS 2008 has been around long enough that your friends computers may already have the release version of the CRT.
If this does not work, point your friends to http://www.microsoft.com/en-us/download/details.aspx?id=29 so they can download and install the files they need.
And if that is not enough, you may need to keep track of which service pack of VS 2008 you built with because that may affect which version of the CRT they must download and install.
Anyways, good luck. Hope this helps.
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