Related
I have an Excel workbook that calls a test DLL I wrote in C++. The path to DLL is hardcoded in VBA. The only files the DLL uses are stdlib and iostream.
On my machine it works. On several other office machines it works. However, on the remainder when i try to call the DLL through Excel I get error 48 - file not found.
My understanding is error 53 is the file is missing; error 48 is there are missing dependencies. I have used dependency walker and have not found any issues.
What I did discover, however, is that if I install Visual Studio on a machine there is a 90% chance that after the install the Excel file/DLL works perfectly. On the 10% that it does not work, I restart and re-run the Visual Studio install, selected 'repair', and after the installation finishes again the Excel/DLL combo works. So basically installing Visual Studio allows the DLL to be loaded by Excel. If i uninstall Visual Studio the DLL still works fine.
Obviously this means something is missing on those machines, but I have no idea what - I've tried separately installing all the pieces that show up under 'programs', such as most current .net framework, visual c++ re-distributables, etc... and it doesn't work. The only thing that works is installing Visual Studio itself.
I'm not certain how to proceed since asking users to mount a 5gig ISO and install a developer environment isn't really ideal.
Ah-ha, I found the issue. It turns out that it requires 2 DLL files - msvcr120.dll and msvc120.dll. I had these 2 files in my System32 folder, but not in my SysWOW64 folder. As soon as i populated that folder then the DLLs started working.
I found many threads on google with the 'same' problem but no answer, so if you run into the same issue I'd suggest using dependency walker and making sure the DLLs are in both system folders to be safe (although I suspect System32 is only needed for 64bit DLL, and SysWOW64 for 32bit DLLs).
Most probably your DLL depends on C++ redistributables. Depending on the version of VC++ you have used to develop your DLL, you should install the relevant version of VC++ redistributables on the target machine.
In case of VS 2015 you can find VC++ redistributables here:
https://www.microsoft.com/en-us/download/details.aspx?id=48145
Use the SysInternals Process Monitor utility to monitor DLL access and look for errors. An example is in this other answer. Watch the Excel process and the CreateFile operation.
Ah-ha, I found the issue. It turns out that it requires 2 DLL files - msvcr120.dll and msvc120.dll. I had these 2 files in my System32 folder, but not in my SysWOW64 folder. As soon as i populated that folder then the DLLs started working.
I found many threads on google with the 'same' problem but no answer, so if you run into the same issue I'd suggest using dependency walker and making sure the DLLs are in both system folders to be safe (although I suspect System32 is only needed for 64bit DLL, and SysWOW64 for 32bit DLLs).
Error 48 can also be returned when the dll does not correspond to the bitness of the calling program. So, if you're runnning Excel's VBA with Excel 64-bit, for example, you want to make sure the DLL is compiled as a 64-bit binary.
Note this is different from error 53 wich really means the DLL is not found in any paths.
An old MFC application now rebuilt in Visual Studio 2015 Community which uses an old DLL, I'm trying (and tearing my hair) to determine exactly what runtime DLLs are required to properly run the application on machines which doesn't have VS installed.
Target OS is Windows 7. It's a 32 bit application.
The application uses a DLL MAuEASE_s.dll, which uses mfc80.dll and msvcr80.dll DLLs. I don't have the source code of MAuEASE_s.dll so I cannot rebuild/replace it.
On my development machine, the application runs fine with the following set of files put into the same folder:
main executable
MAuEASE_s.dll
mfc80.dll
msvcr80.dll
an ini file required to run the software
To test how it will behave in client machine, I'm using the same set of files on a fresh copy of Windows 7 on a virtual machine. The problem only appears to be specific to mfc/msvcr dependency of MAuEASE_s.dll.
On my machine, even though I've put the DLLs in executable's directory, they are picked from the following folder (found from Dependency Walker):
c:\windows\winsxs\x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.6195_none_cbf5e994470a1a8f\MFC80.DLL
c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6229_none_d089f796442de10e\MSVCR80.DLL
I've copied exactly these two DLLs in executable's directory, then copied the directory into virtual machine running Windows 7. There, Dependency Walker shows error for MAuEASE_s.dll:
The side-by-side configuration information for MAuEASE_s.dll contains error.
Screenshot:
Interestingly, from the manifest of MAuEASE_s.dll I found that it needs 8.0.50727.4053 version of both of the DLLs. But the DLLs found in development machine's c:\windows\winsxs have versions 8.0.50727.6195 and 8.0.50727.6229 but these DLLs still work on development machine.
I've searched the Windows directory for version 8.0.50727.4053 of the DLLs and found them and replaced them in the application's executable directory. The application still works on the development machine.
None of these versions work in the virtual machine.
What's going on and how can I find the exact DLLs to run the application in a PC where Visual Studio is not installed?
My answer doesn't target the problem how to fix the WinSxS error. It just shows how you can force the system to load the application local MFC DLLs.
The MFC80. DLL belongs to VS-2005. They introduced loading DLLs for the MFC side by side. So the Manifest inside the DLL tells the loader to find a public version in the WinSxS directories.
Even if you don't have the source of the MAuEASE_s.dll you can change the behaviour just in changing the embedded manifest. It is just a XML block.
You can just open the DLL in VS and you can modify the resource there. (Export/Import it). Or use another tool to modify the resources of an executable (Resource Hacker etc.)
Long time ago I wrote an article to use the MFC DLL as a private assemblies in your application directory. You just need to remove one token from the manifest. See here.
Alternativly you can create a new manifest as described in the article and replace the existing one with mt.exe.
Binaries built with Visual Studio prior to Visual Studio 2010 referenced dependent DLLs through a manifest (embedded or external). Dependencies referenced through a manifest are searched for in the native side-by-side assembly cache (WinSxS folder) only. The application's directory is not searched. To verify, whether a binary contains an embedded manifest you can use the manifest tool Mt.exe:
mt.exe -inputresource:<filename of binary> -out:manifest.txt
To deploy an application that references DLLs through a manifest, or references DLLs that do, you should deploy those binaries using the respective vcredist_<architecture>.exe download.
If you would rather not have to install files into the native side-by-side assembly cache (because your installer should not need admin rights, for example), you would need to modify the binary (MAuEASE_s.dll in your case). To do so you can retrieve the original manifest first (see above), update the manifest by removing the respective assembly references, and replacing the original RT_MANIFEST resource (using a resource editor like Visual Studio, or Mt.exe):
mt.exe -manifest manifest_new.txt -outputresource:<filename of binary>
Once that's done, you can deploy the DLLs alongside the binary that references them. Note, that this no longer allows you to link against a specific version of a DLL.
As xMRi and IInspectable suggested, I was able to modify the manifest inside the DLL to force load the particular DLL I put in the executable's directory. But it didn't solve the problem. Whenever I was launching the application on the fresh PC, I got the following error:
The application was unable to start correctly (0xc0150002).
In my development machine, I had tons of Visual C++ redistributable versions installed and I found several versions of mfc80.dll and msvcr80.dll in Windows directory. I copied all possible combinations of these two files of different version one by one and tried to launch the application. But it didn't work.
What did work is (what I wanted to avoid) - I opened the uninstall program window from control panel. There I found 3 different versions of Visual C++ 2005 redistributables are installed:
8.0.61001
8.0.50727.42 (this is x64 version)
8.0.56336
I started looking online for these installers. On the fresh PC I started installing the redistributables one by one and trying to launch the application. Finally I found that after installing version 8.0.61001, which is Visual C++ 2005 redistributable SP1 with MFC security update, the application successfully launched.
Now I'm going to pack the installer of this redistributable in my application's installer.
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.
I created a client server application in C++ using Visual Studio.
Now I want to run the client EXE file on another computer (which doesn't have Visual Studio installed),
but when I try run the EXE file, it gives the following error message:
This application has failed to start because the application
configuration is incorrect. Reinstalling the application may fix this
problem.
How can I run the EXE file without installing anything on the computer?
Applications built with Visual Studio depend on Visual C++ Redistibutable (VCRedist). When the program is being linked dynamically, then your binaries will need
MSVCR**.dll (Microsoft C Runtime Library).
On MSDN, there is a nice article called Redistributing Visual C++ Files (for Visual Studio 2008), that states that there are Potential run-time errors in case that required Visual C++ library is not installed:
you may get one of the following error messages depending on the version of Windows on which you try to run your application:
The application failed to initialize properly (0xc0000135).
This application has failed to start because the application configuration is incorrect. Reinstalling application may fix this problem.
The system cannot execute the specified program.
Basically you have two options:
The simplest possible solution is to change the dynamic linking of runtime libraries to static linking. Go to project properties and under C/C++ → Code Generation you will find Runtime Library option. You need to change it from Multi-threaded DLL (/MD) to Multi-threaded (/MT).
Another possible solution is to make sure that the right version of Microsoft VC++ Redistributable Package is installed on the target machine.
But your application might depend on other DLL files as well. In case you want to find out what are the dependencies of your program, there is a great utility called Dependency Walker that will help you in this and many other situations :)
Background:
C++ applications need run-time assemblies (DLL files) to run in any Windows computer.
Normally these run-time assemblies are located at C:\Windows\Winsxs directory.
All the Windows operating systems by default comes with several run time assemblies.
But if your application is developed in a newer version of the run-time assembly environment, the target computer also needs the same version of the run time to exist there.
When you're installing Visual Studio, most newer versions of the run-time assemblies comes to your computer.
Solution:
Finally by anyway the target computer should have the exact run time assemblies. There are a few ways to do this (for more details search each in Google).
Statically link run-time assemblies with your application (troublesome for large application).
Install the C++ redistribution environment on the target computer (the easiest way).
Creating a setup project to deploy the run-time on the target computer when installing the application (not bad).
For deploying run-time assemblies as private assemblies (professional), see here for more details
Conditions:
You must not use .NET framework in your application.
You must not use the common language run-time support for your application
I deployed my program in release instead of debug, and the EXE file now works on the other computer.
I haven't seen that specific error before. Usually it's an error around a missing DLL (Windows redistributable). Assuming there isn't actually a problem with the configuration, you have two choices:
Change the compile mode from Multithreaded DLL to Multithreaded. This can be done from the C++ section of project properties under code generation. In multithreaded mode your binary will be statically linked against the Windows redistributable. This is probably what you want.
Install the Windows redistributable on the target machine. This probably isn't OK, because you state that you don't want to install anything on the target machine.
A warning about option 1: Different versions of Windows have different versions of the redistributable. It's possible to encounter a highly specialized environment in which a statically linked program will not behave as expected.
It look like you're missing some DLL files. Be sure to copy appropriate DLL files along with EXE file.
I am running Visual Studio 2019 and I found a very helpful configuration property to address the problem of moving a simple application to another computer without an installation package.
Open the project Property Pages.
Choose which configurations this change should apply to, I used “All Configurations”.
In the left-hand window click to expand the top node called “Configuration Properties”.
Click on "Advanced". In the right-hand window look for the property called “Copy C++ Runtime to OutDir” and set that to “yes”.
Click OK to close the Properties window.
Rebuild your project. All the necessary dlls will be copied to the project’s output directory. Copy your exe and all dlls to another computer. The exe should find everything it needs to run.
My C(++) program, written and compiled using Visual C(++)/Visual Studio, runs fine on my own machine, but refuses to run on another machine. The error message I get is "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."
If you write a C++ program, it links dynamically to the C Runtime Library, or CRT for short. This library contains your printf, your malloc, your strtok, etcetera. The library is contained in the file called MSVCR80.DLL. This file is not by default installed on a Windows system, hence the application cannot run.
The solution? Either install the DLL on the target machine through VCREDIST.EXE (the Visual C++ Redistributable Package), or link to the CRT statically (plug the actual code for the used functions straight into your EXE).
Distributing and installing VCREDIST along with a simple application is a pain in the arse, so I went for the second option: static linking. It's really easy: go to your project's properties, unfold C/C++, click Code Generation, and set the Runtime Library to one of the non-DLL options. That's all there is to it.
The problem here is a missing DLL dependency, such as the CRT (C Runtime Library). A good tool for diagnosing this sort of problem is Dependency Walker (depends.exe), which you can find here:
http://www.dependencywalker.com/
You would run this program on the computer that generates the error message you posted, and use it to open the exe that's generating this error. Dependency Walker will quickly and graphically indicate any DLLs that are required but not available on the machine.
Chances are high that you miss the runtime libraries of Visual Studio (CRT amongst others), you can either get rid of those dependencies (link statically) or install the VC redist packages on the target computer.
Depending on the Visual C++ version you use, you have to install different packages :
Visual C++ 2005
Visual C++ 2005 SP1
Visual C++ 2008
Warning : those packages only contain release versions of the libraries, if you want to be able to distribute debug builds of your application you'll have to take care of the required DLL yourself.
It is much the simplest to link to the runtime statically.
c++ -> Code Generation -> Runtime Library and select "multi-threaded /MT"
However, this does make your executable a couple hundred KByte larger. This might be a problem if you are installing a large number of small programs, since each will be burdened by its very own copy of the runtime. The answer is to create an installer.
New project -> "setup and deployment" -> "setup project"
Load the output from your application projects ( defined using the DLL version of the runtime ) into the installer project and build it. The dependency on the runtime DLL will be noticed, included in the installer package, and neatly and unobtrusively installed in the correct place on the target machine.
The correct VC Redist package for you is part of your Visual Studio installation. For VC 8, you can find it here:
\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86
POSSIBLE SOLUTION........
EDIT: (removed most of my post)
Long story short, I was having similar problems, getting the "Application Configuration Incorrect" messages, etc etc.
Depends.exe was only finding ieshims.dll and wer.dll as possible issues, but this is not the problem.
I ended up using the Multithreaded (/mt) compile option.
What HAS worked though, as a workable solution, is making an installer with InstallShield.
I've selected several merge modules in installshield builder and this seems to have fixed my problem. The modules selected were:
VC++ 9.0 CRT, VC++ 9.0 DEBUG CRT, and the CRT WinSXS MSM merge module.
I'm pretty sure its the WinSXS merge module that has fixed it.
DEBUG CRT: I noticed somewhere that (no matter how hard I tried, and obviously failed thus far), my Release version still depended on the DEBUG CRT. If this is still the case, the InstallShield merge module has now placed the DEBUG CRT folder in my WinSXS folder :) Being somewhat of a novice with VC++ I assume that this would normally be used to distribute debug versions of your programs to other people. To test if this is what fixed my problem I removed the DEBUG CRT folder from the WinSXS folder and the application still worked. (Unless something is still running in the background etc etc - I'm not that into it)
Anyway, this has got things working for me on an XP SP3 fully updated machine, and also on a VMWare XP SP3 machine with the bare bones (.net 3.5 and VC++ 2008 RTM basically) - and also on a mate's XP machine where it previously wasn't working.
So give these things a try, you might have some luck.
First thing you must use
#define _BIND_TO_CURRENT_VCLIBS_VERSION 1
or add _BIND_TO_CURRENT_VCLIBS_VERSION=1 to the preprocessor directives.
The problem is related to binding and the manifest types, you can find more http://www.nuonsoft.com/blog/2008/10/29/binding-to-the-most-recent-visual-studio-libraries/
By doing this your application will run with a larger range of runtime libraries versions.
Often times this error is the result of attempting to run the debug version of an application that uses .NET. Since the .NET redistributable package doesn't include the debug versions of the dlls that are installed with Visual Studio, your application will often get this error when running it on any other machine that doesn't have Visual Studio installed. If you haven't already, try building a release version of your application and see if that works.
Note also - that if you change to static runtime, you will have to do the same for MFC if your app uses MFC. Those settings are in properties->Configuration/General
I ran into this problem and was able to fix it very simply.
Visual studio gives you the option (on by default) to build a manifest for each build.
The manifest was put in the release folder, but it was a different release folder than the exe.
Even when using the setup utilities it was not packaged.
You should look for a file names something like myprogram.exe.indermediate.manifest
If this is in the same folder as the exe (and you have all the dlls) it should run