I've developed a 64 bit dll using C++ and Visual Studio 2008 and i'm trying to register it on a target machine using 'regsvr32.exe'. I've checked the manifest file and it clearly states what version of CRT is needed:
<assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='amd64' publicKeyToken='1fc8b3b9a1e18e3b' />
When i try to register the file i always get a side-by-side error message stating that the application settings are incorrect and that i should reinstall it.
Log Error: Generate Activation Context
failed... Reference error message: The
referenced assembly is not installed
on your system.
The target machine runs Windows Xp Professional 64 bit. I've tried to install the corresponding VC++ redistributable package( VC++ 2008 Redist x86 and x64 ), create a setup and include the corresponding merge module ( microsoft_vc90_crt_x86_x64.msm ), install all VC++ redistributable packages etc. No matter what's installed it will always fail.
If i check for the dependent files and they are correctly located inside the WinSxS folder, but if i run Dependency Walker on the file it will complain too that the files from the VC9 CRT could not be found.
If i build the file for 32 bit it will correctly register on a 32 bit OS. I'm running out of ideas so any help is very appreciated.
Thanks,
Adrian.
EDIT *This is reproductible only on Win XP 64, all works fine on Windows 7 64 bit.
I'm no expert in installers but have you thought about distributing the redistributable's in the root folder of your application?
As for me, I've never heard of using regsvr32.exe to install crt redist's.
<assemblyIdentity type='win32' name='Microsoft.VC90.CRT' ...
shouldn't it be
<assemblyIdentity type='win64' name='Microsoft.VC90.CRT' ...
?
You need the 64-bit runtime
It sounds like despite the app is 64 bit it's looking for the 32bit crt dlls. Did you try to install the 32bit redistributable package?
Here is a good description on how to track down SideBySide failures:
http://blogs.msdn.com/b/junfeng/archive/2006/04/14/576314.aspx
In the end I've managed to fix this by including a newer version of C++ redistributable merge modules into the setup along with all the required policy merge modules in order to redirect the calls to any old version to the new one that's available.
Most important thing here is that the exe redistributable include the policy files and the merge modules don't so they need to be separately added.
Related
I'm' trying to build a C++ application with Visual Studio 2015 using OpenSSL.
The application experiences a 0xC0000007b error with the message "The application was unable to start correctly". Using Dependency walker I saw my application, built as x86, uses the X64 OpenSSL DLL (in System32 instead of SYSWOW64).
How can i force Visual Studio to use the 32-bits DLL?
I just added these two dependencies :
libeay32.lib
ssleay32.lib
And visual studio loads automatically ( or windows ? ) the 64 bits version, which gets me the 0xc0000007b error
Edit : Yeah, the DLL 32-bits are in the SysWow64 too.
Any idea please ?
Thanks a lot :)
You cannot force Visual Studio to automatically find proper libraries for your architecture. Instead of it you should point to it explicitly via Library Path. Use $(PlatformName) there if you have multiple target platforms.
If you compile application as x86 than Windows automatically redirects you to the proper 32 bit system32 folder. But don't rely on it, deploy required OpenSSL dlls locally, into your application folder. If you have multiple target platforms it's also handy to use $PlatformName macros in post-build event. E.g:
copy "$(SolutionDir)3rdParty\OpenSSL\$(PlatformName)\ssleay32.dll" "$(TargetDir)"
copy "$(SolutionDir)3rdParty\OpenSSL\$(PlatformName)\libeay32.dll" "$(TargetDir)"
I have recently acquired source code from a VS2005 project that uses the MFC library. Firstly I upgraded the project to VS2012 and I can now successfully build and run the software on Windows 8. Next, I wanted to deploy the software on a Windows XP machine.
I have set the Platform Toolset to build to Windows XP (using the v110_xp option) and I have installed the 'Visual C++ Redistributable for Visual Studio 2012 Update 1' on the target machine. When I run the software, nothing appears to happen. Via some logging functions I can determine that a call to LoadFrame(IDR_MAINFRAME) causes an exception in kernel32.dll. I can't debug any further in to LoadFrame as remote debugging on Windows XP is not available in VS2012.
Any ideas what may be going wrong? Is the Visual C++ Redistributable package the correct version to be installing on the target machine? What should I be trying next?
UPDATE
My project is already set up to use the 7.1 SDK and has minimum required version set to 5.01 in linker options.
If I use InstallShield to generate an installer and include the MFC, CRT and ATL redistributables, the installer works and my program now runs on Windows XP. My understanding of the redistributables is that they simply copy the relevant dll's in to the system32 folder (or equivalent)? Is that correct?
However, if I simply copy the files over, run the vsredist_x86.exe or use Inno Setup to install the software & dll's, my program no longer works.
I believe you have read this blog. In summary, you need to use the 7.1 SDK, and you need to set minimum required version to 5.01 in linker options.
Using the working InstallShield project and the not-working Inno project I was able to determine that the real culprit here was an unregistered msxml4.dll. The error I was receiving gave no real clue to this outcome but I got there eventually...
regsvr32 msxml4.dll
Issue
I wrote a C++ project called 'Foo' using Microsoft Visual Studio 2005 Verison 8.0.50727.762 (SP.050727-7600) on Windows XP Professional Version 2002 Service Pack 3. I built the project into Foo.exe. Then, I copied the file Foo.exe to a Windows Server 2003 Enterprise Edition Service Pack 2. When I tried to run it, it failed with this error,
C:\foo.exe
The application has failed to start because the application configuration is incorrect.
Reinstalling the application may fix the problem.
In Event Viewer > System, three events were logged.
Event ID: 32; Source: SideBySide
Dependent Assembly Microsoft.VC80.CRT could not be found and Last Error was
The referenced assembly is not installed on your system.
Event ID: 59; Source: SideBySide
Resolve Partial Assembly failed for Microsoft.VC80.CRT.
Reference error message: The referenced assembly is not installed on your system.
Event ID: 59; Source: SideBySide
Generate Activation Context failed for C:\foo\Foo.exe.
Reference error message: The referenced assembly is not installed on your system.
Installing Microsoft Visual C++ 2005 Redistributable didn't fix it
Downloaded vcredist_x86.exe from http://www.microsoft.com/download/en/details.aspx?id=3387
Installed it. The installer created a folder called C:\windows\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd.
The version of this software as found from 'Add or Remove Programs' was '8.0.50727.42'.
On trying to run C:\foo\foo.exe, I got the same errors I described above.
Installing Microsoft Visual C++ 2005 SP1 Redistributable didn't fix it
Downloaded vcredist_x86.exe from http://www.microsoft.com/download/en/details.aspx?id=5638
Installed it. The installer created a folder called: C:\windows\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700.
The version of this software as found from 'Add or Remove Programs' was '8.0.56336'.
On trying to run C:\foo\foo.exe, I got the same errors I described above.
Copying CRT DLLs and manifest from the same machine (where I'm running the EXE) didn't fix it.
I copied msvcm80.dll, msvcp80.dll and msvcr80.dll from
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd
to C:\foo.
Next, I copied
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd.manifest
to C:\foo and renamed it to Microsoft.VC80.CRT.manifest.
The fourth line of the manifest file looked like this:
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.42"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
When I tried running C:\foo\foo.exe this time, it didn't work. I repeated this thing again with the DLLs in C:\windows\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700 and the corresponding manifest file. It didn't help as well. I got the same error.
In both cases, I got the following errors in Event Viewer > System.
Event ID: 34; Source: SideBySide
Component identity found in manifest does not match the identity of the component requested
Event ID: 58; Source: SideBySide
Syntax error in manifest or policy file "C:\foo\Microsoft.VC80.CRT.MANIFEST" on line 4.
Event ID: 59; Source: SideBySide
Generate Activation Context failed for C:\foo\Foo.exe. Reference error message: The manifest file contains one or more syntax errors.
Copying CRT DLLs and manifest from the Windows XP machine (where I built the EXE) didn't fix it.
I copied msvcm80.dll, msvcp80.dll and msvcr80.dll from
C:\winnt\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700 of Windows XP machine (where I developed and built foo.exe)
to C:\foo of Windows Server 2003 (where I am trying to run foo.exe).
Next, I copied
C:\winnt\winsxs\Manifests\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700.manifest
to C:\foo and renamed it to Microsoft.VC80.CRT.manifest.
The fourth line of the manifest file looked like this:
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
On trying to run C:\foo\foo.exe now I got the same errors mentioned in the previous section.
Copying CRT DLLs and manifest from Visual Studio folder fixed it.
Copied msvcm80.dll, msvcp80.dll, msvcr80.dll and Microsoft.VC80.CRT.manifest from C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT of Windows XP machine (where I developed and built foo.exe) to C:\foo of Windows Server 2003 machine (where I am trying to run it).
The fourth line of the manifest file looked like this:
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.6195"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
This time I could run C:\foo\foo.exe without any issues.
Question
I was expecting that installing 'Microsoft Visual C++ 2005 SP1 Redistributable' (vcredist_x86.exe) as described in the second approach would fix it. But it didn't. Copying the DLLs and manifest files from the C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT folder of the development machine fixed it. Why was it so?
Build options
In case, it helps you to answer my question. Here is the compiler and linker options I picked up from Visual Studio project properties:
Configuration properties > C/C++ > Command Line:
/O2 /GL /D "_MBCS" /FD /EHsc /MD /Fo"Release\\" /Fd"Release\vc80.pdb" /W3 /nologo /c /Wp64 /Zi /TP /errorReport:prompt
Configuration properties > Linker > Command Line:
/OUT:"C:\MixedBag\Release\Foo.exe" /NOLOGO /MANIFEST /MANIFESTFILE:"Release\Foo.exe.intermediate.manifest" /DEBUG /PDB:"c:\MixedBag\release\Foo.pdb" /OPT:REF /OPT:ICF /LTCG /MACHINE:X86 /ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
I'll answer my own question. Comments to the question by Hans Passant and Luke helped.
I downloaded Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update and installed it on the system where I was trying to run C:\foo\foo.exe. The EXE ran fine after this.
The installer placed the CRT DLLs in C:\windows\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.6195_x-ww_44262b86. So, yes, 8.0.50727.6195 was the version of the CRT DLLs I was looking for as Hans Passant rightly said.
The easiest way to figure this version was by looking at the manifest file generated by Visual Studio while building my project on the development system. Mine was located at C:\Foo\Release\Foo.exe.intermediate.manifest. It had a tag like this:
<assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50727.6195'
processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b' />
So, this is a clue that I needed 8.0.50727.6195 version of the DLLs. The rest was a matter of searching for the right vcredist_x86.exe which happened to be in the URL I have mentioned in the second paragraph. The page in that URL contains a link to KB2538242 which shows the version numbers of the DLLs that would be installed by the installer.
Note: As Elie has mentioned in a different answer to this question, since this is a 32-bit application, it is necessary to install vcredist_x86.exe (not vcredist_x64.exe) on the system where this application is supposed to be run irrespective of whether that system is a 32-bit Windows system or a 64-bit Windows system. Once again, the .manifest file provides this clue in the processorArchitecture attribute.
You have to install "Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update" which is here: http://www.microsoft.com/en-us/download/details.aspx?id=26347
Here is how you fix this issue:
You WILL STILL Get the sidebyside errors If the application being used is 32 bit and you try running it on a 64 bit OS which has the VC_REDISTx64 installed.
Simple solution, you MUST ALSO LOAD THE VC_REDISTx86 on the 64 bit os
I had a somewhat related problem. Two development XP machines with VS2005 installed, call them A and B. I developed, built and ran on A. Then I copied the whole project to B. Built there. Tried to run and got the same error messages mentioned by SusamPal. I realized that on B's WinSxS there were the x86_Microsoft.VC80.CRT_xxx manifests (and folders) but not the corresponding x86_Microsoft.VC80.DebugCRT_xxx ones (and why?!). I tried several of the dances and incantations described by SusamPal to no avail. I solved the problem by copying the appropriate folders from the WinSxS of A to B AND the appropriate manifests from the WinSxs\Manifests.
Although my application was
developed on Win 2k8 R2 x64 with vs2008 (which has msvcm90.dll, msvcp90.dll and msvcr90.dll in C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\redist\amd64\Microsoft.VC90.CRT)
and ran on win 2k3 SP2 x64,
but the msvcm80.dll, msvcp80.dll and msvcr80.dll are needed.
After install Microsoft Visual C++ 2005 SP1 Redistributable Package (x86), the application can be installed and ran rightly.
For me the side by side error went just by chabging the under the setting c/c++ ->CodeGeneration->RuntimeLibrary ,make it MTD that is multi-Thread Debug
We have really following problem here: the application executable references dlls using manifest machinery. In the deep past application authors just copied required dll's into system directories. Unfortunately this caused so called "dll hell" problem when overwriting older dll versions by incompatible newer one could make applications stop working. MS then came up with with versioning idea (winsxs).
Unfortunately this is quite complex machinery and it is definitely not a good idea to try manually installing dlls (assemblies) into the sxs folder. Installing so called "redistributable packages" is not a perfect solution either.
Additionally, this cannot help when we want debug versions. As MS prohibits distribution of debug versions of supporting dlls, "redistributable packages" won't install them. (Note that the assembly id depends on current subversion of VS2005 and is related to installed supporting libraries.)
Usually, the VS installer adds the required assemblies to the system, but after some time installation of updates or newer SDK's and tools may damage this correct state.
Let's assume we have this situation - our debug libraries are no longer integrated into system. Suppose we have given workspace with project A and active debug configuration giving not working application. We can then create installer project, say C in current workspace, add our application (or strictly, project with active configuration) to it. Setup installer project to put our executable in some place (desktop is the right place regarding this situation) enable dependencies check and some other minor properties. Then build project C and run installer (or "install" from VS using context menu). Now your application and other created with debug dll libraries start to work.
Beware when you run installer with "remove" option you came to previous situation. Here is good article related to distribution topic: http://blogs.msdn.com/b/vcblog/archive/2007/10/12/how-to-redistribute-the-visual-c-libraries-with-your-application.aspx.
If you have some other applications and want to deploy them simply by copying, maybe on non development machine without installed VS, you may create dummy project together with appropriate configuration and installer for it . You then install it once on each machine and then copy executable(s) you are working on.
I have a C++ .exe compiled with /MDd (since I can't use CLR with /MTd). At first I was getting couldn't find x.dll that is installed when installing the VC++ runtime. After I installed the VC++ 2010 runtime, I still get the error. I've verified that the .dll it's looking for (msvcpsomethingd.dll) is located in the correct folder ([SystemDrive]\Windows\system32). Has anyone run into this problem before?
How to deploy debug CRT .dlls
How to deploy CRT .dlls in general to the application local folder
The short answer is you have to explicitly install the CRT debug runtime for VS 2010 with a custom setup project on the target machines OR ensure the CRT .dlls for the platform are in the same folder as the application.
You will have to explicitly install the CRT if you are using multiple versions of the debug CRT (i.e., x86 and x64).
The best way to solve these issues is to use the depends.exe tool. Profile the program and it will tell what you are missing.
Compile with release mode and run on different PC. It seems like one/more of your DLLs are compiled using Debug build or dependencies.
It could be your referenced library as well..
Ensure that correct Redestributable of VC++ 2010 is installed:
32-bit OR 64-bit, depending on your application, not as per target OS.
Appropriate RTM or Service Pack version.
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