Обработка исключения исключений CLR в потоке, создаваемом не CLR

Проблема:

Необработанное исключение в потоке, входящем в CLR из неуправляемого кода, не вызывает обработку "нормального" необработанного исключения CLR.

В коде ниже вызывается CSSimpleObject.GetstringLength() из С++ с

• "1" генерирует исключение в вызывающем потоке (поток, созданный не CLR),
• "2" генерирует исключение в новом потоке Thread() (поток, созданный CLR).

В случае "1"

• CurrentDomain_UnhandledException() никогда не вызывается.
• домен приложения, и процесс останется загруженным и запущенным, вы получите только FAILED.

В случае "2" (ожидаемое поведение)

• Вызывается CurrentDomain_UnhandledException().
• Процессы убиваются.

Вопрос:

Что нужно сделать, чтобы получить "нормальное" поведение?

Пример кода:

Нижеприведенный код основан на примере кода Visual Studio 2010 CppHostCLR "из всех образцов взаимодействия и слияния.

RuntimeHost (С++):

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;
}

Управляемый код (С#):

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, внутренние, прерывания потока и исключения из загрузочного домена Application Domain обрабатываются по-разному. В не-CLR-потоках

"они идут нормально, что приводит к прекращению действия приложения."

Дальнейшие исследования привели меня к обработке необработанных исключений в среде CLR", где я узнал следующее:

", если исключение не обрабатывалось... в управляемом методе исключение вышло из CLR, но продолжает распространять стек как собственное исключение SEH (управляемые исключения представлены как собственные исключения SEH)... Механизм фильтра необработанных исключаемых ОС (UEF) может не всегда приводить к запуску обработки необработанных исключений CLR. В нормальных условиях это будет работать, как ожидалось, и обработка обработанных обработок CLR без обработки. Однако в некоторых случаях это может не произойти".

Что не так с приведенным выше кодом или как его можно изменить так, чтобы запускалась обработка необработанных исключений CLR?

Обновление (2011-05-31):

Я только что нашел старый отчет об ошибке: "UnhandledExceptionEventHandler не вызывается, когда управляемый код вызывается из неуправляемого и генерирует исключение - http://tinyurl.com/44j6gvu", где Microsoft подтверждает это "багги":

Спасибо, что нашли время сообщить об этой проблеме. Поведение действительно является ошибкой, вызванной механизмом выполнения CLR и CRT, конкурирующим за UnhandledExceptionFilter. Архитектура CLR была изменена в версии 4.0, поддерживающей этот сценарий.

Обновление (2011-06-06):

Почему так важно правильно?

• Если вы создаете хостинг-среду, ваши разработчики ожидают последовательного поведения в обработке исключений
• если есть способ вызвать "обычную обработку исключений CLR" в собственном потоке, это означает, что вам всегда нужно передать исполнение в управляемый поток (например, в пуле потоков)
• все еще есть небольшая часть кода, передающая исключение из native в управляемый поток..., который должен улавливать все исключения и каким-то образом обрабатывать эту ситуацию по-другому.

Примечание. изменение поведения CLR с помощью SetActionOnFailure() приводит к ухудшению ситуации, в результате чего он маскирует исходное исключение (т.е. вместо нехватки памяти вы получаете вид threadAborts - без ключ, где оригинальная ошибка cam от)!