为什么 .NET 程序能够在损坏的堆栈中幸存下来？ （当使用错误的调用约定时）

Question

在 VS2010 中，托管调试助手会给您一个 pInvokeStackImbalance 异常 (pInvokeStackImbalance MDA）如果您使用错误的调用约定调用函数，通常是因为您没有指定 CallingConvention =调用 C 库时使用 Cdecl。例如，您编写了

[DllImport("some_c_lib.dll")]
static extern void my_c_function(int arg1, int arg2);

而不是

[DllImport("some_c_lib.dll", CallingConvention=CallingConvention.Cdecl)]
static extern void my_c_function(int arg1, int arg2);

，因此得到了 StdCall 调用约定而不是 Cdelc。

如果您回答这个问题，您已经知道其中的区别，但对于该线程的其他访问者来说：StdCall 意味着被调用者从堆栈中清除参数，而 Cdecl 意味着调用者清除堆栈。

因此，如果您的 C 代码中的调用约定错误，您的堆栈不会被清理，并且您的程序会崩溃。

但是，.NET 程序即使使用 StdCall 来执行 Cdecl 函数，似乎也不会崩溃。 VS2008 上默认未启用堆栈不平衡检查，因此某些 VS2008 项目在不知不觉中使用了错误的调用约定给他们的作者。我刚刚尝试了 GnuMpDotNet ，即使缺少 Cdelc 声明，示例也运行得很好。 X-MPIR 也是如此。

它们都在调试模式下抛出 pInvokeStackImbalance MDA 异常，但在发布模式下不会崩溃。这是为什么呢？ .NET VM 是否包装对本机代码的所有调用并随后恢复堆栈本身？如果是这样，为什么还要费心 CallingConvention 属性呢？

Answer 1

这是因为方法退出时堆栈指针的恢复方式。方法的标准序言，针对 x86 抖动显示；

00000000  push        ebp                 ; save old base pointer
00000001  mov         ebp,esp             ; setup base pointer to point to activation frame
00000003  sub         esp,34h             ; reserve space for local variables

其结束方式：

0000014a  mov         esp,ebp             ; restore stack pointer
0000014c  pop         ebp                 ; restore base pointer
0000014d  ret 

使 esp 值不平衡在这里不是问题，它会从 ebp 寄存器值恢复。然而，当抖动优化器可以将局部变量存储在 CPU 寄存器中时，它经常会优化这一点。当 RET 指令从堆栈中检索到错误的返回地址时，您将崩溃并烧毁。无论如何，希望当它偶然落在一大块机器代码上时真的很糟糕。

当您在没有调试器的情况下运行发布版本时，很可能会发生这种情况，如果没有 MDA 来帮助您，则很难排除故障。

Answer 2

运行时可以检测堆栈不平衡，因为堆栈指针不在预期的位置。也就是说，在 StdCall 的情况下，被调用的函数预计会清理堆栈，那么运行时可以执行以下操作：

SavedSP = SP; // save the stack pointer
// now push parameters
// call the external function.
if (SP != SavedSP)
{
    // error!
}

现在，如果 SP 的值为小于SavedSP，那么堆栈上有额外的东西——这意味着运行时可以继续并恢复保存的堆栈指针。

运行时应该始终能够检测到堆栈不平衡。我不知道它是否总能恢复。但是，如果无意中将 Cdecl 方法作为 StdCall 调用，它应该能够毫无问题地恢复，因为堆栈上会有额外的内容可以忽略。

至于为什么要麻烦呢？正如您所说，StdCall 和 Cdecl 之间的区别实际上只是谁负责堆栈清理。另外，StdCall 与变量参数列表（即 C 中的 printf）不兼容，尽管我不知道是否可以从 .NET 调用这样的方法（从来没有需要）。无论如何，尽管使用 StdCall 调用 Cdecl 方法似乎没有什么特殊问题，但我有点想知道存在潜在的错误。对我来说，这就像你编写时编译器给出的错误消息：

uint x = 3;
int y = x;  // error!

我知道赋值是可以的，但编译器不允许它，因为它是错误的潜在来源。在我看来，不平衡的堆栈是错误的潜在来源。不，它是一个错误，可能会导致一些非常糟糕的事情发生。我宁愿运行时告诉我这一点，以便我可以解决问题。