IMethodCallMessage Args.Get() - FatalExecutionEngineError 或 AccessViolationException答案

【问题标题】：IMethodCallMessage Args.Get() - FatalExecutionEngineError or AccessViolationExceptionIMethodCallMessage Args.Get() - FatalExecutionEngineError 或 AccessViolationException
【发布时间】：2011-11-30 20:58:44
【问题描述】：

这行代码导致如下所示的异常：

object arg = methodCallMessage.Args[i];

private static List<ParameterInformation> GetParameterInfoList( IMethodCallMessage methodCallMessage )
{
    List<ParameterInformation> parameterInformationList = new List<ParameterInformation>();

    // Note: This works even if a parameter's value is null.
    for( int i = 0 ; i < methodCallMessage.ArgCount ; i++ )
    {
        string argName           = methodCallMessage.GetArgName(i);
        object arg               = methodCallMessage.Args[i];
        var parameterInformation = new ParameterInformation(argName, arg);

        parameterInformationList.Add(parameterInformation);
    }

    return parameterInformationList;
}

例外： FatalExecutionEngineError：运行时遇到致命错误。错误地址位于线程 0x2ef4 上的 0x71b97e8d。错误代码为 0xc0000005。此错误可能是 CLR 或用户代码的不安全或不可验证部分中的错误。此错误的常见来源包括 COM-interop 或 PInvoke 的用户封送错误，这可能会损坏堆栈。

或者有时这个例外：

AccessViolationException：试图读取或写入受保护的内存。这通常表明其他内存已损坏。

这发生在不止一台机器上。

在调用堆栈中，当我显示外部代码时，它位于顶部： mscorlib.dll!System.Runtime.Remoting.Messaging.Message.Args.get() + 0x5 字节。

任何想法为什么会发生这种情况，或者如何解决它？

注意：调用此方法的代码周围有一个锁，所以它不应该是线程/时序问题。

【问题讨论】：

垃圾收集堆被非托管代码损坏的典型情况。该损坏是较早完成的，它不会在导致损坏的代码处崩溃。难以调试，需要通过大量的单元测试来解决。

标签： c# reflection remoting

【解决方案1】：

这更像是一种变通方法而不是实际修复，但它适用于这种情况。该问题仅在以异步方式完成时发生。启动该过程的代码将其包裹起来：

Task.Factory.StartNew(() =>

当我删除它并同步处理事情时，问题就消失了。

【讨论】：