VS2013中SEH与x64调用约定下rbp被修改的原因问询

首先明确一个核心规则：在x64调用约定里，RBP是非易失寄存器——也就是说，被调用函数（比如你的bar）必须保证返回时RBP的值和进入函数时完全一致。哪怕函数自己修改了RBP（比如建立栈帧），也得在返回前把它恢复原样。

那回到你的场景，问题出在SEH的异常展开（Unwind）流程上，我们一步步拆解：

1. 异常展开的隐形操作 #

当__try块里触发异常时，系统会执行unwind流程来清理栈上的局部对象、恢复寄存器，最终跳转到__except块。这个过程完全依赖编译器生成的unwind信息来决定怎么恢复寄存器。

你发现的那个诡异现象——s += "-----\n"这行根本不会执行的代码却影响了RBP，本质是它改变了编译器生成的栈帧布局和unwind信息：

• 当保留这行代码时，编译器为std::string s生成的栈帧逻辑更复杂，连带unwind信息里错误地包含了修改RBP的操作，而且没有正确恢复它。
• 移除这行后，栈帧结构简单，unwind信息正确，RBP就不会被篡改。

2. 为什么bar会“违反”调用约定？ #

bar本身并没有主动修改RBP，但SEH的unwind流程绕过了它正常的栈帧恢复逻辑：

• 在foo调用bar时，foo的RBP指向自己的栈帧；如果bar没有显式建立自己的栈帧（编译器优化掉了），RBP会一直指向foo的栈帧。
• 异常发生后，unwind流程因为错误的unwind信息，把RBP改成了异常触发时的栈帧指针，却没把它恢复到bar刚被调用时的原值。
• 等bar从__except块返回时，RBP已经被改了，回到foo里访问[rbp+0x10]自然就访问到错误的内存，直接崩溃。

3. VS2013的编译器bug嫌疑 #

这个问题大概率是VS2013编译器的bug——它在处理SEH unwind和局部对象（比如std::string）的结合时，对未执行代码路径的栈帧分析有问题，导致生成的unwind信息不正确，最终破坏了RBP的非易失性保证。

修复建议 #

• 显式保留RBP：在bar函数开头手动添加栈帧建立代码，强制保护RBP：

  int bar() {
      int st = XXX_OK;
      push rbp;  // 保存调用者的RBP
      mov rbp, rsp;  // 建立自己的栈帧
      __try {
          ... // 触发异常的代码
      } __except (filter())
      {
          st = XXX_EXCEPTION;
      }
      pop rbp;  // 恢复调用者的RBP
      return st;
  }
  

• 升级编译器：换到VS2019或更高版本，这类老版本的SEH相关bug基本都被修复了。
• 简化栈帧逻辑：尽量避免在可能触发异常的函数里有复杂的局部对象，或者调整代码结构，减少编译器生成异常unwind信息的复杂度。

内容的提问来源于stack exchange，提问作者TanakaYasen