找到System.AccessViolationException的原因 [英] finding the cause of System.AccessViolationException

问题描述

我们的应用程序遇到了奇怪的致命的System.AccessViolationException异常。我们看到这些，因为我们已经配置了AppDomain.CurrentDomain.UnhandledException事件来记录异常。

Our application experiences the odd fatal System.AccessViolationException. We see these as we've configured the AppDomain.CurrentDomain.UnhandledException event to log the exception.

Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
   at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.Run(Form mainForm)
   at Bootstrap.Run() in e:\build-dir\src\Bootstrap.cs:line 25

异常本身似乎不包含比消息更多的信息尝试阅读或写入受保护的内存，这通常表明其他内存已损坏。

The exception itself doesn't seem to contain any more information than the message "Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

• 我们现在可以采取哪些步骤来获取对问题的原因？


• 有没有办法确定导致崩溃的非法地址或指针值？


• 我们可以找到原生图书馆代码是否导致问题？


• 是否有更多的调试/跟踪功能可以启用？

• What steps can we now take to get to the cause of the problem?
• Is there any way to determine the illegal address or pointer value that caused the crash?
• Can we find out what native library code was causing the problem?
• Is there more debugging/tracing we can enable?

更新

• 是由早期非线程安全使用WinForms API引起的？

推荐答案

是完全相当于程序遇到问题，现在关闭，除了它被.NET运行时而不是操作系统捕获。

What you are experiencing is the exact equivalent to "The program has experienced a problem and will now close", except it's being caught by the .NET runtime, rather than the OS.

查看堆栈跟踪，它不会被您的代码触发，这使我认为它来自您正在使用的库或自定义控件生成的工作线程。

Looking at the stack trace, it's not being triggered by your code, which makes me think that it's coming from a worker thread spawned by a library you're using or a custom control.

跟踪这样的东西的唯一方法是在调试器下运行本机库，这样就可以在触发CLR层之前捕获访问冲突。这可能很容易或困难。

The only way to track something like this would be to run the native libraries under a debugger, which should trap the access violation before it bubbles up to the CLR layer. This can be easy or hard.

如果本机代码是您自己的项目，那么最简单的方法就是将.NET项目和C ++项目在同一个解决方案中，并确保.NET项目引用了C ++项目。如果您发布有关您的环境的更多详细信息，我可能会提供更具体的建议。

If the native code is your own project, then the easiest way to set this up is to put both the .NET project and the C++ project in the same solution, and ensure that the .NET project is referencing the C++ project. If you post more details about your environment, I may be able to give more specific advice.

这篇关于找到System.AccessViolationException的原因的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！