代码编织梦想

转自 : https://www.cnblogs.com/Braveliu/p/9342633.html

(1)dll动态库文件路径不对。此场景细分为以下几种情况:

1.1 文件路径的确错误。比如:本来欲加载的是A文件夹下的动态库a.dll,但是经过仔细排查原因,发现a.dll动态库竟然被拷贝到B文件夹下去了。

若真遇到这种低级错误,建议你找个没人的墙角蹲下用小拇指逆时针划圈圈去吧。。。

1.2 实参传值错误。比如:实参类型为LPCWTR,经常都会因为字符串转换导致实参事与愿违。

网上的经验总结实例。某程序员经过一番周折后通过以下语句调用成功

hDll = LoadLibrary(TEXT(“user32.dll”));

再经过一番百度google后发现,原来是字符格式惹的祸。

这里的LoadLibrary实际使用了LoadLibraryW而非LoadLibraryA,因此需要UNICODE字符串(宽字符串),而非窄字符串。 如下:

#ifdef UNICODE

#define LoadLibrary LoadLibraryW

#else

#define LoadLibrary LoadLibraryA

#endif // !UNICODE

在C/C++代码中,直接使用""定义的字符串为窄字节串,而windows头文件中提供的TEXT宏可以根据是否定义了UNICODE宏来自动选择字符串类型。

因此,利用TEXT宏使其自动选择了正确的字符集,dll调用成功。

(2)dll里有全局变量初始化失败或dllmain函数返回false。这种情况需要根据自己的业务代码具体分析排除与定位。

(3)64位进程调用了32位dll动态库的问题。

微软公司的官方网站针对这个问题描述如下:

在64位的windows系统中,一个64位进程不能加载一个32位dll,同理一个32位进程也不能加载一个64位dll。

如果您真都没有源码,只能如此“尴尬”的想正常运行,可以参见资料《64位进程调用32位dll的解决方法 / 程序64位化带来的问题和思考》

(4)其他原因

4.1 LoadLibrary函数跟LoadLibraryEx函数装载dll的机制不一样,前者在装载dll遇到与该dll依赖的其他dll时会自动装载,而后者不会。

网上有加载自己的dll无法成功的例子,排除路径问题的话(最好全路径),就要考虑该dll是否依赖到其它的dll。

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。 本文链接: https://blog.csdn.net/msk10k/article/details/103625371