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 installed VS 2012 Professional and the XP update as well. I built my project with v110_xp as the platform toolset on VS 2012. My project's .msi package is installing fine on Win 7 but failing on Win XP SP3. The error reported on XP SP3 is -
"The procedure entry point FlushProcessWriteBuffers could not be
located in the dynamic link library Kernel32.dll".
While the same project built from VS 2005 is installing fine on XP SP3. I am not sure what is going on VS 2012. _WIN32_WINNT is set to 0x0501. Can some one please guide as how to resolve the problem ?
Any help is highly appreciated,
Mahesh.
Yes, the C Runtime has a dependency on FlushProcessWriteBuffers(). The updated version of msvcrt110.dll and libcmtl.lib, the ones you got along with the update, no longer directly link to the function, they use GetProcAddress() to find it and limp along if it is missng. So you should never get this error.
So very high odds that you deployed the wrong version of msvcrt110.dll, an old one instead of the updated one. You can find it back in c:\windows\system32, look at the properties. Mine is version 11.00.51106.1, dated 11/5/2012. A separate installer is available for it here.
The VS2012 runtime that you are installing uses functions that are not present available in XP. See this MS article: Targeting Windows XP with C++ in Visual Studio 2012 which explains more and provides some workarounds.
Update 1 for VS2012 resolve the problem.
But Update 1 isn’t just about new Windows platforms. It also enables you to target Windows XP with native C++ applications in Visual Studio 2012.
If you are building with update 1 and still encountering problems then I suspect that you are installing an out of date runtime. You need to deploy the runtime delivered with update 1.
You can solve this by including the VC11 merge modules from your development machine(program files\common files\merge modules) in your installer. It's easier than having to run the redist exe in your installer.
If you use WIX: merge module addition
I've tested on server 03, xp64 and xp32.
I have Windows 7 64-bit with Microsoft Visual Studio 2010 and subsequent installation of SP1.
If I open up Control Panels | Programs and Features, I see 3 entries for Visual Studio 2010, the third being one ADO.Net.
I tried to uninstall SP1 first and somehow that failed. It asked for the Visual Studio 2010 setup disk, which I put in. Sadly, after the completion, SP1 stayed in the Programs and Features list.
I tried uninstalling VS2010, which uninstalled nicely, but left the entry for SP1. I tried uninstalling SP1, but got a message that I had to have VS2010 installed, so I bit my lip, shoveled down my irritation, and reinstalled VS2010. I received only one option to install SP1, which I did. I guess you can consider that a reapply.
A refresh of Programs and Features showed once again 3 entries. I was able to uninstall SP1, at least the option was there and I was able to complete the uninstall. I kept the VS2010 disk in the CD tray. Sadly, closing Control Panel Programs and Features (CPPF subsequently) and reopening it, nicely showed Microsoft's bug invested SP1. Selecting to uninstall/change the entry results in a dialog to install SP1.
It appears that SP1 might be gone in part, but obviously not entirely. The entry, the executable/DLL tied to that entry is nicely there.
How do I remove/cleanup/delete/nuke VS2010 SP1 inclusive of CPPF and any other trash that it installed?
I just ran the web installer for VS2010 SP 1 with the following parameters. That forced it to uninstall and got me past the blocking issue:
VS10sp1-KB983509.exe /uninstall /force
I tried James solution above but it still didn't work and kept requiring the installation CD.
After further search I found this solution that worked for me:
Microsoft tool to remove Visual Studio 2010
As life moves on, I chose a chose maybe not the best solution, but it is a solution, so here is what I did.
I found an article, which talked about removing the entry from Control Panel | Programs and Features. http://www.roelvanlisdonk.nl/?p=1179. I then did other steps.
First from the link as I have a Windows 7 64-bit system, I went to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
in the registry. There were two locations, one the obvious with the name completely spelled out and the other with the DisplayName property set to the product name as part of a GUIID. I deleted both entries. The main entry with the nice name as the key was the one that deletes the program ID entry from the list.
I noticed that several products share the same InstallSource. That is bizarro (Smallville rocks and sadly ended), all in the C:\Windows\TEMP folder. As the actual setup program is under ProgramData folder, I am not sure what the TEMP folder entries do.
I deleted the ProgramData portion but left the C:\Windows\TEMP, although I am still thinking of cleaning that up, just am cautious.
I then deleted all other VS2010 components leaving the runtime. By the way, do not forget to delete Premptive's expensive and end user install based pricing product. That is further up (name sort ascending) under Dotfuscator...
That more or less cleaned things up. I am not sure what uses the VS2010 runtime, so I am leaving that. I assume that is what is installed at the VS2010 folder.
A side comment: I still find it strange that Microsoft in the registry follows a ...\Software\Microsoft\ entry. They do not follow that anywhere else. Why there?
Details:
In the registry, the information was:
{5AB7D739-1735-3A9E-BE73-C43507CB4E6F}
Uninstall String: MsiExec.exe /X{5AB7D739-1735-3A9E-BE73-C43507CB4E6F}
Install Source: C:\Windows\TEMP\Microsoft Visual Studio 2010 Service Pack 1_10.0.40219\
InstallLocation: C:\ProgramData\VS\vs10sp1\SetupCache\
Uninstall Path: C:\ProgramData\VS\vs10sp1\SetupCache\
Uinstall String: C:\ProgramData\VS\vs10sp1\SetupCache\Setup.exe
Shared products using C:\Windows\TEMP...40219 folder:
Microsoft SQL Server 2008 R2 Data-Tier Application Framework
Microsoft SQL Server 2008 R2 Data-Tier Application Project
Microsoft SQL Server 2008 R2 Management Objects
Microsoft SQL Server 2008 R2 Transact-SQL Language Service
Microsoft SQL Server System CLR Types
Microsoft Visual C++ 2010 x86 Runtime - 10.0.40219
Microsoft Visual F# 2.0 Runtime
Paths used by other products:
C:\Windows\TEMP\Microsoft Visual Studio 2010 Service Pack 1_10.0.40219\
C:\Windows\TEMP\Microsoft Visual Studio 2010 Service Pack 1_10.0.40219\Dotfuscator\
2 of several keys that share the same C:\Windows\TEMP folder entry (InstallSource):
InstallSource
{09C52940-A4D1-4409-A7CC-1AAE630CF578}
{1AA5BD63-6614-44B2-88A7-605191EDB835}
This answer on the MSDN forum explains a sequence for manual removal, but more importantly it also links to a Microsoft FixIt VS2010 Uninstall Utility which was the only way I was able to get rid of SP1.
None of the solutions here worked for me to remove VS 2010 SP1.
The visual stiduio 2010 uninstall utility worked nicely to remove everything but VS 2010 SP1.
to remove SP1 I went to the setup cache and ran setup as follows:
C:\ProgramData\VS\vs10sp1\SetupCache>setup /uninstall /force
I am in the process of evaluating an upgrade to Windows SDK 7.1
Part of my team's legacy codebase is a large number of ATL web services, which are still maintained using Visual Studio 2005 because (I am told) ATL web services are not supported in versions beyond 2005.
When I pointed the IDE to SDK 7.1, I began to receive the following link error:
uuid.lib(cguid_i.obj) : fatal error LNK1103: debugging information corrupt; recompile module
I haven't been able to find much on the web related to this problem in VS2005 and SDK 7.1.
I found some forum posts from back in 2005 about the same error -- they seemed to indicate an SDK incompatibility.
Based on the download page, I was under the impression that Windows SDK 7.1 could be used with Visual Studio 2005 (although I do note the "Not all features work with all versions of Visual Studio" disclaimer).
Is this a known issue, or have I got something configured incorrectly?
I was hoping someone could share their experience or suggest how/if I might be able to resolve this.
EDIT:
I discovered that this problem is circumvented by disabling /DEBUG on the linker command line. While allowing the build to complete, this is suboptimal as it precludes debugging during future maintenance.
The hotfix listed here appears to address the link error. Not sure how I missed it before.
Including here in case anyone ever searches for it using similar language.
Another developer and I are experiencing different behavior in native C++ executables built with Microsoft Visual Studio 2008, Version 9.0.30729.1 SP on different machines.
We are statically linking to the Standard Library so we don't think it's a DLL version issue. We have ruled out differences in our source code and build settings.
We theorized that perhaps we had different "hotfixes" installed on our separate machines that either affect code generation or perhaps have differences in their C++ Standard Library implementations.
We each used [Help | About Microsoft Visual Studio | Copy Info] to get version information and then diffed them. Sure enough, we found a few discrepancies. I have some hotfixes that my colleague does not. And he has a couple which are missing from my installation.
Here's an example hotfix entry from the version info:
Hotfix for Microsoft Visual Studio 2008 Professional Edition - ENU (KB953256) KB953256
This hotfix is for Microsoft Visual Studio 2008 Professional Edition - ENU.
If you later install a more recent service pack, this hotfix will be uninstalled automatically.
For more information, visit http://support.microsoft.com/kb/953256.
As you'll notice, link provided is dead. In fact, of the four differences we found, all but one have dead links:
http://support.microsoft.com/kb/948484 (dead link)
http://support.microsoft.com/kb/952241
http://support.microsoft.com/kb/953256 (dead link)
http://support.microsoft.com/kb/958357 (dead link)
Does anyone out there know how to actually find more info about these kinds of mystery hotfixes? Any advice on these particular ones? Short of each fully reinstalling Visual Studio, does anyone have tips on how we might get our separate installations synchronized, perhaps through removing and/or reinstalling hotfixes?
The main culprit for causing different behavior in native C++ apps would probably be:
KB958357
This seems to be an earlier version of what is now KB962219. Details are available in this posting on the Visual C++ Team Blog:
http://blogs.msdn.com/vcblog/archive/2008/12/17/vc9-sp1-hotfix-for-the-vector-function-ft-crash.aspx
This hotfix actually fixes 5 bugs:
function::swap() was broken by the Small Functor Optimization in VC9
TR1 (the Feature Pack). This broke
vector> in VC9 SP1.
"Broken" meant "compiling but
crashing".
vector> nonconformantly required X to have a
default constructor. (This is a
specific example of a general bug:
vector>,
vector>>, etc.
were also affected.)
vector> nonconformantly required X and Y to
have default constructors. (This is a
specific example of a general bug, see
above.)
vector> nonconformantly required X to have a default
constructor.
Random distributions were broken, triggering infinite loops and emitting
bogus results.
Those look like sufficient changes to cause differing behavior, but it all depends on your code. See if installing the latest version of that hotfix on each machine resolves the discrepancies you're seeing.
I'm not sure how much of a help this is but here is the information for the various hot fixes
948484 - Visual C++ 2008 SP1 Design-Time Components for x64
953256 - Visual Studio Team Explorer SP1
958357 - Appears to be a hot patch for TR1 after Visual Studio 2008 SP1 is installed
Based on the service pack details it looks like one of the following could be the differences between the machines
TR1 Hotfix: http://blogs.msdn.com/vcblog/archive/2008/12/17/vc9-sp1-hotfix-for-the-vector-function-ft-crash.aspx
One machine has Team Explorer and the other does not
The obvious one to throw out for completeness: one x86 the other x64.