问题描述
我正在重组遗留的混合（托管和非托管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
因此，这是我尝试过的一些sceanrios。
-启用异常-> Win32异常-> c0000005，当抛出异常时，访问冲突将中断。我得到的最详细的信息还是来自上述堆栈跟踪。我已经尝试过使用F10的应用程序，但是在碰到任何断点之前它会失败，并且上面的堆栈跟踪也会失败。
-我已经删除了bridge DLL，以便它只有一个返回布尔值的方法，并且该方法被编码为仅返回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; }
如果存根DLL是使用/ clr标志编译的，则应用程序将失败。如果编译时没有/ clr标志，则该应用程序将运行。
-我已经使用Visual Studio向导为多文档应用程序创建了一个存根MFC应用程序，并调用了DllPassthrough :: IsFailed（）。即使使用/ clr标志来编译DLL，此操作也成功。
-我已尝试在winmm.lib上进行手动LoadLibrary，如以下说明所述时发生访问冲突。应用程序仍然失败。
那么，我的问题是如何解决问题？任何提示，策略或以前的事件。而且，如果失败，我如何获得有关导致访问异常的代码段或库的更多信息？如果我尝试进行诸如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 andcommenting 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 ++应用程序时发生访问冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！