dotnet.exe已退出 - 访问冲突

Question

将.NET Core从2.0升级到2.1后，在运行测试时遇到以下错误：

程序'[12372] dotnet.exe'已退出，代码为-1073741819（0xc0000005）“访问冲突”。

在调试模式下，VS会退出调试模式，并在输出->调试窗口中打印上述消息。

当步进httpClient.SendAsync(...)时出现此错误。

我认为可能是相同的问题。

通过dotnet test运行测试显示：

活动测试运行被中止。原因：由于StackOverflowException进程正在终止。

更新

该问题是由不良IoC映射引起的。

- Răzvan Flavius Panda

---

@jdweng 我已经重新构建了整个解决方案。此外，这可以在另一台计算机上重现。 - Răzvan Flavius Panda

@jdweng 不管我使用多少个try catch，VS都不会在这种类型的异常上中断，只会在输出窗口中记录它。 - Răzvan Flavius Panda

你仍然可以使用Catch来添加断点进行调试。如果您有循环，将断点添加到循环中会使定位问题更加困难，而将断点放在Catch中则更为方便。 - jdweng

@jdweng 这样做不起作用，因为dotnet.exe在异步函数内部死亡，而没有抛出任何可捕获的异常。 - Răzvan Flavius Panda

代码中是否已经有try/catch？是否有Using语句？Using语句通常不会报告异常。我通常用try/catch替换Using。您可以在异步操作中设置断点。如果您到达断点，则问题出现在断点之后。然后继续添加断点，直到找到不会中断的位置。根据我的经验，当您没有try/catch时，代码会向上执行堆栈，直到在方法中找到任何地方的try/catch。因此，有时它会给出错误的失败点。 - jdweng

Answer 1

在我的案例中，存在隐藏的无限递归。我重载了==运算符，然后在这个重载函数中使用了==运算符，却没有注意到其中的反讽！正如@jdweng所建议的那样，使用断点来深入分析问题区域。它可能会被很好地隐藏起来！

- Chad Hedgcock

---

我也遇到过这种情况。我写了一个扩展方法来包含布尔逻辑，以避免重复的代码，然后不小心对该逻辑进行了全局更改，导致扩展方法（也）调用了自身。糟糕！ - Will

这拯救了我的理智。谢谢。 - Frank Fajardo

这很棒，但是任何低级别的访问冲突都不应该出现。想知道.NET Core框架在新版本中是否解决了这个问题，并且能否在堆栈溢出发生的地方抛出有用的异常。 - Vinz

Answer 2

我也遇到了同样的错误，但在我的情况下，这是由于属性的set语句中存在拼写错误引起的。有问题的代码：

private bool _isCompressed;
public bool isCompressed {
    get { return _isCompressed; }
    set { isCompressed = value; } //Should be _isCompressed
}

- nos.17

---

您的回答可以通过添加更多支持信息来改善。请[编辑]以添加更多细节，例如引用或文档，以便他人确认您的答案是否正确。您可以在帮助中心找到有关如何编写良好答案的更多信息。 - Community

Answer 3

我遇到了同样的问题，因为我没有正确地使用后备字段和属性，例如：

public int Number {
    get => Number;
    set
    {
        Number = value;
        // infinite loop here
    }
}

不要这样做：

private int _number
public int Number {
        get => _number;
        set
        {
            _number = value;
        }
    }

- Gabriel

Answer 4

另一个可能的原因是循环类实例化： 类A创建了类B的一个实例。 而类B又创建了类A的一个实例。

.Net Core在编译时没有检测到这个问题的机制。

- Jpsy

---

现在它在运行时可以检测到循环依赖，并且会明确报错，指出存在依赖注入的循环引用。你不会收到访问违规错误。 - iCollect.it Ltd