通过DLL代理重定向名称修饰函数 调试老游戏运行逻辑问题咨询

问题成因 #

你遇到的导出失败核心原因是新旧版本MSVC的C++名称修饰规则不兼容：1998年对应的是MSVC 6.0（VC6）版本，和你现在用的VS2019（CL 19.x）的名称修饰逻辑存在差异，尤其是针对特殊参数、调用约定的编码规则VC6和后续版本有改动，所以你本地编译的LogInfo函数的修饰名和你想要导出的?LogDebug@@YAXPBDZZ完全不匹配，链接器找不到对应的目标函数，自然不会生成预期的导出项。

可行解决方案 #

方案1：直接指定导出别名（成本最低，无需调整编译配置） #

你不需要让本地编译器生成匹配的旧版修饰名，直接在导出指令里强制关联符号即可，操作步骤如下：

1. 给你本地实现的LogInfo函数加上__declspec(dllexport)声明
2. 编译一次项目，用dumpbin /exports [你的DLL路径]命令查看LogInfo的实际修饰名，假设为?LogInfo@@YAXPBD@Z
3. 修改你的pragma指令为如下格式：

#pragma comment(linker, "/export:?LogDebug@@YAXPBDZZ=?LogInfo@@YAXPBD@Z,@504")

链接器会直接把对外暴露的导出名设置为你需要的老版本修饰名，指向你本地的函数实现，完全不需要兼容旧版修饰规则。

方案2：用DEF文件导出（比#pragma指令更可控） #

如果后续需要处理大量导出函数，更推荐用DEF文件管理导出规则，新建一个后缀为.def的文件加入项目，内容格式如下：

EXPORTS
?LogDebug@@YAXPBDZZ=?LogInfo@@YAXPBD@Z @504
; 其他需要代理到原DLL的函数直接按这个格式写：?[原修饰名]=trueDLL.?[原修饰名] @[导出序号]

这种方式比写大量#pragma指令更清晰，不易出错。

方案3：适配VC6编译环境（仅适用于需重写大量函数的场景） #

如果需要完全匹配老版本的修饰规则，可以安装VC6编译器，在VS2019里切换工具集为VC6编译，编译出来的函数修饰名就会和原DLL完全一致，但配置成本较高，普通场景不推荐。

验证原DLL修饰规则的方法 #

不需要依赖第三方反汇编工具的识别结果，直接用微软官方自带的undname工具即可验证：

1. 打开VS2019的开发者命令提示符
2. 执行命令undname ?LogDebug@@YAXPBDZZ
3. 如果能正常解析出函数原型（比如该符号会被解析为void __cdecl LogDebug(char const *, ...)），就说明确实是MSVC的C++修饰规则，解析失败才是其他编译器的规则。
   第三方在线demangler工具大多仅适配新的编译器规则，对VC6的特殊修饰规则支持不全，才会出现解析失败的情况。

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