msvcr90d.dll not found in debug mode - c++

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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