9

我刚刚花了最后一个小时来解决 C# 中非托管内存的一个奇怪问题。

首先，一点上下文。我有一个 C# DLL，它导出一些本机方法（通过这个很棒的项目模板），然后由 Delphi 应用程序调用。这些 C# 方法之一必须将结构传回给 Delphi，然后将其转换为记录。我已经可以告诉你感到恶心，所以我不会详细说明。是的，它很丑陋，但另一种选择是 COM ......不，谢谢。

这是有问题的代码的简化：

IntPtr AllocBlock(int bufferSize)
{
    IntPtr ptrToMem = Marshal.AllocHGlobal(bufferSize);

    // zero memory
    for(int i = 0; i < bufferSize; i++)
       Marshal.WriteInt16(ptrToMem, i, 0);

    return ptrToMem;
}

实际上，这里还有一些其他的东西，与本地资源跟踪有关，但基本上就是这样。如果您已经发现了这个错误，那就太好了。

本质上，问题在于我使用WriteInt16了而不是WriteByte，由于 IntelliSense 辅助的错字，导致最终迭代在缓冲区末尾写入一个字节。很容易犯错，我猜。

然而，让调试变得如此痛苦的原因是它在调试器中默默地失败了，而应用程序的其余部分继续工作。内存已经分配，​​除了最后一个字节之外的所有字节都被归零，所以它工作正常。当在调试器之外启动时，它会导致应用程序因访问冲突而崩溃。一个典型的 Heisenbug 情况 - 当您尝试分析它时，该错误消失了。请注意，此崩溃不是托管异常，而是真正的 CPU 级访问冲突。

现在，这让我感到困惑有两个原因：

  1. 附加任何调试器时不会引发异常 - 我尝试了 Visual Studio、CodeGear Delphi 2009 和 OllyDbg。附加后，该程序运行良好。未附加时，程序崩溃。我对所有尝试都使用了完全相同的可执行文件。我的理解是调试不应该改变应用程序的行为，但它显然做到了。

  2. 通常我希望这个操作会AccessViolationException在我的托管代码中导致一个错误，但它会在ntdll.dll.

现在，很公平，我的案例可能是 C# 历史上最晦涩（并且可能被误导）的极端案例之一，但我不知道附加任何调试器如何防止崩溃。我对它在 OllyDbg 下工作感到特别惊讶，它不会像 Visual Studio 那样干扰该过程。

那么，这里到底发生了什么？为什么在调试期间异常被吞没（或没有引发），但在调试器之外却没有？当我尝试Marshal.WriteInt16在分配的内存块之外调用时，为什么没有抛出托管访问冲突异常，正如文档所说的那样？

4

1 回答 1

2

您只需将一些堆内存设置为零。这不会失败，因为没有检查您从何处获得此地址。这会在以后的堆管理（在 ntdll 中）中产生问题。此页面显示了为什么稍后才检测到溢出。

由于类似的原因，您没有使用附加的调试器失败。当 Windows 检测到附加了调试器时，将使用不同的堆管理器。调试堆管理器添加了一个用于检测溢出的后缀，它不会禁用堆管理器，但会在释放块时显示损坏。有关更多详细信息，请参见上面的页面。

我不知道堆管理器是如何切换到操作系统级别的，但我在 stackoverflow 上找到了相关答案： Visual C++: Difference between Start with/without debugging in Release mode

据我了解堆管理器切换，如果您从桌面/控制台以发布模式启动进程并稍后附加调试器，则调试器应在使用标准堆管理器时停止堆损坏。这可以用来检验我的假设。

于 2012-10-03T17:18:19.430 回答