如何在检测到 AccessViolationException 时强制应用程序崩溃

2024-01-31

我们使用自动崩溃报告工具(即http://crashrpt.sourceforge.net http://crashrpt.sourceforge.net)用于生成崩溃报告。

因此,如果一段非托管代码通过访问NULL例如,指针,应用程序崩溃,崩溃报告工具激活,我们获得可用的堆栈跟踪来诊断和分组问题。

问题是 .NET 在某些情况下似乎会干扰崩溃处理。一个示例如下:

this.Dispatcher.BeginInvoke((ThreadStart)delegate
{
  // Send message to unmanaged control for performing a specific task.
  User32.SendMessage(...);
}, DispatcherPriority.Input);

如果非托管组件因访问冲突而失败,内部 .NET 方法会捕获实际上应该是崩溃的内容,如下所示AccessViolationException并将其重新包装在一个TargetInvocationException首先,然后崩溃(如果不使用方法调用,它就不会这样做)。

这非常不方便,因为本机堆栈信息完全丢失。剩下的是以下堆栈,与非托管部分到底在哪里失败无关:

kernelbase!RaiseException+0x6c
clr!RaiseTheExceptionInternalOnly+0x276
clr!RaiseTheException+0x86
clr!RaiseTheExceptionInternalOnly+0x30a
clr!RealCOMPlusThrow+0x2f
clr!ThrowInvokeMethodException+0xac
clr!RuntimeMethodHandle::InvokeMethod+0xa64
mscorlib_ni+0x2d37b1
mscorlib_ni+0x2cf92a
windowsbase_ni+0xd77b1
windowsbase_ni+0xd768a
windowsbase_ni+0xc2d5c
windowsbase_ni+0xc2c98
mscorlib_ni+0x302346
mscorlib_ni+0x302301
windowsbase_ni+0xc2b9b
windowsbase_ni+0xd640b
windowsbase_ni+0xd65ca
windowsbase_ni+0xd798b
windowsbase_ni+0xd78db
windowsbase_ni+0xd7756
windowsbase_ni+0xd768a
windowsbase_ni+0xd5cae
windowsbase_ni+0xd71e1
user32!InternalCallWinProc+0x23
user32!UserCallWinProcCheckWow+0x100
user32!DispatchMessageWorker+0x3ef
user32!DispatchMessageW+0x10
windowsbase_ni+0xddca8
windowsbase_ni+0xd5636
windowsbase_ni+0xd5325
windowsbase_ni+0xb27d3
presentationframework_ni+0x2721b7
presentationframework_ni+0x271e0f
presentationframework_ni+0x271baa
clr!CallDescrWorkerInternal+0x34
clr!CallDescrWorkerWithHandler+0x6b
clr!MethodDescCallSite::CallTargetWorker+0x152
clr!RunMain+0x1aa
clr!Assembly::ExecuteMainMethod+0x124
clr!SystemDomain::ExecuteMainMethod+0x614
clr!ExecuteEXE+0x4c
clr!_CorExeMainInternal+0xdc
clr!_CorExeMain+0x4d
mscoreei!_CorExeMain+0x10a
mscoree!ShellShim__CorExeMain+0x7d
mscoree!_CorExeMain_Exported+0x8
kernel32!BaseThreadInitThunk+0xe
ntdll!__RtlUserThreadStart+0x72
ntdll!_RtlUserThreadStart+0x1b

当非托管组件发生故障时,我们如何防止这种情况并强制应用程序立即崩溃?


尝试这个:

this.Dispatcher.BeginInvoke((Action) delegate 
{
    User32.SendMessage(...);
}, DispatcherPriority.Input);

应用程序应该按照您希望的方式崩溃。


我见过的大多数例子都调用Dispatcher.BeginInvoke()与匿名委托一起使用Action.

  • https://richnewman.wordpress.com/2012/12/03/tutorial-asynchronous-programming-async-and-await-for-beginners/ https://richnewman.wordpress.com/2012/12/03/tutorial-asynchronous-programming-async-and-await-for-beginners/
  • http://tech.pro/tutorial/800/working-with-the-wpf-dispatcher http://tech.pro/tutorial/800/working-with-the-wpf-dispatcher

为什么会出现这种情况?

看起来 CLR 代码在下面:

at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.DispatcherOperation.InvokeImpl()

调用一个Action大多数其他委托都是使用反射直接调用的。

反射机制会将异常包装在TargetInvocationException.

See 这个答案 https://stackoverflow.com/a/28746677/4593760到另一个问题来解释一下。


其他不会包装异常的特殊情况委托有:DispatcherOperationCallback and SendOrPostCallback,尽管要工作它们必须用一个参数来调用。

this.Dispatcher.BeginInvoke(DispatcherPriority.Input,
    (SendOrPostCallback)(delegate(object o)
    {
        throw new AccessViolationException(o.ToString());
    }), "test");
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

如何在检测到 AccessViolationException 时强制应用程序崩溃 的相关文章

随机推荐