1. 一开始报错
下载dll放到同级目录后报下一个错误。
(这里注意:搜索的时候就发现大多数dll都是 vc_runtime 140 没有d,d表示debug。同事指点:使用vscode生成解决方案时要用release模式,不是debug模式,这也是导致我解决方式1和2失败的原因。)
下载dll放到同级目录后报错应用程序无法正常启动0xc000007b
2.应用程序无法正常启动0xc000007b
·
之前自己用vs2019写的一个单纯的控制台程序(调用使用了MFC的dll程序),在安装了vs2019的win7上可以运行,但是在没有安装vs2019的电脑上就不能运行,提示了标题错误。
搜索过一些常规解决方案,例如:
2.1 无效:解决1
这个问题,根据 应用程序无法正常启动0xc000007b怎么解决。主要是由于DirectX 9.0被损坏,需要下载软件运行一下(主要还是win7系统缺失了很多dll文件造成的)
打开DirectX修复工具,
- 检测并修复
- 工具->选项->扩展->开始扩展(联网状态下完成)
- 重启
依然报错。
2.2 无效:解决2
第二种解决方案,根据教您解决应用程序无法正常启动(0xc000007b)
管理员身份打开cmd,输入
sfc /scannow
# 显示
开始系统扫描。此过程需要一些时间开始系统扫描的验证阶段。
验证XX%已完成。 # 等上述进度变成100%
可以在路径查看修复情况,最后显示如下:(也需要重启)
2.3 无效:解决3 找对应的分发包
参考 正确解决:坑爹的0xc000007b——应用程序无法正常启动可知:
肯定是缺乏了一些什么包,但是这个人的说法太含糊了
请教公司一个c++开发的前辈,经过高人指点,下载分发包,软件环境,就需要Microsoft VC++ Redistributable 2015这个可再分发包即可(我的可以运行的电脑是win7 vs2019)
下载 Visual C++ Redistributable for Visual Studio 2015:报错按不上,显示样本机(测试机)有一个更新的版本的时候就不能安装这个。
测试机版本:
所以找找更新的版本,下载Visual Studio 2015、2017 和 2019。
这个版本号是 14.27.29112(x86和x64都是这个版本号)
试了之后还是没用
比我本机用的要新了很多啊。。。找到本机用的吧。
在本机目录,vs2019的安装目录下,
D:\visual studio2019\VC\Redist\MSVC\14.27.29016
就可以找到和自己电脑安装的分发版本一致的这个exe包
依然没用,哈哈哈
2.4 使用工具查看缺乏/冲突dll文件
参考:应用程序无法正常启动0xc000007b解决方法
根据Dependency Walker使用说明,去这个网站下载这个软件:dependencywalker
File->Open
打开要查看dll依赖关系的exe文件,然后就会出现结果。
2.5 OK 解决4:vs studio使用release生成解决方案
又忘了visual studio这个软件的一些使用方式,不常用就是难受。
我的解决方案下有两个项目,
- 控制台应用 类型 (这个用来调用dll)
- 动态链接库(DLL)类型 用来完成功能
使用的时候,将调用dll的那个项目设置为设为启动项目
,
- 先 DLL的那个项目直接在
解决方案资源管理器
里右击项目名称重新生成
即可。 - 然后直接菜单栏上
生成
->生成解决方案
在将配置管理器
部分的Debug
模式变成Release
模式之后,报了新的错误。(Debug模式下不报错,换成release模式就报错,也是奇怪。。。)
继续解决这个项目的错误
2.5.1 MFC dll共享设置错误
E0035 #error 指令: Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d] produce_dll C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\atlmfc\include\afx.h 24
C1189 #error: Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d] produce_dll C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\atlmfc\include\afx.h 24
看起来是一个错。
根据error Please #define _AFXDLL or do not use /MD[d] occurs even after making changes in Project Properties
想起来以前debug模式下调试的时候也遇到过这个错误,没想到换个release模式还要从重新设置。
vs2019的设置位置是:解决方案资源管理器
->右击项目名称->属性->高级->MFC的使用->选择在共享DLL中使用MFC
此外,注意 项目属性页(下图)中的配置和平台与运行界面的 并不总是一致,
所以可以直接把平台写成所有
(Debug中不设置可以运行,但是release不这样就不行??)
2.5.2 error LNK2005: _DllMain@12 already defined in XXX.lib
错误 LNK2005 _DllMain@12 已经在 mfcs140u.lib(dllmodul.obj) 中定义
produce_dll E:\2.电动工具所\experiment02_C++\produce_dll\dllmain.obj 1
大部分中文博客都知道原因是什么:
dll文件的cpp文件中默认就有dllmain这个函数,当添加MFC库时,在其中已经定义了DLLMAIN这个方法
解决方案基本都是参考:
基于MFC的dll中添加DllMain函数,编译时产生_DllMain@12 已经在 XXX.obj 中定义的解决方法
看到咧,vs2019的在这里(平台要选个特定的,不能选所有。。。)
但是我不太喜欢这种解决方式,调配置,太马后炮了
还有一些是去掉dll的cpp文件中的dllmain函数。。。。更不靠谱,例如由于引用MFC库导致DllMain重复定义问题解决 error LNK2005
解决方式2 推荐
根据error LNK2005: _DllMain@12 already defined in MSVCRT.lib
。
简单来说:就是在你编写dll的cpp文件最后加上一句代码
extern "C" { int _afxForceUSRDLL; }
英语的大意是:
当我们使用MFC的时候,会直接/间接的include
文件afx.h
,然后MFC(afx.h)告诉链接器去寻找 _afxForceUSRDLL
这个符号,然后把包含 _afxForceUSRDLL
这个符号的对象放到程序中去,这样链接器就找到并把 dllmodule.obj
放到程序中了,因为_afxForceUSRDLL
是在dllmodule.cpp
文件中定义的。
这是最常见的场景,当我们想在 共享DLL中使用MFC时,链接器编译时发现有两个DllMain
函数,一个在我们自己编写dll的cpp文件中,另一个在Dllmodule.obj
中。
所以我们需要告诉链接器把 _afxForceUSRDLL
这个符号加到我们的dllmodule.obj
中,为此我们要在自己写的DllMain函数定义的cpp文件里定义 _afxForceUSRDLL
。这样链接器就会忽略mfc模块中的dllmodule.obj
,只看到我们自己定义的那个DllMain。就好了
2.5.3 其他知识
debug模式下生成的dll文件有180KB,exe文件有39KB
但是release模式下生成的dll文件只有28KB,exe文件有10KB。
原来这个东西还是不太一样哦,哈哈。还是release模式好,么么哒(*  ̄3)(ε ̄ *)