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 just completed my application development efforts on a D2D1 application using Visual Studio 2010 IDE in C++. I was exploring different ways of creating a package from this and used the built-in Visual Studio installer/setup. The setup project compiled smoothly and an install file was created. I was also able to successfully install the application according to my requirements. However, when I install it in the default location (which would be my preferred location - C:\Program Files(x86)), the application refuses to launch. Here is the debugging I was able to do so far:
Installed in C:\Program Files(x86): Application does not launch normally.
Installed in C:\Program Files(x86): Application launches when "Run as administrator"
Installed in a location other than %ProgramFiles% or %ProgramFiles(x86)%: Application launches normally without having to "Run as administrator".
I have tried cornering the error cases, but don't have anything conclusive or convincing so far, which is why I am seeking the experts help here. What I have done further:
Used Dependency Walker x86 version to figure out where/what the dll calls are through the profiler. It did not provide me with anything concrete - depends.exe believes my application has delay-load dependent modules GPSVC.dll and IESHIMS.dll and I am fairly certain that I don't need those. The profiler also indicates a CRT 0xC0000417 error - but it is difficult for me to say if it is related at all.
I do have a manifest defined for my visual styles as a pragma. Removing this did not help.
If this helps - my C++ project manifest file options in the Linker settings looks like this:
Generate Manifest - Yes
Allow Isolation -Yes
Enable UAC - Yes
UAC Execution level - As invoker
UAC Bypass UI Protection - No
I have converted all CRT functions to it's secure version (sprintf -> sprintf_s) as recommended by MSDN documentation. Is this even related here?
I have tried simply copying the .exe to %ProgramFiles(x86)%. It did not help - so it appears that my installer is not the one creating the problem.
I use _dupenv_s in several places within the code to retrieve %COMSPEC% , %TEMP% etc.
Any pointers to how I can proceed further with the debug is highly appreciated. I did read around about this and some experts suggest incorrect string handling or large or invalid directory names; but I don't see that as relevant in my case since the issue is unique to launching the application normally under %ProgramFiles(x86)% .
Other details:
* OS Windows 7 - 64 bit, Vista with latest SP - 32 bit
* Visual Studio Professional 2010, C++ Project with .Net client profile target
Visual Studio Installer; Target platform 32 bit
* Nature of application - Direct2D based
Pardon me if I did not use the correct technical terms. I am a novice in application deployment.
That is correct Viswanathan, you cannot write to Program Files/Program Files(x86) if you are not running from an elevated process.
If your application needs to write custom settings in a file when it is launched you should create a dedicated folder for it under CommonAppDataFolder
I'm re-writing a console application using Visual Studio 2010. The original application was written using Visual Studio 2008 and works OK, but has no tests associated with it. Hence, the idea of re-writing it with tests.
Both applications are working with a Sharepoint 2007 site.
The project compiles but when I try and run it the code below is throwing errors.
SPSite spsite = null;
SPSecurity.RunWithElevatedPrivileges(delegate() {
spsite = new SPSite("http://sharepointdev");
});
return spsite;
I'm running this on Windows Server 2008. I've set the platform target of the build to be x86 (this is in the properties of my project) and in Security I've checked that this is a full trust application. I'm also running the project as an administrator. I've also set the .NET Framework to be 3.5
Is it just a case that SharePoint 2007 just doesn't want to play with Visual Studio 2010, or is there something else I've not yet considered?
I've tried searching on the web and stackoverflow but all the articles I've seen deal with trying to get Visual Studio 2010 to work with Sharepoint 2010.
The exact error I get is 'Object reference not set to an instant of an object' with the debugger high-lighting the SPSecurity call.
If I just use this code
using(SPSite spsite = new SPSite("http://sharepointdev")){
Then I get a FileNotFoundException, which isn't exactly true! I've got plenty of applications that do find a site using that URL. What I suspect the error message is trying to say is that my 2010 application is not being allowed to access the site, but I've not found any clues as to why that should be.
Any clues, hints or suggestions gratefully accepted.
EDIT
I've lifted the code from my VS 2010 project and dropped it into a new VS 2008 project and it ran straight-away.
FURTHER EDIT
I created a simple little console application in VS 2010. By default it uses .NET Framework 4, I had to set this to .NET Framework 3.5. I also set the platform target to be 'Any CPU' and it works. This makes me wonder if there is an issue with the Test Project associated with my first application?
I re-created the console application but this time without a Test Project associated with it (the test project was a class library and worked with NUnit). It ran with no problems. I guess the problem lies within the test project and something there that the solution doesn't like. Probably there's a build there it doesn't like
TL;DR; answer: Switch to Any CPU build - don't choose x86.
I've run into this problem before with a console utility. I got the same FileNotFound error but it's referring to the DLL, not your SharePoint site. Digging a bit I discovered a deeper error of BadImageFormat and realized it was complaining about a DLL or EXE. I guessed it was due to the linking from x86 to MSIL. There's a lot of things that have to happen to marshal calls between the two and I guess it led to an incompatibility. When I switched it (and verified all my support library projects) built to MSIL/Any CPU the application worked with no problems and no other changes.
I use Visual Studio 2010 to develop for SharePoint 2007 all day for a long time now and the only problems I've encountered aren't related to that combination. More often than not it's a quirk of a 3rd party add-on I'm using. For almost all of my development I start with the WSP Builder templates but they are buggy and have a few quirks you have to work around (some severe enough to take down your SharePoint server) so I don't blame VS 2010 directly.
(I'm running Windows7 and using Visual Studio 2010.)
I'm using ClamAV in a .NET Azure project, and I'm running into side-by-side errors whenever I run clamd.exe, either through my code or by running clamd.exe on it's own.
In Visual Studio 2010 I am getting the error:
Win32Exception was unhandled 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
And in Event Viewer I get:
Activation context generation failed for
"C:\Users\pconerly\code\AntiVirus_source\WorkerRole\clamav\clamd.exe".
Dependent Assembly
Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.6195"
could not be found. Please use sxstrace.exe for detailed diagnosis.
When I searched for "8.0.50727.6195" it led me to the 2005 redist, so I downloaded it
http://www.microsoft.com/download/en/details.aspx?id=3387
After a restart I am still getting the side-by-side error. Additionally, I think that the redist installer is not completing it's install-- like it's seeing visual studio 2010 and saying "oh, that's good enough, no need for me to install". I haven't tried uninstalling 2010 and using 2005, because the rest of my Dev team is using VS 2010.
What's the deal? How can this be fixed? I'm ready to pull out my hair.
The link Timores posted is the update for Visual Studio. The actual redistributable package is this:
http://www.microsoft.com/en-us/download/details.aspx?id=26347
The version you mention is actually at found here
Microsoft Visual Studio 2005 Service Pack 1 MFC Security Update
Timores is right: the redist should be this one, which is related to this KB entry
As you can see there, msvcr80.dll has been updated to version 8.0.50727.6195.
It is the "security update" of the "SP1" of the 2005 C++ runtime..
Your exe probably requires (through an internal manifest) that specific version.
If it is not found on the system (there's a lot of places searched for) nor in the current folder (with a suitable manifest aside) it won't load the exe since it is not able to "activate the context", that is load the specific DLL required in the manifest.
I had similar issues when my system got updated (windows updates) and the newly compiled EXEs were not working with an old-versioned runtime placed on the same folder.
I had to update msvcr80.dll and its manifest (which I found deep in \windows\winsxs) to make everything work.
Context activation is a tricky matter, anyway :)
HTH
I'm trying to create an absurdly simple shell extension in C++ using Visual Studio 2010, but I can't even seem to get the examples out there to work as a starting point.
I'm using Windows 7 x64.
I've tried this Visual Studio template, but once I get the template to work in VS2010, I have a host of errors that I'm not sure how to fix.
I've tried The Complete Idiot's Guide to Writing Shell Extensions, and once the demo compiles all the right registry settings etc. are created but no context menu appears.
I've looked at this C# COM Interop example, but I've been left confused as to whether it is safe to use C# thanks to this article*, but it looks like I might be OK if I use .NET 4 because it supports in process side-by-side CLR hosting.
in short: historically two versions of .NET cannot run in the same process, and the way shell extensions work is they inject themselves into a process. So if .NET 3.5 gets injected into a .NET 2 process - bang
So, can I use .NET 4.0 now?
Is there a working, downloadable, VS2010 solution that adds a simple shell extension?
I used to be not so bad with C++ back in the day, but after years of moulding to .NET I'm quite rusty, and as such, fiddling with the details to fix the host of errors I'm getting on the existing examples is proving... fiddly!
I could really do with a clean slate to start with that I can break myself and figure out what I did wrong!
I struggled with this for a while and had limited success with the code project article due to x64 issues and SDK differences.
I recently picked the project back up and started over using the MS all-in-one code sample and I am very pleased. It makes a simple example context menu and x64 works out of the box: http://code.msdn.microsoft.com/windowsdesktop/CppShellExtContextMenuHandl-410a709a
To get it running on your machine:
download the code via the all-in-one sample browser or use the direct link.
Open project in VS under admin rights
switch build config to x64 and build it
Kill all explorer sessions
Locate the new dll and run regsvr32.exe .\CppShellExtContextMenuHandler.dll
open explorer again and right click a .cpp file to see the new menu
remove it by running same command with /u flag
My next step is to get debugging working and I think this may do the trick: msdn
On Windows 7 x64 for a C++ extension you need to build it as an x64 project. In Visual Studio 2010 there is an option on the ATL Wizard to create a shell extension project that provides preview window support, thumbnails and Windows Search support. I recently used this and once built, nothing seemed to happen. However, switching the project configuration to build an x64 dll got it working.
With regards to using .Net - Explorer now launches plugins in a separate sub-process. So loading a shell extension that links to .net 4.0 does not contaminate everything with that version of .net as only the hosting subprocess will actually load that CLR. You can see this using a preview extension as a new process (prevhost) gets launched to contain this.
I got this one working: http://www.codeproject.com/Articles/174369/How-to-Write-Windows-Shell-Extension-with-NET-Lang
Make sure you use the right RegAsm.exe for de/registering it:
32-bit platforms: Compile for x86/Any CPU. Use C:\Windows\Microsoft.NET\Framework\vXYZ\RegAsm.exe.
64-bit platforms: Compile for x64/Any CPU. Use C:\Windows\Microsoft.NET\Framework64\vXYZ\RegAsm.exe.
(XYZ is the version of the .NET Framework you used for compiling.)
Note, however, that Microsoft recommends against using .NET for shell extensions.
The short answer to your 'can I use C#' is no. This is from Microsoft’s Guidance for Implementing In-Process Extensions. "One runtime of particular note is the common language runtime (CLR), also known as managed code or the .NET Framework. Microsoft recommends against writing managed in-process extensions to Windows Explorer or Windows Internet Explorer and does not consider them a supported scenario."
The problem arises because only a single version of .NET can be used in an application and there is no way to enforce that limitation if multiple .NET extensions are in use.