I have a friend who's taking over a Visual C++ project from me and is having trouble running it. It's a graphics application and it uses the Qt GUI library. The reason I mention this is because of the error below.
He can build and link the program using Visual Studio 2010, but when he runs it this message comes up in the event viewer:
Activation context generation failed
for
"D:\Test\Qt\4.2.2\bin\QtGuid4.dll".
Dependent Assembly
Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",
type="win32", version="8.0.50608.0"
could not be found. Please use
sxstrace.exe for detailed diagnosis.
When we do as the message asks and run sxstrace.exe, here's what we see:
Begin Activation Context Generation.
Input Parameter: Flags = 0
ProcessorArchitecture = Wow32
CultureFallBacks = en-US;en
ManifestPath =
D:\Test\Qt\4.2.2\bin\QtGuid4.dll
AssemblyDirectory =
D:\Test\Qt\4.2.2\bin\
--------------- INFO: Parsing Manifest File D:\Test\Qt\4.2.2\bin\QtGuid4.dll.
INFO: Manifest Definition Identity is
(null). INFO: Reference:
Microsoft.VC80.DebugCRT,processorArchitecture="x86"type="win32",version="8.0.50608.0"
INFO: Resolving reference
Microsoft.VC80.DebugCRT,processorArchitecture="x86""win32",version="8.0.50608.0".
INFO: Resolving reference for
ProcessorArchitecture WOW64. INFO:
Resolving reference for culture
Neutral. INFO: Applying Binding
Policy.
INFO: No publisher policy found.
INFO: No binding policy redirect found. INFO: Begin assembly
probing.
INFO: Did not find the assembly in WinSxS.
INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.VC80.DebugCRT\8.0.50608.0__1fc8b3b9a1e18e3b\Microsoft.VC80.DebugCRT.DLL.
INFO: Did not find manifest for culture Neutral. INFO: End assembly
probing. INFO: Resolving reference
for ProcessorArchitecture x86. INFO:
Resolving reference for culture
Neutral. INFO: Applying Binding
Policy.
INFO: No publisher policy found.
INFO: No binding policy redirect found. INFO: Begin assembly
probing.
INFO: Did not find the assembly in WinSxS.
INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.VC80.DebugCRT\8.0.50608.0__1fc8b3b9a1e18e3b\Microsoft.VC80.DebugCRT.DLL.
INFO: Attempt to probe manifest at D:\Test\Qt\4.2.2\bin\Microsoft.VC80.DebugCRT.DLL.
INFO: Attempt to probe manifest at D:\Test\Qt\4.2.2\bin\Microsoft.VC80.DebugCRT.MANIFEST.
INFO: Attempt to probe manifest at D:\Test\Qt\4.2.2\bin\Microsoft.VC80.DebugCRT\Microsoft.VC80.DebugCRT.DLL.
INFO: Attempt to probe manifest at D:\Test\Qt\4.2.2\bin\Microsoft.VC80.DebugCRT\Microsoft.VC80.DebugCRT.MANIFEST.
INFO: Did not find manifest for culture Neutral. INFO: End assembly
probing. ERROR: Cannot resolve
reference
Microsoft.VC80.DebugCRT,processorArchitecture="x86", publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50608.0".
Sorry for the length of that message, but I thought it might jog some memories. Is this a case of his not having the Visual C++ 2005 (I believe that's where the VC80 comes from) C runtime libraries installed? If so, can he download the VC++ redistribution package and install it, and will all be well then? Or is this a completely different problem?
If your friend doesn't have VS2005 installed, he will not have the debug runtime libraries for it. They're not part of the redistributable runtimes and IIRC, Microsoft prohibits you from distributing them yourself so you have to have VS2005 installed in order to get them.
I would suggest that he'd rebuild the affected library if possible; I vaguely recollect that there are a couple of articles out on the web on how to rebuilding the GPL QT using Visual Studio, which I believe is not officially supported.
Mixing C++ runtimes requires a lot of care and you can fall into a fairly nasty trap if you don't get it exactly right. If rebuilding all libraries with VS2010 is not an option, your friend will have to get hold of VS2005. It might be worth checking if MS still offers the Express Edition of VS2005 for download.
You might as well do below: LOL
If you are running your application on Windows 7 X64 mode which build in X64 target, you have to install the following X64 SP1 redistributable package
http://www.microsoft.com/download/en/details.aspx?id=2092
Note: The manifest file should change to processorArchitecture = X64 and type="win64"
If you are building your application with X86 (32 bit mode) which run on top of WOW64 layer you have to install X86 SP1 redistributable package
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5582
Related
Description:
When attempting to package project for the HoloLens, I am greeted with an error claiming that the packager was unable to generate a PRI (package resource index) and that the Appx manifest could not be found or is invalid. This issue happens when attempting to package the Microsoft/Unreal chess tutorial as well as creating a new project from scratch. This issue has been observed on 3 computers, while a 4th computer was somehow able to successfully complete a build. When taking the .PRI files from the PC that is successfully able to package and adding them into the Binaries/HoloLens directory of my project (as well as the chess tutorial project) I am suddenly able to build and package without any issues. The problem is that this is not a sustainable method of packaging and I am unsure of what is the root cause of this issue.
Steps to reproduce:
Open Unreal Project and edit/modify project
Click file -> Package Project -> Hololens
Allow the process to proceed
Results:
UATHelper: Packaging (HoloLens): ERROR: ERROR: PRI191: 0x8007007e - Appx manifest not found or is invalid. Please ensure well-formed manifest file is present. Or specify an index name with /in switch.
PackagingResults: Error: ERROR: PRI191: 0x8007007e - Appx manifest not found or is invalid. Please ensure well-formed manifest file is present. Or specify an index name with /in switch.
UATHelper: Packaging (HoloLens): ERROR: Failed to generate Package Resource Index file. See log for details.
PackagingResults: Error: Failed to generate Package Resource Index file. See log for details.
Expected:
Successful Build and packaging for application on the windows UWP/WinRT platform.
Affects:
Unreal Version:
4.26.x, 4.25.x
Windows SDK:
10.0.18362.0, 10.0.9041.0 (possibly other versions as well)
Platforms:
Microsoft HoloLens 2
The systems that are failing:
1 Dell Dev Machine with no security/admin/network restrictions
Windows 10 Pro
OS Build: 19042.746
CPU: Intel i9
Windows Kit SDK: 10.0.18362.0
And
2 Dell Laptops (Corporate devices that have security restrictions, but nothing that should impact development)
Windows 10 Enterprise
OS Build: 17763.1697 (1809)
CPU: Intel i7 9th Gen
Windows Kit SDK: 10.0.18362.0
The System that's succeeding:
Dev Machine with no security/admin/network restrictions
Windows 10 Pro
OS Build: 18363.1316
CPU: AMD FX-8350
Windows Kit SDK: 10.0.18362.0
The main differences:
Windows 10 OS build is different
The failing machines all have Qt installed, the succeeding machine does not (uninstalling Qt Creator does not solve this issue)
The Succeeding machine has an AMD processor instead of Intel, also ram size is different
Causes Crash:
No
Additional Notes:
Though taking the resource pri files from the working PC and mounting them in the same directory in our non-working projects does fix the solution, there is a concern that our project may change in a way that conflicts with the current pri files and would cause our builds to fail again. Their is also a growing concern that we may not be able to use an automated build system like Jenkins if our project can't properly package in its current state across any machine.
This issue is caused by the makepri.exe that is found in the windows 10 SDK, when attempting to manually run the makepri.exe tool, I am provided with the following error: "ERROR: PRI260: 0xdef00106 - PRI file is invalid."
I am unsure if my issues are steming from Unreal or the Microsoft SDK, but makepri.exe does not seem to be working on any of my machines.
Commands used:
"C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\MakePri.exe" createconfig /cf "\Binaries\HoloLens\priconfig.xml" /dq en-US /pv 10.0.0 /o
"C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\MakePri.exe" new /pr "" /cf "\Binaries\HoloLens\priconfig.xml" /mn "\Binaries\HoloLens\AppxManifest_x64.xml" /of "\Binaries\HoloLens\resources_x64.pri" /o
I'm working on a plugin for Autodesk 3ds Max 2017. As per Max's documentation, the plugin is compiled inside VS 2017 using the VS 2015 toolset against the 10.0.10586.0 Windows SDK.
When the plugin is loaded by 3ds Max, it in turn programmatically loads a number of DLLs using LoadLibrary(). Until recently, that was working fine on my machine. It's also still working fine on other developers' machines.
What happens now on my machine is that LoadLibrary() fails and returns a null handle. The error code is 127, i.e. "The specified procedure could not be found."
I am quite sure that DLLs that the one I'm trying to load to depends on are available on the system. I have triple-checked with both Dependency Walker and its modern incarnation, Dependencies.
In fact, the following program run inside Visual Studio 2017 (also using VS 2015 toolset against the 10.0.10586.0 Windows SDK) is able to load that DLL just fine:
#include <Windows.h>
int main(int argc, char* argv[])
{
auto result = LoadLibrary(L"C:\\path\\to\\appleseed.dll");
}
To investigate this problem further, I've turned to GFlags which is part of the Debugging Tools for Windows 10.
Here is the full debugger output emitted when calling LoadLibrary(): https://gist.github.com/dictoon/b3f9f7cb52d2d81078965133d5035a03
I believe (but I'm not 100% sure) that the relevant error from this output is the following:
5f4c:54bc # 131346281 - LdrpReportError - ERROR: Locating export "StackWalkEx" for DLL "C:\Windows\SYSTEM32\dbgeng.dll" failed with status: 0xc0000139.
Exception thrown at 0x00007FFCC6A9EAA8 (ntdll.dll) in 3dsmax.exe: 0xC0000139: Entry Point Not Found.
5f4c:54bc # 131346281 - LdrpGenericExceptionFilter - ERROR: Function LdrpSnapModule raised exception 0xc0000139
Exception record: .exr 000000000223F030
Context record: .cxr 000000000223EB40
dbgeng.dll appears to be Visual Studio's debugger so I thought that maybe the error would only occur when 3ds Max was run inside Visual Studio with the debugger attached but that's not the case: the DLL also fails to load when 3ds Max is launched on its own.
Inspecting C:\Windows\SYSTEM32\dbgeng.dll with Dependencies reveals that it does export a StackWalkEx() symbol:
Edit 1: #RbMm commented that StackWalkEx() is actually not exported by dbgeng.dll but by dbghelp.dll as the screenshot below shows:
Edit 2: With a release build of the DLL I'm trying to load, everything works fine too. Looking at the debugger's output, no attempt is made at loading dbgeng.dll or finding StackWalkEx().
Edit 3: It appears that the debug version of the library I'm trying to load does have a dependency toward dbgeng.dll:
But a small test DLL written from scratch doesn't!
Edit 4: I now suspect that Boost 1.69 (on which the DLL I'm trying to load depends) to which we recently switched (from Boost 1.55) has introduced a dependency on dbgeng.dll via its Stacktrace library introduced in Boost 1.65.
The problem is an older version of dbghelp.dll which ships with 3ds Max and conflicts with the newer version the appleseed.dll has been linked with during the debug build.
The call to the function StackWalkEx, which failed, has a dependency on dbghelp.dll
StackWalkEx function
The solution is to inactivate or replace the older, incompatible version of dbghelp.dll inside the Max root directory.
StackWalkEx is part of DbgHelp and used by System Services. It may have been updated recently during a Windows update causing the breaking change.
I have an x86 C++ app that works in VS2013 and I'm upgrading to VS2015. The build and link work fine but when I run I get an error:
Unable to start program. This application has failed to start because
the application configuration is incorrect. Review the manifest file
for possible errors. Reinstalling the application may fix this
problem. For more details, please see the application event log.
The application event log shows:
Activation context generation failed for "MyApp.exe".
Dependent Assembly Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762" could not be found.
Please use sxstrace.exe for detailed diagnosis.
So I ran sxstrace and got:
=================
Begin Activation Context Generation.
Input Parameter:
Flags = 0
ProcessorArchitecture = Wow32
CultureFallBacks = en-US;en
ManifestPath = MyApp.exe
AssemblyDirectory = MyApp\Debug\
Application Config File =
-----------------
INFO: Parsing Manifest File MyApp.exe.
INFO: Manifest Definition Identity is (null).
INFO: Reference: Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762"
INFO: Resolving reference Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762".
INFO: Resolving reference for ProcessorArchitecture WOW64.
INFO: Resolving reference for culture Neutral.
INFO: Applying Binding Policy.
INFO: No publisher policy found.
INFO: No binding policy redirect found.
INFO: Begin assembly probing.
INFO: Did not find the assembly in WinSxS.
INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.VC80.DebugCRT\8.0.50727.762__1fc8b3b9a1e18e3b\Microsoft.VC80.DebugCRT.DLL.
INFO: Did not find manifest for culture Neutral.
INFO: End assembly probing.
INFO: Resolving reference for ProcessorArchitecture x86.
INFO: Resolving reference for culture Neutral.
INFO: Applying Binding Policy.
INFO: No publisher policy found.
INFO: No binding policy redirect found.
INFO: Begin assembly probing.
INFO: Did not find the assembly in WinSxS.
INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.VC80.DebugCRT\8.0.50727.762__1fc8b3b9a1e18e3b\Microsoft.VC80.DebugCRT.DLL.
INFO: Attempt to probe manifest at MyApp\Debug\Microsoft.VC80.DebugCRT.DLL.
INFO: Attempt to probe manifest at MyApp\Debug\Microsoft.VC80.DebugCRT.MANIFEST.
INFO: Attempt to probe manifest at MyApp\Debug\Microsoft.VC80.DebugCRT\Microsoft.VC80.DebugCRT.DLL.
INFO: Attempt to probe manifest at MyApp\Debug\Microsoft.VC80.DebugCRT\Microsoft.VC80.DebugCRT.MANIFEST.
INFO: Did not find manifest for culture Neutral.
INFO: End assembly probing.
ERROR: Cannot resolve reference Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762".
ERROR: Activation Context generation failed.
End Activation Context Generation.
I'm not sure how this helps and I still don't understand why I'm getting this error if I built the app from scratch in VS2015. I've tried installing Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) which corresponds to the version 8.0.50727.762 but it hasn't helped.
A lot of the older posts on this subject (e.g. Why installing vcredist_x86.exe doesn't fix SideBySide error when I develop an EXE on one machine and run it on another one?) mention checking the .manifest file generated by the build but I can't find one. Does VS2015 no longer generate them?
One of your used library is build against the Debug Runtime of Vs2005 (Microsoft.VC80.DebugCRT). Those debug files are NOT part of the normal Visual C++ 2005 SP1 Redistributable Package.
Do a trial & error search to figure out which library and get the release version which uses the release Dlls which are part of the Redistributable Package.
What type of 3d party libraries are you using and how are they being linked? For example are you using DLLs, Libs or both? If you are using statically linked 3rd party libraries, then they must be compiled and built using the same version of VS you are using with the same code generation flags. You may also want to visit the developer's websites of those libraries and look to see if they have a newer version and one that is already compiled with your current version of VS. If they only have 2010, 12 or 13 they should work but you will have to open them in 2015 and build them out yourself
For example; I use libpng, openal, ogg-vorbis, glm & others, For all of the 3rd party libraries that my applications depend on I have created a file directory where they are stored and I created environment variables on my main machine for an easier linking process. For all of these libraries except for glm since glm is a headers only library I had to create different environment variables for each version of visual studio I'm using; for example OGG-Vorbis are 2 different libraries used for doing audio; so I would have OGG_SDK_2010, VORBIS_SDK_2010 ... OGG_SDK_2015, VORBIS_SDK_2015 where these libraries being the newest version from their websites are loaded and built out in both release & debug versions of each version of Visual Studio that I may be using.
Before I redid my pc I did have VS2008, 2010, 2012, 2013 and 2015; now that I reinstalled my OS I currently only have VS2013 & 2015. So any of my older programs from VS2008, VS2010 & VS2012 I will have to first port them to 2013 and fix any dependencies and take care of any deprecation. Once that process is completed I'll then be able to port them over to 2015.
Now, from my experience on porting one of my programs over to 2015 from 2013 there was a little bit of a process that had to be done, however, I do not recall off of the top of my head exactly what had to be done. I do know that it did take a little bit of time reading different threads and trial and error to get everything to work properly.
It may also be that you could be using a library that has not been updated and that there is currently no more work or support being done for it that the library dependency that you may have may be considered deprecated in itself and if that is the case, then you may have to do some research to find an alternative library that will fit your needs. Once you find the appropriately library, then it is a matter of stripping out all of the old method calls and replacing them with the equivalent calls to the newer library. However in some cases this may involve a complete rewrite of your existing program.
For example; I use OpenGL and when I first started to learn it I was using version 1.0 where everything that was used to do render calls was all done on the CPU. Now that I'm using Modern OpenGL and using GLSL Shaders on the GPU and have successfully created a 3D Graphics Shader Rendering Engine; the transition from OpenGL 1.0 to 4.5 was quite a bit to take in and the difference between the two versions of the same Library or API by OpenGL was a challenge. Porting from an older version of a compiler to a newer version is sometimes fairly easy like porting from 2012 to 2013, there wasn't that much of an overhead change, but sometimes porting from an old version to a newer version can be tedious such as going from 2005 to 2015.
Also do not forget to check these 3rd party libraries props files to make sure they are pointing to the correct version of VS.
#magicandre1981's answer is correct but didn't give any clues how to help track it down. I eventually noticed that when Visual Studio links my app it prints out:
glew32sd.lib(glew.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'glew32sd.lib(glew.obj)' or at 'MyApp\Debug\vc80.pdb'; linking object as if no debug info
I rebuilt glew32sd.lib from the glew source code and my problem was fixed.
------ Discover test started ------
Failed to configure settings for runsettings plugin 'VSTest Run Configuration' as it threw following exception:
'Method not found: 'System.Collections.Generic.IEnumerable1<System.String> Microsoft.VisualStudio.TestPlatform.Utilities.InferSettingsHelper.MergeRunSettingsAndFindCompatibleSources(Microsoft.VisualStudio.TestPlatform.ObjectModel.Architecture ByRef, Microsoft.VisualStudio.TestPlatform.ObjectModel.FrameworkVersion ByRef, System.String, System.String, System.Collections.Generic.IDictionary2>, System.Xml.XPath.IXPathNavigable, System.String ByRef)'.'
Please contact the plugin author.
Exception has been thrown by the target of an invocation.
========== Discover test finished: 0 found (0:00:00) ==========
I found the solution by my own observations. After digging for 2 days and found nothing about this problem...
Well, the problem is caused simply because vstest engine is not updated. When I implemented those steps mentioned in the article "Authoring a new Visual studio unit test adapter" for Bhuvaneshwari K, sorry guys the admin says I can't post more than 2 hyperlinks and I prefered to post the links for Microsort down center for the solution. Anyway, you can google the article for more info.
When I compared the vstest of my build machine, and once again of my local test machine I found that the vesion of vstest.console was obsolete, although I see in the Hellp=>About menue that Update1 is already installed for both machines with the same version. So, I figured to install again the VS SDK and update 1, well in fact, repair not install. So I installed them from those links:
1- Microsoft Visual Studio 2012 SDK
http://www.microsoft.com/en-us/download/details.aspx?id=30668
2- Visual Studio 2012 Update 1 KB2707250 from the link:
http://www.microsoft.com/en-us/download/details.aspx?id=35774
3- Restart the machine.
And the XMLTestAdapter is working like a charm in VS2012 in the build machine, still though I met some issues with TFSBuild to find the assemblies in a mapped folder under TFS2012 for the dlls of that adapter. I'll post a question for it in a new thread.
My solution to this problem was that I had an issue in my Windows 7 System Environment variables.
To access:
Start Menu\Control Panel\System and Security\System
Click the Advanced System Settings link of the left.
Choose 'Environment Variables'
In the 'user variables for ***' section, click "New".
Variable name = PROCESSOR_ARCHITECTURE
Variable value = AMD64 (or whatever you find in the same corresponding 'system variable' area in the same window.)
close/reopen Visual Studio and rebuild your solution.
What fixed this for me was adding the System.Configuration.ConfigurationManager package to the class library I wanted to test.
I obtained some code from a friend, developed on the same system (Windows 7) and same Visual Studio Ultimate 2010, with all the libraries relatively mapped.
The code builds, but when trying to run it I get the error:
Application failed to start because the application configuration is incorrect"
Running Dependency Walker on the executable showed that msvcr90.dll, ieshishm.dll, ieframe.dll and freeglut.dll could not be found. I copied these to the execs directory and that solved these problems. However, two issues remain:
Error: The Side-by-Side configuration information for "e:\projects\darwin\code\debug\GLTEMPLATE.EXE" contains errors. 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 (14001).
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
With SHLWAPI.DLL and IEFRAME.DLL modules being marked red (assuming error message relates to these two, how do I fix that?).
Also, the sxstrace gave following result:
Begin Activation Context Generation.
Input Parameter:
Flags = 0
ProcessorArchitecture = x86
CultureFallBacks = en-US;en
ManifestPath = E:\Projects\Darwin\Code\Debug\GLTemplate.exe
AssemblyDirectory = E:\Projects\Darwin\Code\Debug\
Application Config File =
INFO: Parsing Manifest File E:\Projects\Darwin\Code\Debug\GLTemplate.exe.
INFO: Manifest Definition Identity is (null).
INFO: Reference: Microsoft.VC90.DebugCRT(...)
INFO: Resolving reference Microsoft.VC90.DebugCRT
INFO: Resolving reference for ProcessorArchitecture x86.
INFO: Resolving reference for culture Neutral.
INFO: Applying Binding Policy.
INFO: No publisher policy found.
INFO: No binding policy redirect found.
INFO: Begin assembly probing.
INFO: Did not find the assembly in WinSxS.
INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.VC90.DebugCRT\9.0.21022.8__1fc8b3b9a1e18e3b\Microsoft.VC90.DebugCRT.DLL.
INFO: Attempt to probe manifest at E:\Projects\Darwin\Code\Debug\Microsoft.VC90.DebugCRT.DLL.
INFO: Attempt to probe manifest at E:\Projects\Darwin\Code\Debug\Microsoft.VC90.DebugCRT.MANIFEST.
INFO: Attempt to probe manifest at E:\Projects\Darwin\Code\Debug\Microsoft.VC90.DebugCRT\Microsoft.VC90.DebugCRT.DLL.
INFO: Attempt to probe manifest at E:\Projects\Darwin\Code\Debug\Microsoft.VC90.DebugCRT\Microsoft.VC90.DebugCRT.MANIFEST.
INFO: Did not find manifest for culture Neutral.
INFO: End assembly probing.
ERROR: Cannot resolve reference Microsoft.VC90.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".
ERROR: Activation Context generation failed.
End Activation Context Generation.
(...)
And some more similar.
I also tried changing the runtime library as suggested on other related posts from multi-threaded debug DLL (/MDd) into multi-threaded debug (/MTd). However, I get the:
MSVCRTD.lib(MSVCR100D.dll) : error LNK2005: _printf already defined in LIBCMTD.lib(printf.obj)
And some five more similar. Excluding LIBCMTD.lib allows me to build. However, I still cannot run the application. I get the same error as in the very beginning.
What is going wrong and how do I fix this?
No other related posts gave me the answer so far.
Your project uses one or more libraries that were built with Visual Studio 2008, the previous version of Visual Studio. They require the C runtime library for that version to be available; that's why it is complaining about msvcr90.dll. You've got Visual Studio 2010; you only have msvcr100.dll installed on your machine.
Just copying msvcr90.dll isn't going to work; that DLL needs to be installed in the Windows side-by-side cache. You can get an installer from Microsoft or from your friend. That's, however, not the true fix; you still have a problem with your application depending on two versions of the CRT. Very unhealthy, that can cause very-hard-to-diagnose crashes and memory leaks. You need to get the libraries rebuilt with Visual Studio 2010. That's where my advice fizzles out; I can't guess what those libraries are from your question.
"msvcr90" <- I'm pretty sure that's not the 2010 version; not the release anyway. My bet is that somewhere in the mix you're linking to something built against an older runtime but not old enough to be installed with win7.
You don't want to switch to the static runtime while linking to 3rd party DLL's, or your own DLL's.
It is possible the problem in manifest.
I set Configuration Properties/Linker/Manifest file/ Generate manifes==No
and program began starting.