当前位置： 文江博客话题详情

在调试模式下找不到 msvcr90d.dll

发布于 2024-07-29 02:25:01 字数 381 浏览 3 评论 0原文

我发现 在调试模式下找不到 MSVCR90D.dll与 Visual C++ 2008 问题，但给出的答案都没有真正给出问题的答案。 其中大多数都指出关闭增量链接，但没有解释错误的真正原因以及如何在不关闭增量链接的情况下修复该错误。

我想指出的是，我的情况与原始问题中的情况略有不同。 我使用的是 Visual Studio 2008 中的 C++ 编译器，但在 Qt Creator 中而不是在 Visual Studio 中。

任何人？

原文

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?

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（7）

倾城泪 2024-08-05 02:25:01

如果出现 sxs 文件夹中完全缺少 Debug CRT 的错误，只需安装 VS2008 Service Pack 1 即可解决该问题。

我在 64 位 Windows 7 上全新安装 VS2008 并使用包含 VC++ 项目的解决方案时就遇到了这种情况。 当在运行时加载 C++ 程序集时，调试构建会崩溃，并出现并行错误。

在 Vista 和 Win7（但不是 XP）上，SxS 错误提供了有关它尝试加载但未能加载的程序集的详细信息 - 在本例中为 VC90.DebugCRT 9.0.22.19。 我检查了 VC 程序集的（嵌入）清单，果然，它包含对此程序集和版本的引用。

检查sxs目录（%System Drive%\Windows\WinSxS）发现根本没有并行安装VC90 DebugCRT！ 我已经安装了 VC++ 运行时，但其中不包括调试运行时。 VS2008 本来是要安装调试运行时的，但它不存在。

原来是VS2008的原始版本 不会安装 64 位 VC++ DebugCRT，但安装 SP1 会安装。 完成此操作后，不再出现运行时异常和并行错误。

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.

回复 原文
挖个坑埋了你 2024-08-05 02:25:01
  1. 您可以使用 Dependency Walker 来找出您的程序尝试查找的 msvcr90d.dll 版本。 可能是某些第三方组件链接到您没有的某些版本的 msvcr90d.dll。
  2. 您应该检查manifest.xml 文件。 尝试删除所有不必要的依赖项。
  1. 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.
  2. You should check manifest.xml file. Try to remove all unnecessary dependencies.
回复 原文
樱花细雨 2024-08-05 02:25:01

以下是编译器的输出。 奇怪的是，第二次运行build竟然成功了。 但是我怀疑问题可能是由于运行 mt.exe 时出现此错误造成的，该错误负责将清单中的信息嵌入到可执行文件中...

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.

更新

在链接过程中无法运行 mt.exe 确实是问题的原因。 我将 Windows SDK 的路径 (C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin) 添加到 PATH 环境变量中，现在可以运行可执行文件。

对各种答案的评论；

@Shay

sxstrace 的输出 txt 文件是空的。 不知道为什么。 但是应用程序日志中有以下信息：

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.

版本 6.0.6002.18005？
这到底是什么？

@Kirill V. Lyadvinsky

Dependency Walker 在
中找到 qtwebkit4.dll 文件使用的 msvcr90d.dll
c:\windows\winsxs\x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.30729.1_none_bb1f6aa1308c35eb\MSVCR90D.DLL

但找不到（另一个版本？）msvcr90d.dll 文件由可执行文件直接链接。 但是 DW 似乎没有在任何地方显示它的版本，是吗？

formExtractor.intermediate.manifest 文件的竞争

<?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>

从清单文件来看，可执行文件似乎链接到了与 qtwebkit4.dll 不同版本的 msvcr90d.dll。 奇怪的是，两个版本的 msvcr90d.dll 都存在于 c:\windows\winsxs 文件夹的以下子文件夹中
x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.21022.8_none_96748342450f6aa2
和
x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.30729.1_none_bb1f6aa1308c35eb

有什么想法吗？

@knight666

我正在使用 Qt 框架，它是使用我现在使用的编译器编译的，所以我认为这里没有不匹配。 此外，Dependency Walker 显示丢失的 msvcr90d.dll 文件直接链接到可执行文件，因此我认为这不是任何第三方库的错误。

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.

回复 原文
椒妓 2024-08-05 02:25:01

免责声明：我不是真正的 Win32 高手:)

我从未使用过 Qt Creator，但它是否为 exe 创建了正确的清单？
也许清单适用于不同的版本（例如 SP1），而您只有 RTM 版本。
你用的是Vista吗？ 您可以尝试运行 SxsTrace 来进行诊断附带问题。

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.

回复 原文
平安喜乐 2024-08-05 02:25:01

更新：就我而言，我发现 vc++ 2008 Express 有一个“使用 FAT32 解决方法”（可在配置属性的“清单工具”页面中找到）； 这解决了问题。 此选项的帮助信息解释说，FAT32 驱动器/分区的时间戳有 2 秒的延迟，导致 mt.exe 无法正常工作。 这似乎解释了问题的某种随机行为。

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.

回复 原文
吾性傲以野 2024-08-05 02:25:01

是否有可能版本不匹配？ 我对 Ogre 也有类似的情况，我必须使用最新版本的第三方库重新编译 SDK 才能编译。

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.

回复 原文
待＂谢繁草 2024-08-05 02:25:01

我有同样的问题，在 vs2008 c++ express ed 中找不到 msvcr90d.dll。
当启用增量链接时，输出 .exe 中的嵌入清单如下所示：


<程序集manifestVersion =“1.0”xmlns =“urn：schemas-microsoft-com：asm.v1”>

难怪找不到msvcr90d.dll！

我尝试了两件事：

A.使用十六进制编辑器，上面的内容被<程序集>覆盖。 ./Debug/XXX.embed.manifest 中找到的内容

B. 使用 mt.exe -manifest ./Debug/XXX.embed.manifest -outputresource:./Debug/XXX.exe

两种方法似乎都有效。 我使用第二种方法作为构建后事件命令：

mt.exe -verbose -manifest ./$(ConfigurationName)/$(TargetFileName).embed.manifest -outputresource:./$(ConfigurationName)/$(TargetFileName)

i不知道为什么启用增量链接时，“错误”清单会嵌入到第一个位置。 如果有人知道为什么，请发帖。

谢谢！

莱克斯

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

回复 原文
~没有更多了~

关于作者

后知后觉

暂无简介

0 文章
0 评论
847 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

linfzu01

文章 0 评论 0

§对你不离不弃

文章 0 评论 0

可遇━不可求

文章 0 评论 0

枕梦

文章 0 评论 0

qq_3LFa8Q

文章 0 评论 0

JP

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文