I have ported a project from Win32 to x64 platform. I changed all dependencies so I can build the project smoothly. However, as soon I start the executable I'm getting an error (0xc000007b).
Using the dependency walker I can see, that at a certain point the ComCTL32.dll is loaded but the x86 and not the x64 as expected.
As soon I turn of the manifest generation (linker->Manifestfile), it works. But that's not a solution.
So my question is: Where in Visual Studio 2010 can I set the path to the correct DLL ComCtl32.dll.
Well, the manifest matters. An example of a bad one that could cause this problem would look like this:
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="x86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
The processerArchitecture attribute value matters. A good one uses *, which means compatible or amd64, which means 64-bit.
You don't set the path anywhere. You specify a manifest to indicate which version of ComCtrl you want, and then it is up to the OS to find it, like any other DLL. The error you are seeing means a 64bit process is trying to load a 32bit DLL, or vice versa. That could be a search path issue, that could be a dependancy issue. Use a tool like DependancyWalker to find the culprit.
Related
I have an MFC project in MSVS 2010. When I compile it, MSVS generates manifest file that contains the following lines:
<assemblyIdentity publicKeyToken="1fc8b3b9a1e18e3b"
processorArchitecture="x86" version="9.0.21022.8"
name="Microsoft.VC90.CRT" type="win32"/>
As a result, I get a binary that depends on both vcredist_x86.exe for MSVS 2008 and vcredist_x86.exe for MSVS 2010, though it actually uses only vcredist_x86.exe for MSVS 2010!
I tried to switch off manifest generation in project properties. After it my app started to work with only vcredist_x86.exe for MSVS 2010 installed. But some controls (especially comboboxes) broke and began to be displayed incorrectly. I guess this happens because windows doesn't have the following information from manifest any more:
<assemblyIdentity language="*" publicKeyToken="6595b64144ccf1df"
processorArchitecture="x86" version="6.0.0.0"
name="Microsoft.Windows.Common-Controls" type="win32"/>
Why does MSVS write a wrong version of CRT in the manifest file?
How to fix the problem/make MSVS write the correct version of CRT in the manifest file?
I figured it out. I had a reference to libcurl.lib which had a reference to openssl libs compiled in MSVS 2008... After rebuilding libcurl with the proper versions of openssl the reference to crt 9.0 disappeared from the manifest file.
Probably this happens because of the platform toolset in project properties.
Change it to v100 (I suppose now it is set to v90), re-activate manifest generation and embedding (Manifest Tool\Input and Output) and rebuild your project.
I am posting this in the hope that it will save someone else the time and effort of figuring this one out:
My current setup is VS2015 against TFS 2013.4
Problem
My old PC setup had VS2013, and I had been using the Microsoft.TeamFoundation.WorkItemTracking.Client namespace to get some Work Item information from TFS.
I recently had to rebuild my PC, and continued development of a program that gets this information.
To my dismay, I kept getting an error:
Unable to load DLL 'Microsoft.WITDataStore32.dll'
You don't need to install the TFS object model/Team Explorer anymore. You can use the NuGet package
Also with the NuGet package, you may run into the same issue that your application cannot find the native DLL.
The text below is copied from
https://connect.microsoft.com/VisualStudio/feedback/details/1695433/team-foundation-server-2015-sdk-missing-microsoft-witdatastore64-dll
Microsoft.WITDataStore*.dll is part of the ExtendedClient package, they are native dlls and cannot be referenced in managed project.
You will need to manually copy the dll into your bin folder for runtime resolution.
Microsoft.WITDataStore32.dll is in ..\Microsoft.TeamFoundationServer.ExtendedClient.14.83.1\lib\native\x86
Microsoft.WITDataStore64.dll is in ..\Microsoft.TeamFoundationServer.ExtendedClient.14.83.1\lib\native\amd64
(note these paths point to the NuGet package folder)
In the end, the following stackoverflow threads gave me the answer:
where is the tfs 2010 api dll microsoft teamfoundation framework server dll
what do i need to install to get microsoft teamfoundation workitemtracking client
The VS2015 dll's are not compatible with TFS 2013, so don't go looking for the dll's in Microsoft Visual Studio 14.0\ Common7 \ IDE !
You HAVE to install Team Explorer 2013 if you work against TFS 2013
It's small (just 130 MB), and it contains the correct DLLs.
After installation, you need to Browse... for the references here:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies
If you are getting Microsoft.WITDataStore32.dll issue while dealing with TFS/ VSTS ie. getting project name or fetching test case id in Visual Studio 2015 then you can simply redirect the Team Foundation dlls to version 12.0.0.0 from 14.0.0.0 as 14 version dlls create issue while retrieving such data and we use to get such error.
I have faced issue "Unable to load DLL 'Microsoft.WITDataStore32.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)" while running my Coded UI test script after migration from "TFS 2012 and VS2013" to "VSTS and VS2015" respectively.
The issue got resolved when i redirected the referenced 14 versions dll to 12 version in the App config as shown below:
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.TeamFoundation.Common" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="14.0.0.0" newVersion="12.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.TeamFoundation.TestManagement.Client" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="14.0.0.0" newVersion="12.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.TeamFoundation.WorkItemTracking.Client" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="14.0.0.0" newVersion="12.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
Regards,
Prasidh
My case was that I needed to add NuGet reference directly in the test project (my custom attribute was situated in another project and dll was not copied to the test project).
I'm posting this information w.r.t. Visual Studio 2017 in case it helps someone:
Please check whether you have 'Microsoft.WITDataStore32.dll' in the
path below:
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team
Explorer
If not, please try to install team explorer for vs 2017 , download it
from this blog:
https://blogs.msdn.microsoft.com/bharry/2017/04/05/team-explorer-for-tfs-2017/
Then find Microsoft.WITDataStore32.dll in team explorer folders and
copy it to the path above.
Source: MSDN
I'm developing a binary file in windows XP with Visual Studio 2005. I've generated debug and release versions of my application and on my machine all goes fine. But, when I try to run the application on another machine, the debug version runs fine (I think because I have the same Visual Studio on both machines), but the release version is having problems executing (i have the same version of redistributables).
Reading here in Stackoverflow, I've set the embedded manifest to no, and when I generate my application, I can see my release manifest and its content is this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32"
name="Microsoft.VC80.CRT"
version="8.0.50727.762"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b">
</assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32"
name="Microsoft.VC80.MFC"
version="8.0.50727.762"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b">
</assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32"
name="Microsoft.VC80.CRT"
version="8.0.50727.4053"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b">
</assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>
If I remove the last entry, 8.0.50727.4053 in the manifest of the destination machine, I can run the application successfully but, why this entry is added to the manifest? How can I remove it?
regards
Manifests are the Microsoft solution to their DLL hell. There is one (libname, version) entry for every library your program use, so that Windows can load the correct version.
About the removal:
You can try if your VS version has the ability to link the MFC and CRT libraries statically into the executable. Then these items should disappear from the manifest.
If you can't statically link and you have full control about your runtime environment, you can simply ship without the .manifest file. When you can't control your runitme environment, it is better to create an installer for your application, which bundles the needed libraries.
When you build a project in VS2005, using the DLL Runtime, the compiler automatically includes information that is used to add dependentAssembly entries to the final manifest.
What is going on here then is probably caused by you including a static library project, built with VS2005 RTM, and now you are trying to build a project using VS2005 SP1.
Your solutions are:
Rebuild the static libraries in your project with the most recent VS2005, so all dependentAssemblies point to the same, latest, version.
Rebuild your EXE only, with options to force it to reference the RTM runtime. Instructions are here
Disable the automatic manifests entirely, and simply ship a hand crafted one with only a single dependentAssembly CRT reference, being your preferred CRT version.
I recently reformated which led me to install MSVC 2010. Everything seemed okay, except this time around I had Windows x64. I went ahead and rebuilt all of the dependencies for my project as x32 as some of them have issues with x64, but I am having this error message popup before my application even starts as debug build (it crashes immediately in release)
"This application has failed to start because its side-by-side configuration is incorrect."
I believe this is caused due to either my main project being written in MSVC9 and converted to MSVC2010 and/or my GUI library (CEGUI) doing the same thing.
Here is what my manifest looks like for my project...
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC90.DebugCRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
I don't know how to fix this, so any help would be great, thank you.
Yup - this is because your project manifest is specifying the VC90 CRT, and you've build and linked your application with the VC10 import libraries.
I'd fix this by creating a dummy VC2010 C++ project that uses the DLL version of the CRT, and copy the CRT section(s) from it's manifest to your project manifest.
I found MSVCR90D.dll not found in debug mode with Visual C++ 2008 question but none of given answers really gives answer to the question. Most of them point to turning off incremental linking but don't explain the true cause of the error and how it can be fixed without turning off incremental linking.
I'd like to mention that my situation is a little different than the one in the original question. I am using C++ compiler from Visual Studio 2008 but within Qt Creator not within Visual Studio.
Anyone?
Simply installing VS2008 Service Pack 1 will fix the problem, if it's an error where the Debug CRT is totally missing from the sxs folder.
I had this happen to me with a fresh install of VS2008 on 64 bit Windows 7 and a solution containing a VC++ project. The debug build would crash when the C++ assembly was loaded at runtime, with a side-by-side error.
On Vista and Win7 (but not XP) the SxS error gives details about exactly what assembly it tried and failed to load - in this case it was VC90.DebugCRT 9.0.22.19. I checked the (embedded) manifest for the VC assembly and sure enough, it included a reference to this assembly and version.
Checking the sxs directory (%System Drive%\Windows\WinSxS) showed that there was no VC90 DebugCRT installed in side-by-side at all! I had installed the VC++ runtimes, but these don't include a debug runtime. VS2008 is meant to install a debug runtime, but it wasn't there.
Turns out the original release of VS2008 doesn't install a 64 bit VC++ DebugCRT, but installing SP1 does. Once I'd done this, no more runtime exceptions and side-by-side errors.
You could use Dependency Walker to find out what version of msvcr90d.dll you program tries to find. May be some 3rd-party component linked to some version of msvcr90d.dll which you don't have.
You should check manifest.xml file. Try to remove all unnecessary dependencies.
Below is output from compiler. It's strange that running build the second time succeeds. However I suspect the problem might be due to this error with running mt.exe which is responsible for embedding information from manifest into executable...
Generating Code...
link /LIBPATH:"c:\Qt\4.5.2-vc\lib" /NOLOGO /DEBUG /MANIFEST /MANIFESTFILE:"debug\formExtractor.intermediate.manifest" /SUBSYSTEM:WINDOWS "/MANIFESTDEPENDENCY:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' publicKeyToken='6595b64144ccf1df' language='*' processorArchitecture='*'" /OUT:debug\formExtractor.exe #.\nmD932.tmp
mt.exe -nologo -manifest "debug\formExtractor.intermediate.manifest" -outputresource:debug\formExtractor.exe;1
'mt.exe' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'mt.exe' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
Exited with code 2.
UPDATE
Failing to run mt.exe during the linking process was indeed the cause of the problem. I added path to Windows SDK (C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin) to the PATH environment variable and I'm able to run executable now.
Comments to various answers;
#Shay
Output txt file from sxstrace is empty. Have no idea why. However there's the following information in the application log:
Faulting application formExtractor.exe, version 0.0.0.0, time stamp 0x4a638ee1, faulting module MSVCR90D.dll, version 6.0.6002.18005, time stamp 0x49e03824, exception code 0xc0000135, fault offset 0x0006f04e, process id 0xf68, application start time 0x01ca08ba801ac5cf.
Version 6.0.6002.18005?
What the heck is this?
#Kirill V. Lyadvinsky
Dependency Walker finds msvcr90d.dll used by qtwebkit4.dll file in
c:\windows\winsxs\x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.30729.1_none_bb1f6aa1308c35eb\MSVCR90D.DLL
but doesn't find (the other version of?) msvcr90d.dll file linked directly by the executable. However DW doesn't seem to show it's version anywhere, does it?
Contest of formExtractor.intermediate.manifest file
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level='asInvoker' uiAccess='false' />
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' publicKeyToken='6595b64144ccf1df' language='*' processorArchitecture='*' />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC90.DebugCRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
</assembly>
From the manifest file it looks like the executable is being linked to a different version of msvcr90d.dll than the qtwebkit4.dll. What's strange is the fact that both versions of msvcr90d.dll are present in c:\windows\winsxs folder in the following sub folders
x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.21022.8_none_96748342450f6aa2
and
x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.30729.1_none_bb1f6aa1308c35eb
Any ideas?
#knight666
I'm using Qt framework which I compiled using exactly the compiler I'm using now so I think there's no mismatch here. Additionally Dependency Walker shows the missing msvcr90d.dll file is linked directly to the executable so it's not a fault of any 3rd party library I think.
Disclaimer: I'm no real a Win32 master :)
I never used Qt Creator, but does it create a proper manifest for the exe?
maybe the manifest is for a different version (SP1 for example) and you have only the RTM version.
Are you using Vista? you can try to run SxsTrace to diagnose side by side issues.
update: in my case, i found that vc++ 2008 express has a 'Use FAT32 Work-around' (found in the configuration properties' "manifest tool" page); this resolves the problem. The help info for this option explains that FAT32 drives/partitions has a 2-second latency in the time stamp that prevents mt.exe from working properly. This seems to explain the somewhat random behavior of the problem.
Is it possible you have a version mis-match? I had a similar thing with Ogre, I had to recompile the SDK using the latest version of the third party library for it to compile.
i have the same problem with msvcr90d.dll not found in vs2008 c++ express ed.
The embedded manifest in the output .exe looks like this, when incremental link is enabled:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
</assembly>
No wonder msvcr90d.dll could not be found!
i tried 2 things:
A. using a hex editor, the above is overwritten with the <assembly> contents found in ./Debug/XXX.embed.manifest
B. use mt.exe -manifest ./Debug/XXX.embed.manifest -outputresource:./Debug/XXX.exe
Both methods seem to work. i used the 2nd method as a post-build event command:
mt.exe -verbose -manifest ./$(ConfigurationName)/$(TargetFileName).embed.manifest -outputresource:./$(ConfigurationName)/$(TargetFileName)
i don't know why the 'wrong' manifest is embedded in the 1st place when incremental link is enabled. if anyone knows why, please post.
Thanks!
lex