【问题标题】:Is it reasonable to use SEH to protect my code from exceptions thrown by third party COM objects使用 SEH 保护我的代码免受第三方 COM 对象抛出的异常是否合理
【发布时间】:2012-04-22 23:00:43
【问题描述】:

我正在保护我自己的 C++ 代码 (Windows x86) 免受第三方 COM 对象中的异常影响,并使用以下 SEH 伪代码记录这些异常。

__try {
    hr = m_ComObj->SomeFunc();
} __except ( LogExceptionInfo(GetExceptionCode(), GetExceptionInformation()) ) {
    hr = E_UNEXPECTED;
    m_ComObjCrashed = true;
}

如果 SEH 代码不存在,这种方法是否可能捕获将要处理的异常?

下面的一篇 MSDN 文章提到,默认的未处理异常过滤器将捕获并修复代码在加载的资源中写入内存的情况。在其他情况下,使用 SEH 会干扰理想的默认操作系统行为吗?

A Crash Course on the Depths of Win32™ Structured Exception Handling

【问题讨论】:

  • 嗯,你怎么知道异常是可恢复的?可能某个关键部分被孤立了,或者异常是由内存损坏引起的。
  • 好点。发生异常后我不会继续正常执行,只是将其用作更优雅的故障形式并在过滤器函数中记录一些崩溃信息(第三方 COM 对象包含阻止 MiniDumpWriteDump 工作的反调试代码)。跨度>
  • cf 我之前的问题是关于使用 SEH 记录崩溃信息的动机stackoverflow.com/questions/9977545/…
  • 但是在您的过滤器函数记录崩溃信息后,程序会恢复执行。这很可能会导致更严重(更令人困惑)的崩溃。

标签: windows exception com seh


【解决方案1】:

是的,这很合理。

它将捕获 COM 函数中未处理的所有异常

我没有发现任何与默认操作系统行为有关的干扰问题

【讨论】:

  • 默认的未处理异常过滤器执行以下操作(从上面的链接粘贴)。我担心使用我自己的 SEH 处理会禁用此行为,并想知道它可能会改变什么。 “如果由于写入 EXE 或 DLL 的资源部分 (.rsrc) 而发生异常,BasepCurrentTopLevelFilter 会将故障页面的属性从其正常的只读状态更改,从而允许写入发生。如果这种特殊情况发生时,UnhandledExceptionFilter 返回 EXCEPTION CONTINUE_EXECUTION 并在错误指令处重新开始执行。”
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-07-24
相关资源
最近更新 更多