运行本机 C++ 时出现访问冲突使用 /clr 构建的 DLL 的应用程序

发布于 2024-08-28 19:52:34 字数 1195 浏览 4 评论 0原文

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

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

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

- 我已经删除了桥 DLL,以便它只有一个返回 bool 的方法,并且该方法被编码为仅返回 false(不调用任何 C# 代码)。

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

如果使用 /clr 标志编译已存根的 DLL,则应用程序将失败。如果编译时没有 /clr 标志,则应用程序将运行。

- 我使用 Visual Studio 多文档应用程序向导创建了一个存根 MFC 应用程序,并调用 DllPassthrough::IsFailed()。即使使用 /clr 标志来编译 DLL,此操作也会成功。

- 我尝试在 winmm.lib 上执行手动 LoadLibrary,如以下注释 使用 c++/cli 时发生访问冲突。申请仍然失败。

那么,我的问题是如何解决这个问题?任何提示、策略或以前的事件。如果做不到这一点,我如何获得有关导致访问异常的代码段或库的更多信息?如果我尝试更多涉及的解决方法,例如执行 LoadLibrary 调用,我想将其范围缩小到失败的库。

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

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   

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; }

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

荭秂 2024-09-04 19:52:34

我相信我解决了我的问题。通过系统地删除每个库引用和
在应用程序代码(非托管)中注释掉对该特定库的调用,我最终删除了问题库并让程序运行。这是诊断问题的一种强力方法,幸运的是我不需要删除太多库来解决它。如果可以通过调试器识别该库,我仍然很好奇是否有人有评论。
因此,下一步是将这些库调用移至托管代码,并通过我的桥接 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文