CLR 在非 CLR 创建的线程中托管异常处理

Question

问题：

从非托管代码进入 CLR 的线程中的未处理异常不会触发“正常”未处理异常 CLR 处理。

在下面的代码中，使用

• “1”从 C++ 调用 CSSimpleObject.GetstringLength() 会在调用线程（非 CLR 创建的线程）中引发异常，
• “2”会在新线程中引发异常（ )（CLR 创建的线程）。

如果“1”

• CurrentDomain_UnhandledException() 永远不会被调用。
• 应用程序域和进程将保持加载并运行，您只会得到失败。

如果是“2”（预期行为），

• 则调用 CurrentDomain_UnhandledException()。
• 进程被杀死。

问题：

必须做什么才能获得“正常”行为？

示例代码：

下面的代码基于 Visual Studio 2010“CppHostCLR”代码示例 来自“所有互操作和融合示例”。

RuntimeHost (C++)：

PCWSTR pszStaticMethodName = L"GetStringLength";
PCWSTR pszStringArg = L"1";
//PCWSTR pszStringArg = L"2";

hr = pClrRuntimeHost->ExecuteInDefaultAppDomain(pszAssemblyPath,
    pszClassName, pszStaticMethodName, pszStringArg, &dwLengthRet);
if (FAILED(hr))
{
    wprintf(L"Failed to call GetStringLength w/hr 0x%08lx\n", hr);
    goto Cleanup;
}

托管代码 (C#)：

public class CSSimpleObject
{
    public CSSimpleObject()
    {
    }
    //------8<----------
    public static int GetStringLength(string str)
    {
        AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

        switch (str)
        {
            case "1":
                throw new Exception("exception in non-CLR-created thread");
            case "2":
                Thread thread = new Thread(new ThreadStart(WorkThreadFunction));
                thread.Start();
                break;
        }
        return str.Length;

    }
    static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        Console.WriteLine("CurrentDomain_UnhandledException:" + e.ToString());
        Console.ReadKey();
    }
    public static void WorkThreadFunction()
    {
        throw new Exception(""exception in CLR-created thread"");
    }

迄今为止的研究：

MSDN 最初暗示非 CLR 创建的线程中未处理的异常应该或多或少“自然”地运行 - 请参阅“托管线程中的异常"

公共语言运行时允许线程中大多数未处理的异常自然地进行。在大多数情况下，这意味着未处理的异常会导致应用程序终止。”

“大多数”意味着在 CLR 创建的线程内部、线程中止和应用程序域卸载异常的处理方式不同。在非 CLR 线程中

“他们正常进行，导致应用程序终止。”

进一步的研究让我找到了“CLR 中未处理的异常处理”，我发现了以下内容：

“如果在托管方法中未处理异常...，异常将退出 CLR，但会继续作为本机 SEH 异常在堆栈中向上传播（托管异常表示为本机 SEH 异常）... 操作系统未处理异常过滤器 (UEF) 机制可能并不总是会触发 CLR 的未处理异常处理。 正常情况下，这会按预期工作，并且会触发 CLR 的未处理异常处理。然而，在某些情况下，这可能不会发生。”

上面的代码有什么问题，或者如何更改它以便触发 CLR 的未处理异常处理？

更新 (2011-05-31)：

我刚刚发现了一个旧的错误报告，“当从非托管调用托管代码并引发异常时，不会调用 UnhandledExceptionEventHandler - http://tinyurl.com/44j6gvu”，其中微软确认这是一种“有缺陷”的行为：

感谢您花时间报告此问题。 该行为确实是 CLR 执行引擎和 CRT 争夺 UnhandledExceptionFilter 引起的错误。 4.0版本中对CLR的架构进行了修改，支持该场景。

更新（2011-06-06）：

为什么正确处理这一点很重要？

• 如果您正在创建一个托管环境，您的开发人员期望异常处理中的行为一致
• ，除非有一种方法可以在本机线程中触发“正常的 CLR 异常处理”，这意味着您始终必须将执行转移到托管线程（排队）例如在线程池中）
• 仍然有一小部分代码将执行从本机线程传输到托管线程...必须捕获所有异常并以某种方式以不同方式处理该情况

注意：更改 CLR 行为从某种意义上说，通过 SetActionOnFailure() 使事情变得更糟，它最终掩盖了原始异常（即，您最终看到的不是内存不足，而是 threadAborts - 不知道原始错误来自何处） ！

Answer 1

更新意味着您可能在这里找到了解决方案。然而，它的解决方案并不适用于所有情况，所以这里有一些更多信息。

如果您更喜欢 CLR 未处理的异常行为，请将其作为最外层程序并仅调用本机代码来执行特定功能。这将确保 CLR 获得对未处理异常过滤器的控制。

如果您想保留当前的结构并且您拥有的 C++ 代码很小，您可以完全停止使用 CRT（这将拒绝您使用许多有用的东西，包括静态构造函数和 C++ 异常处理）。这将确保 CLR 获取未处理的异常过滤器。

当然，您可以简单地自己调用 SetUnhandledExceptionFilter 并获得您想要的行为。

但是，我认为在这种情况下最好的建议是将带有 catch 块的实际函数放在任何线程的调用堆栈上，当异常发生时您希望在该线程中执行某些操作，而不是依赖 UEF 机制 - 因为在上下文中对于一个组件系统来说，当多个用户竞争它时，它总是脆弱的。

马丁