I've created a small text adventure. I've built the solution with Visual Studio Community 2019 using Release and x64 settings. I've zipped up the *.exe file along with the other generated files and sent them to another pc that doesn't have VS installed and the error you see in the image came up. I've searched my pc and the file exists in a couple of different folders, one of them being system32 so i don't know where to place the file on the new pc.
Any help would be appreciated. Thank you
Per #user4581301's comment, the answer is to download a current Microsoft Visual C++ redistributable for the appropriate architecture (i.e. x64).
As I already had a 2019 of the redestributable installed, I had to install the corresponding 2015-2019 x64 distributable.
I have tried the most voted solution and was still missing it. Found out that MS actually has a different version of VC redist inside Visual Studio download page. Look inside the Other Tools section. After installing that, one missing DLL was added.
I was getting the same error and installed VCRUNTIME140_1.dll file and put it in the MySQL Shell 8.0 bin file.
Problem solved.
I was also facing this issue. The below solution worked for me.
Solution:
Download the VCRUNTIME140_1.dll file
Place it in the path - C:\Windows\System32
Check if it solves your problem.
Download and install both the x86 and x64 versions of the Microsoft Visual C++ 2015 - 2019 Redistributable here
I cannot start Visual Studio Professional 2017 after update, it only appears less then 1 second and disappear. I'll try to repair, uninstall and install fresh new one, but I get same problem. Maybe someone had same problem ? What kind solutions you made ?
Please first check the system requirement here:
https://www.visualstudio.com/en-us/productinfo/vs2017-system-requirements-vs
If your system requirement is satisfied, then remove all the old cache file like disk cleanup, %temp% files. Restart the system and try to install and run.
thanks
I was going to program a game of Snake using SFML, and after downloading SFML, I tried to create a WIN32 Windows Application, and when I clicked finish in the Wizard, I got the following error:
Unable to read the project file "SFML-Snake2.vcxproj".
C:\Users\arnav_1n7er7u\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.Win32.user.props(0,0): The project file could not be loaded.
Root element is missing.
This can be seen in the following screenshot, although it may be unclear:
So to try and solve this problem, I went to the appropriate directory and opened the file Microsoft.Cpp.Win32.user.props in Notepad. After doing so, I found something unusual: The file was full of whitespace, and the exact whitespace content was as follows:
Whitespace
(The word whitespace wasn't written there, I just wrote it for the formatting).
In fact, there were two other files in this directory, and when I looked at them, they were also full of whitespace. I have a feeling that is the problem since it is unlikely Microsoft switched to the Whitespace Programming Language, but I have absolutely no idea what is supposed to be in the file. Could I be pointed in the right direction, to see what the problem is, and how to fix the Visual Studio error message so I can create my project?
UPDATE
Ok, to try and fix the problem, I uninstalled Visual Studio 2015, and instead now downloaded the new Visual Studio 2017. In this, I tried to create another WIN32 Windows Application, and got the exact same error, which can be seen as follows:
This time, I tried to open the file Microsoft.Cpp.Win32.user.props and now found this content (For some reason I cannot copy and paste it):
Now I am really confused. For some reason, now I cannot create WIN32 Applications in Visual Studio, whether it is 2015, or 2017. What should I do?
Yes! I figured out how to solve the problem. After reading this MSDN link, I followed the accepted answers idea to delete the files in the directory v4.0. After doing so, I created a new project, and Visual Studio was able to do so because it generated new files in place of the corrupted ones.
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 visual studio 2010 ultimate version and everything worked perfectly fine and my development environment worked well.
However I had a recent problem in which every piece of code gives me the error about header files not being found like iostream stdio.h conio.h etc.
I pinpointed the problem to it being caused by me uninstalling visual C++ express 2010 that I had installed previous to the installation of the visual studio 2010.
I tried to completely uninstall and install Visual Studio but it seems some files are always left that I cannot track. I used this link and the answer marked right over there to no avails. Can anybody advise me how to get it right without formatting the whole system.
Link to Question
I seem to have solved the problem using another answer on Stack overflow.
The answer points to this link from Microsoft Connect.
The steps I followed to solve the problem are listed below.
Uninstalled visual c++ using the following vs2010_uninstall tool from Microsoft and used the switches /full /netfx while uninstalling(use command line instead of double click) as follows: VS2010_Uninstall-RTM.ENU.exe /full /netfx
Uninstall Visual Studio Service Pack 1 if its installed
Start Registry Editor in Windows: Win+R type Regedit to open Registry Editor. Do remember to backup your registries and create a restore point.
Search for the key named PaddedVersion
If the search key is found and look at keys ending with VisualStudio\10.0\VC\Libraries or VisualStudio\10.0_Config\VC\Libraries
Delete all keys and subkeys under the VisualStudio\10.0\VC\Libraries or if that doesn't work delete all keys and subkeys under VisualStudio\10.0 or VisualStudio\10.0_Config. The catch here is that all keys must be deleted regardless of their prefix to the above mentioned string as HKEY_LOCAL_MACHINE or HKEY_USERS etc. It has to be deleted in all cases.
Note the PaddedVersion just helps you in finding all such keys.
Once done restart(not compulsory but better if you do it) Windows. Now you are ready to begin re-installation of your version of Visual Studio 2010.
Hope it helps all who are having such a problem..
After trying this, and countless other solutions over the past six months, the solution that worked for me was as follows:
1) Right Click project
2) Select Properties
3) Select Configuration Properties > General > Platform Toolset
4) When you get to Platform Toolset, click on the v110 value which will be in the right column. You will see a drop down appear which will allow you to select v90, v100, or inherit. Of course, v100 is the correct answer. Once v100 is selected, I don't believe you can back to v110 from within VS 2010. You would have to once again open in in VS 2012 to move it back to v110.