调用LoadLibrary 193 [英] LoadLibrary 193

查看:3652
本文介绍了调用LoadLibrary 193的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我创建将被加载到一个传统的C ++应用程序中的C ++ / CLI DLL。遗留应用程序与传统的LoadLibrary调用做到这一点。无论是应用程序和C ++ / CLI DLL被编译在64位模式。

I am creating a C++/CLI dll that will be loaded into a legacy c++ application. The legacy application does this with a traditional call to LoadLibrary. Both the application and the C++/CLI dll are compiled in 64 bit mode.

在LoadLibrary调用发生时,出现错误193这通常意味着一些非64位组件试图加载。当我看到在Visual Studio 2010中的DLL加载输出,我看的时候MSCorEE.dll中被加载失败发生(准确的说,我看到我的DLL加载,然后mscoree加载,然后mscoree卸载,然后我的DLL卸载,则返回错误)。特别是C:\ WINDOWS \ SYSTEM32 \ MSCorEE.dll中是正装,当我研究这个MSCorEE.dll中,我发现,它的目标是I386。

When the LoadLibrary call happens, it fails with error 193. This usually means that some non-64bit component is trying to load. When I look at the dll load output in visual studio 2010, I see the the failure is occurring when mscoree.dll is being loaded (to be exact, I see my dll loaded, then mscoree loaded, then mscoree unloaded, then my dll unloaded, then the error returned). Specifically C:\Windows\System32\mscoree.dll is being loaded, when I examine this mscoree.dll, I find that it is targeting I386.

我如何确保我的应用将被正确MSCorEE.dll中链接?我理解这可能有一个清单来完成,但是我无法找到有关设置一上来什么好的信息。理想的解决方案将允许编译在32位或64位模式和目标正确MSCorEE.dll中。

How can I ensure that my application will link against the correct mscoree.dll? I understand this could be done with a manifest, but I can't find any good information about setting one up. The ideal solution would allow compilation in 32bit or 64bit mode and target the correct mscoree.dll.

作为一个方面说明,我发现了一个并排侧文件夹中的MSCorEE.dll中,我验证是64位​​模式,并将其复制到我的希望,这将拿起一个第一个应用程序目录。这没有工作和C:\ Windows \ System32下的版本中仍然加载

As a side note, I found an mscoree.dll in a side-by-side folder that I verified is 64bit mode and copied it into my application directory with the hopes that it would pick up that one first. This didnt work and the C:\Windows\System32 version was still loaded.

谢谢

最大

Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.0.30319.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32+
CorFlags  : 16
ILONLY    : 0
32BIT     : 0
Signed    : 0

pedump.exe对C输出:\ SYSTEM32 \ MSCorEE.dll中

PS C:\Windows\System32> pedump.exe .\mscoree.dll
Dump of file .\MSCOREE.DLL

File Header
  Machine:                      014C (I386)
  Number of Sections:           0004
  TimeDateStamp:                4B90752B -> Thu Mar 04 22:06:19 2010
  PointerToSymbolTable:         00000000
  NumberOfSymbols:              00000000
  SizeOfOptionalHeader:         00E0
  Characteristics:              2102
    EXECUTABLE_IMAGE
    32BIT_MACHINE
    DLL
...

(pedump继续从这里描述进口和出口,但多数民众赞成在这里并不重要)

(pedump goes on from here to describe imports and exports but thats not important here)

这是从失败的负载全力输出。

This is the full output from failed load.

注:C ++ / CLI DLL被称为DsfClr.dll
通过运行gflags.exe -i [EXENAME] + SLS和检查的结果在调试器得到的输出

Note: The C++/CLI dll is called DsfClr.dll
the output was obtained by running gflags.exe -i [exename] +sls and examining the results in a debugger

http://pastebin.com/FyumUiMN

使用贴在下面的评论由鲁本小费,我能够确定MSCorEE.dll中确实是针对AMD64,但pedump正在提供无效信息,因为它正在运行的WOW64。话虽这么说,我还是无法加载这个库,如果任何人有任何建议,他们将大大AP preciated。
还有一件事我曾尝试:我犯了一个新的C#应用​​程序,并参考了C ++ / CLI DLL,然后在main()函数,我在C ++ / CLI DLL实例化一个类。这在以前的main()函数被调用导致访问冲突异常。当我删除的实例,主要功能运行正常。我的猜测是,实例化是造成我的C ++ / CLI装配,这将导致相同的负载错误我是从本地组装看到的延迟加载。

Using a tip posted in a below comment by Reuben, I was able to determine that mscoree.dll is indeed targeting AMD64, but pedump is providing invalid information because it is being run in WOW64. That being said I still cannot load this library, if anyone has any suggestions they would be greatly appreciated.
One more thing I have tried: I made a new C# application and referenced the C++/CLI dll, then, in the main() function, I instantiated a class in the C++/CLI dll. This caused an access violation exception before the main() function is called. When I remove the instantiation, the main function runs fine. My guess is that the instantiation is causing a delay load of my C++/CLI assembly, which causes the same load error I was seeing from the native assembly.

推荐答案

在任何情况下,在整个这个错误运行,事实证明,这是我的本地库造成使用boost ::线程的。升压::线程库使用了一些奇怪的编译设置。其结果是一个静态库是与CLR或混合模式二进制不相容。当然,视觉工作室不知道这一点,所以它高兴地链接提振而崩溃时该dll被加载。
解决的办法是在提升动态链接::线程。要做到这一点,最简单的方法是在您的项目设置中定义BOOST_THREAD_DYN_LINK。一旦我确定的是,该dll加载的罚款。
快速谷歌搜索C ++ / CLI提升线程会给很多关于此错误的详细信息。

In case anyone runs across this error, it turned out that it was caused by my native libraries use of boost::threading. The boost::threading library uses some weird compilation settings. The result is a static library that is incompatible with clr or mixed-mode binaries. Of course, visual studio has no idea of this, so it happily links boost in and crashes when the dll is loaded.
The solution is to dynamically link in boost::threading. The easiest way to do this is to define BOOST_THREAD_DYN_LINK in your project settings. Once I defined that, the dll loaded fine.
A quick google search of C++/CLI boost threading will give plenty more information about this error

这篇关于调用LoadLibrary 193的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆