作为经常折腾Excel自定义函数的老鸟，我太懂你这种32位正常、64位踩坑的痛苦了😅。大概率是数据类型不匹配或者函数导出/调用约定的问题，毕竟32位和64位的内存模型差异很大，下面给你梳理几个必查的点：

1. 先检查参数和返回值的类型是否适配64位 #

Excel的64位API用的是XLOPER12/XLOPER64类型，而32位用的是XLOPER。如果你的64位代码里还在沿用32位的类型，肯定会出问题。

举个正确的64位函数签名例子：

#include <xlcall.h>

// 必须加extern "C"防止C++名称修饰，__stdcall是Excel要求的调用约定
extern "C" __declspec(dllexport) XLOPER12 __stdcall AddTwoNumbers(XLOPER12* x1, XLOPER12* x2)
{
    XLOPER12 result;
    // 用xlCoerce12把单元格引用转换成数值类型
    double val1 = xlCoerce12(x1, xltypeNum);
    double val2 = xlCoerce12(x2, xltypeNum);
    
    result.xltype = xltypeNum;
    result.val.num = val1 + val2;
    return result;
}

注意所有和Excel交互的类型、API都要换成带12后缀的版本（比如xlCoerce→xlCoerce12），这是64位环境的硬性要求。

2. 核对.def文件的导出设置 #

64位DLL的导出函数名不会有32位那种_AddTwoNumbers@8的装饰后缀，一定要确保你的.def文件里的函数名和实际代码里的完全一致。

比如你的.def文件应该写成这样：

LIBRARY "AddNumbers64"
EXPORTS
    AddTwoNumbers @1  // @1是导出序号，可自行调整

编译完可以用dumpbin /exports Your64Dll.dll命令（在VS的命令提示符里运行）查看导出表，确认函数名正确导出，64位下应该是干净的函数名，没有额外后缀。

3. 确认Excel加载的是正确的DLL并正确注册 #

别犯低级错误——在64位Excel里加载的必须是你编译的64位DLL，不能不小心选了32位的版本。

注册函数的时候，参数类型标识要对应好，比如你是两个单元格引用，注册命令可以写成：

=REGISTER("C:\你的路径\AddNumbers64.dll", "AddTwoNumbers", "RR", "Add Two Numbers", "2", "第一个数", "第二个数")

这里的RR表示两个Range类型的参数，如果是直接传数值就用BB，类型标识错了也会返回#VALUE!。

4. 排查内存相关的低级错误 #

64位下指针是8字节，32位是4字节，如果你的代码里有硬编码的指针长度（比如用int代替size_t），或者手动处理内存时计算错误，会直接触发内存越界，Excel为了保护自己就会返回#VALUE!。比如别写int ptrLen = 4;，要写成size_t ptrLen = sizeof(void*);。

5. 用调试工具抓问题 #

最直接的方法是在Visual Studio里附加到64位Excel进程，然后在你的函数里加断点，看看函数有没有被调用：

• 如果根本没进断点：说明导出或注册有问题，回到前两步检查。
• 如果进了断点但执行到某一步崩溃：那就是代码逻辑里的类型或内存问题，一步步排查变量值是否正确。

快速修复的小步骤 #

1. 把32位代码里所有的XLOPER替换成XLOPER12，所有Excel API都换成带12后缀的版本。
2. 检查.def文件的导出函数名，确保和代码里的一致。
3. 用dumpbin确认64位DLL的导出表正确。
4. 在64位Excel里重新注册DLL，测试函数。

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