检测异常是否为损坏状态异常

Question

我有一些调用Rotativa的代码,它调用了wkhtml2pdf.我怀疑从行为中我看到wkhtml2pdf.exe导致损坏的状态异常(CSE)被抛出.我想抓住并记录CSE,如果抛出,我可以追踪它发生的位置.

当我在调试器中让应用程序一夜之间运行时,当我回来时VS已关闭.有时它已重新启动,有时不会.怀疑内存腐败我开始研究并偶然发现CSE处理.

我正在做这样的事情:

[HandleProcessCorruptedStateExceptions]
void DoStuff()
{
     try
     {
          DOThatThingThatMakesTheDebuggerHaltAndShutDown();
     }
     catch(Exception ex)
     {
            //how do I detect that it's a CSE in here, so I can log it especially blatantly
     }
}

有没有办法检测例外是否是General Catch中的CSE？

我看到一个kludge,他们有2个一般的例外条款.内部的不处理CSE并设置标志.如果在没有旗帜的情况下调用外部,那么它就是CSE,但我希望能有更清洁的东西.我想做的是记录这个糟糕的状态,然后将它传递给应用程序以正常冒泡.

当我查看事件日志中导致VS2013失败的错误时,我得到了这个:

应用程序:devenv.exe Framework版本:v4.0.30319描述:由于未处理的异常,进程已终止.异常信息:异常代码0000005,异常地址4DA44C1F堆栈:在Microsoft.VisualStudio.Debugger.Clr.NativeDkmClrModuleInstance.ProcF4BC786AEBAC294EE9C4C0BB1B0F56A7(IntPtr的,IntPtr的为ByRef)在Microsoft.VisualStudio.Debugger.Clr.DkmClrModuleInstance.GetMetaDataImport()在Microsoft.IntelliTrace.Concord Microsoft.IntelliTrace.Concord.Integration.CpdeNotifyPointServiceAdapter.InstallBreakpoint中的.MetadataHelper..ctor(Microsoft.VisualStudio.Debugger.Clr.DkmClrModuleInstance)(Microsoft.VisualStudio.Debugger.Clr.DkmClrModuleInstance,Microsoft.VisualStudio.Debugger.Interop.Internal.NP_INSTALL_REQUEST )
在Microsoft.IntelliTrace.Concord.Integration.CpdeNotifyPointServiceAdapter.BindToModule(Microsoft.VisualStudio.Debugger.Clr.DkmClrModuleInstance)在Microsoft.IntelliTrace.Concord.IntelliTraceProcessState.AlertModuleLoad(Microsoft.VisualStudio.Debugger.DkmModuleInstance)在Microsoft.IntelliTrace.Concord. NotifyPoints.NotifyPointManager.OnModuleInstanceLoad(Microsoft.VisualStudio.Deb Microsoft.VisualStudio.Debugger.EntryPoint.IDkmModuleInstanceLoadNotification_OnModuleInstanceLoad(IntPtr,IntPtr,IntPtr,IntPtr)中的ugger.DkmModuleInstance,Microsoft.VisualStudio.Debugger.DkmWorkList,Microsoft.VisualStudio.Debugger.DkmEventDescriptorS)

接下来是这样的:

错误应用程序名称:devenv.exe,版本:12.0.30501.0,时间戳:0x5361f453错误模块名称:vsdebugeng.impl.DLL,版本:12.0.30501.0,时间戳:0x5361f482异常代码:0xc0000005错误偏移量:0x00094c1f错误进程ID: 0x1c9c错误应用程序启动时间:0x01cfe7cc0cf50465错误应用程序路径:C:\ Program Files(x86)\ Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe错误模块路径:C:\ Program Files(x86)\ Microsoft Visual Studio 12.0\Common7\Packages\Debugger\vsdebugeng.impl.DLL报告ID:097b17c6-5438-11e4-8409-001f2904053c

Answer 1

请记住，不存在“CorruptedStateException”之类的东西。它只是一个收集器用语，是 CLR 团队认为“过于讨厌”的一组例外情况。他们故意不记录他们在该集中放置了哪些类型的异常，只是有“大约十几个”并且它们最初是 Windows SEH 异常。我知道唯一肯定在该集合中的是 AccessViolationException。在你的情况下，导致 VS 崩溃的那个。很常见，但也很令人讨厌。

该功能已添加到 .NET 4.0 中，以帮助程序员完成您所做的事情，即使用 .NET 捕获所有异常处理catch (Exception)。然后让程序继续运行。这有一个糟糕的技巧，他们还会捕获真正令人讨厌的异常，这种异常是他们永远不应该捕获的，因为它们保证是不可恢复的。常常在不知不觉中。由此导致的程序故障很难诊断，可能需要一段时间才能检测到错误行为。

我可以推测该集中还有哪些其他 SEH 例外情况。但这只是猜测。关键是你不必知道。任何具有 [HandleProcessCorruptedStateExceptions] 的方法都应该是外部异常处理程序，在线程入口处激活。就像 Main() 一样。并且做的事情很少，这是 SEH 处理程序应该做的事情，只是让用户知道程序失败的原因并调用Environment.FailFast()。

因此，现在catch (Exception) 不用该属性进行编程就可以了，CLR 在查找处理程序时会跳过它。你不可能不小心吞下那些讨厌的东西。您的情况可能有点不同，看起来像一个没有明确定义的线程入口点的加载项。使用 try/catch 将方法主体移动到另一个方法中，并忽略该方法的属性。为了由具有该属性的方法调用，它现在可以安全地假设它捕获了令人讨厌的方法之一。

当然，请确保当 VS 捕获时不要让 VS 继续运行。调试器状态被炸成碎片，调试会话肯定已经结束，试图继续使用它的程序员将会以糟糕的方式结束。因此，显示一个消息框并快速失败或重新抛出。