Microsoft Visual Studio:调试 dll 被发布模式中内置的二进制文件使用

发布于 2024-11-16 16:41:54 字数 369 浏览 1 评论 0原文

在我的 Visual Studio 2008 项目中,活动配置是“发布”,并且“编译器”和“链接器”设置中没有启用调试符号。我正在从命令提示符构建一个 exe 文件:

devenv standalone_cpp.sln /build "RELEASE|WIN32"

没有理由在运行时使用调试 dll MSVCR90d.dll,但它确实会崩溃。我不知道为什么只有调试 dll 被拾取,而不是发布 dll MSVCR90.dll。有人可以帮忙吗?

我什至尝试在调试模式下构建 .exe,希望它不会崩溃,但它仍然因相同的断言失败 _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) 而崩溃。在我开枪自杀之前请帮忙。

In my Visual Studio 2008 project, the active configuration is Release, and there are no debug symbols enabled in the Compiler and Linker settings. I'm building an exe file from command prompt:

devenv standalone_cpp.sln /build "RELEASE|WIN32"

There is no reason why a debug dll MSVCR90d.dll should get used at runtime, but it does and crashes. I don't have the slightest clue why only the debug dll gets picked up not the release dll MSVCR90.dll. Can someone please help?

I even tried building my .exe in debug mode hoping that it would not crash, but still it crashes with the same assertion failure _BLOCK_TYPE_IS_VALID(pHead->nBlockUse). Please help before I shoot myself.

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

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

发布评论

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

评论(2

苹果你个爱泡泡 2024-11-23 16:41:54

重新安装 MSVS2008 Service Pack 1。您的安装似乎已损坏。

我就遇到过这种情况——它表现为这样的神秘行为,尽管我在链接大型 DLL/EXE 时也看到过它表现为奇怪的“内部错误”,有时编译非常大的项目或非常大的翻译单元。由于某种原因,重新安装服务包有效。

这是一个快速链接:http://www.microsoft.com/downloads/en/details.aspx?FamilyId=FBEE1648-7106-44A7-9649-6D9F6D58056E&displaylang=en

另一种想法可能是您这样做了 将调试链接到您的发布可执行文件中。即使您为“RELEASE|WIN32”构建了解决方案,但如果任何先决条件(链接的库)是调试版本(直接引用 *.lib,或者您引用调试路径而不是发布路径),您最终会得到该组合,并且该 DLL 的“调试”版本将尝试加载。

然后,它崩溃的原因可能是您在“发布”模块中分配并在“调试”模块中删除(反之亦然)。这是行不通的,因为分配器是不同的(因为“调试”版本为哨兵和其他“调试检查”分配额外的状态)。

请记住,即使您从命令行构建,MSVS2008 也会使用 Tools==>Options 中的设置“覆盖”任何项目/解决方案设置。检查是否没有设置用于链接到发布目标的调试路径。 (这是 Microsoft 的一个错误决定,因为它导致项目/解决方案文件无法描述实际发生的情况,他们在 MSVS2010 中删除了该“功能”。)

您还可以看看:

Re-install the MSVS2008 Service Pack 1. Your install seems to have gotten corrupted.

I've had this happen -- it manifests with mysterious behavior like this, although I've also seen it manifest with strange "internal errors" when linking large DLLs/EXEs, and sometimes compiling very large projects, or very large translation units. For some reason, re-installing the service pack worked.

Here's a quick link: http://www.microsoft.com/downloads/en/details.aspx?FamilyId=FBEE1648-7106-44A7-9649-6D9F6D58056E&displaylang=en

Another thought might be that you did link debug into your release executable. Even though you built the solution for "RELEASE|WIN32", if any prerequisites (linked libs) were the debug version (either the *.lib was referenced directly, or you referenced the debug path instead of the release path), you'd end up with that mix and the "debug" version of that DLL would attempt to load.

Then, the reason it crashed, is probably that you allocated in a "release" module and deleted in a "debug" module (or vice versa). That won't work, because the allocators are different (since the "debug" versions allocate extra state for sentinels and other "debug checks").

Remember that MSVS2008 will "override" any project/solution settings with those found in Tools==>Options, even if you build from the command line. Check that no debug paths are set there for linking in your release targets. (That was a bad decision by Microsoft because it leads to project/solution files that do not describe what's actually happening, they removed that "feature" in MSVS2010.)

You might also have a look at:

泪之魂 2024-11-23 16:41:54

我认为@Charley 很赚钱。

下载 Dependency Walker 并查看实际导致调试 DLL 加载的原因。如果您在问题中所说的是正确的,那么它可能是您的 exe 所依赖的另一个库。

I think @Charley is on the money.

Download Dependency Walker and see what is actually causing the debug DLL to be loaded. If what you say in your question is correct, then it'll probably be another library that you exe is depending on.

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