运行使用/clr 构建的 DLL 的本机 C++ 应用程序时的访问冲突 [英] Access violation when running native C++ application that uses a /clr built DLL

问题描述

我正在重组一个传统的混合(托管和非托管 DLL)应用程序，以便主应用程序段是非托管 MFC，并且将调用使用/clr 标志编译的 C++ DLL，该标志将桥接托管(C# DLL)之间的通信和非托管代码.不幸的是，我的更改导致在调用应用程序 InitInstance() 之前发生访问冲突.这使得调试非常困难.我得到的唯一信息是以下堆栈跟踪.

I'm reorganzing a legacy mixed (managed and unmanaged DLLs) application so that the main application segment is unmanaged MFC and that will call a C++ DLL compiled with /clr flag that will bridge the communication between the managed (C# DLLs) and unmanaged code. Unfortuantely, my changed have resulted in an Access violation that occurs before the application InitInstance() is called. This makes it very difficult to debug. The only information I get is the following stack trace.

>   64006108()  
ntdll.dll!_ZwCreateMutant@16()  + 0xc bytes 
kernel32.dll!_CreateMutexW@12()  + 0x7a bytes   

所以，这里有一些我尝试过的场景.
- 打开异常->Win32 异常->c0000005 访问冲突以在抛出时中断.我得到的最详细的信息仍然来自上面的堆栈跟踪.我已经使用 F10 尝试了该应用程序，但它在任何断点被击中之前就失败了，并且由于上面的堆栈跟踪而失败.

- 我删除了桥 DLL，因此它只有一个返回 bool 的方法，并且该方法被编码为只返回 false(没有调用 C# 代码).

So, here are some sceanrios I've tried.
- Turned on Exceptions->Win32 Exceptions->c0000005 Access Violation to break when Thrown. Still the most detail I get is from the above stack trace. I've tried the application with F10, but it fails before any breakpoints are hit and fails with the above stack trace.

- I've stubbed out the bridge DLL so that it only has one method that returns a bool and that method is coded to just return false (no C# code called).

bool DllPassthrough::IsFailed() { return false; }

如果使用/clr 标志编译存根的 DLL，应用程序将失败.如果在没有/clr 标志的情况下编译，应用程序将运行.

- 我已经使用 Visual Studio 向导为多文档应用程序创建了一个存根 MFC 应用程序并调用 DllPassthrough::IsFailed().即使使用用于编译 DLL 的/clr 标志，这也会成功.

- 我试过在 winmm.lib 上做一个手动 LoadLibrary，如下面的注释 使用 c++/cli 时的访问冲突.应用程序仍然失败.

那么，我的问题是如何解决问题?任何提示、策略或以前的事件.并且，如果失败，我如何获得有关导致访问异常的代码段或库的更多信息?如果我尝试更复杂的解决方法，例如调用 LoadLibrary，我想将其缩小到失败的库.

谢谢.顺便说一句，我们使用的是 Visual Studio 2008，并且该项目是针对托管部分的 .NET 2.0 框架构建的.

If the stubbed out DLL is compiled with the /clr flag, the application fails. If it is compiled without the /clr flag, the application runs.

- I've created a stub MFC application using the Visual Studio wizard for multidocument applications and call DllPassthrough::IsFailed(). This succeeds even with the /clr flag used to compile the DLL.

- I've tried doing a manual LoadLibrary on winmm.lib as outlined in the following note Access violation when using c++/cli. The application still fails.

So, my questions are how to solve the problem? Any hints, strategies, or previous incidents. And, failing that, how can I get more information on what code segment or library is causing the access exception? If I try more involved workarounds like doing LoadLibrary calls, I'd like to narrow it to the failing libraries.

Thanks. BTW, we are using Visual Studio 2008 and the project is being built against the .NET 2.0 framework for the managed sections.

推荐答案

我相信我解决了我的问题.通过系统地删除每个库引用和在应用程序代码(非托管)中注释掉对该特定库的调用，我最终删除了问题库并使程序运行.这是诊断问题的蛮力方法，幸运的是我不必删除太多库来解决它.如果可以通过调试器识别库，我仍然很好奇是否有人发表评论.
因此，下一步是将这些库调用移动到托管代码，并通过我的桥 DLL 将信息传递回非托管端.顺便说一句，我将 winmm.lib 重新集成到项目中，它仍然有效.

I believe I solve my problem. By systematically removing each library reference and commenting out the calls to that particular library in the application code (unmanaged), I eventually removed the problem library and got the program to run. It's a brute force way of diagnosing the problem, and fortunately I didn't have to remove too many libraries to solve it. I'd still be curious if anyone has a comment if the library could have been identified though the debugger.
So, the next step is to move these library calls to managed code and pass the information back to the unmanaged side via my bridge DLL. BTW, I reintegrated the winmm.lib into the project and it still works.

这篇关于运行使用/clr 构建的 DLL 的本机 C++ 应用程序时的访问冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！