1. 一个返回值0引发的深夜排查如果你在Windows平台做过动态库加载相关的开发大概率见过GetProcAddress返回NULL的场景。常规思路无非是函数名拼错了、DLL没加载成功、导出符号被修饰了这几种。但有一种情况特别折磨人DLL明明加载成功了函数名也确认无误GetProcAddress就是返回0调用GetLastError()拿到127——找不到指定的程序。这个127错误码本身不稀奇稀奇的是它出现的条件。我最近就碰到了一个案例一个导出函数在DLL里定义得好好的用dumpbin看导出表也能看到符号但通过GetProcAddress去取地址就是拿不到。排查了大半天最后发现根因出在调用约定上——具体来说是CALLBACK这个宏在作祟。这篇文章会把整个排查链路完整还原出来包括我一开始走的弯路、中间用到的工具、最终定位到问题的那一瞬间以及后续怎么修复和验证。如果你也在做Windows下的DLL动态加载尤其是涉及回调函数导出的场景这篇内容应该能帮你省下不少时间。2. 先搞清楚GetProcAddress和127错误码到底在说什么2.1 GetProcAddress的工作机制GetProcAddress是Windows API中用来从已加载的DLL模块中获取导出函数地址的函数。它的签名长这样FARPROC GetProcAddress( HMODULE hModule, LPCSTR lpProcName );hModule是LoadLibrary或GetModuleHandle返回的模块句柄lpProcName是你想找的函数名或者用MAKEINTRESOURCE传入序号。函数返回一个函数指针失败时返回NULL。关键点在于GetProcAddress查找的是DLL导出表Export Table中的符号名。这个查找过程是精确匹配的——你传进去的字符串必须和导出表里的名字完全一致包括大小写实际上Windows的导出表查找是大小写敏感的。2.2 错误码127的含义当GetProcAddress返回NULL时调用GetLastError()通常会得到以下几种错误码错误码含义常见原因127ERROR_PROC_NOT_FOUND找不到指定的程序126ERROR_MOD_NOT_FOUND找不到指定的模块998ERROR_NOACCESS无效的访问权限127就是找不到指定的程序字面意思很直白系统在DLL的导出表里没有找到你指定的那个函数名。但问题在于很多时候你明明能看到那个函数就在导出表里。2.3 为什么明明有却找不到这是整个问题的核心矛盾。导出表里能看到符号但GetProcAddress说找不到。造成这种矛盾的原因通常有这几类名字修饰Name ManglingC编译器会对函数名进行修饰导出表里的名字可能是一串乱码般的修饰名而不是你写的原始函数名。调用约定影响修饰方式__stdcall、__cdecl、__fastcall等不同的调用约定会导致导出名的修饰规则不同。导出方式差异用__declspec(dllexport)导出和用.def文件导出最终生成的导出名可能不一样。序号导出有些DLL只按序号导出不按名字导出。我这次碰到的情况就是调用约定通过CALLBACK宏间接影响了导出名导致GetProcAddress用原始名字去查的时候匹配不上。3. CALLBACK宏是怎么把导出名搞乱的3.1 CALLBACK的本质定义在Windows SDK的头文件中CALLBACK宏的定义是这样的#define CALLBACK __stdcall也就是说CALLBACK就是__stdcall的一个别名。这个宏在Windows API中大量使用因为Windows的系统API默认就是__stdcall调用约定。那为什么会有这个宏历史原因。早期Windows开发中不同的编译器和平台对调用约定的写法不统一微软用CALLBACK、WINAPI、APIENTRY等宏来统一表示这是Windows标准调用约定。在32位环境下它们都展开为__stdcall在64位环境下Windows统一使用__fastcall约定实际上x64只有一种调用约定这些宏就都变成空定义了。3.2 __stdcall对导出名的修饰规则这是问题的关键所在。在32位编译环境下__stdcall调用约定会对导出函数名进行修饰规则是_函数名参数字节数举个例子如果你这样声明__declspec(dllexport) int __stdcall MyFunction(int a, int b);导出表里的名字会变成_MyFunction8因为两个int参数每个4字节总共8字节所以后缀是8。而如果你用的是__cdecl__declspec(dllexport) int __cdecl MyFunction(int a, int b);导出名就是_MyFunction只加一个下划线前缀没有参数大小后缀。3.3 为什么用了CALLBACK就出问题现在回到我的场景。DLL端的代码大概是这样写的// DLL端 __declspec(dllexport) int CALLBACK ProcessData(int nCount, char* pBuffer) { // 处理逻辑 return 0; }因为CALLBACK展开为__stdcall所以导出表里的实际名字变成了_ProcessData8而调用端的代码是这样写的// 调用端 typedef int (CALLBACK *PFN_PROCESSDATA)(int, char*); HMODULE hDll LoadLibrary(mydll.dll); PFN_PROCESSDATA pfn (PFN_PROCESSDATA)GetProcAddress(hDll, ProcessData); if (pfn NULL) { DWORD err GetLastError(); // 得到127 }调用端用ProcessData这个原始名字去查但导出表里存的是_ProcessData8自然匹配不上返回NULL错误码127。这里有个容易混淆的点调用端的函数指针类型声明里也用了CALLBACK这影响的是调用时的栈管理方式但不影响GetProcAddress的查找过程。GetProcAddress只认字符串它不管你调用端声明了什么类型。4. 完整还原我的排查过程4.1 第一步确认DLL是否加载成功遇到GetProcAddress返回NULL第一件事是确认LoadLibrary是否成功。这个案例中LoadLibrary返回了有效句柄说明DLL文件本身没问题依赖项也都满足。HMODULE hDll LoadLibrary(mydll.dll); if (hDll NULL) { // 这里没进来说明加载成功了 }4.2 第二步用dumpbin查看导出表接下来我用dumpbin /exports mydll.dll查看了导出表。输出大概是这样ordinal hint RVA name 1 0 00011234 _ProcessData8看到这个输出的时候其实答案已经摆在眼前了——导出名是_ProcessData8不是ProcessData。但当时我的第一反应是哦有修饰名那我用修饰名去查就行了于是改成了PFN_PROCESSDATA pfn (PFN_PROCESSDATA)GetProcAddress(hDll, _ProcessData8);这样确实能查到。但问题是这种写法太脆弱了——换个编译器版本、换个参数数量修饰名就变了。而且如果DLL是第三方提供的你没法保证它的导出名规则。4.3 第三步确认调用约定的一致性真正让我意识到问题本质的是对比了DLL端和调用端的声明。DLL端用了CALLBACK即__stdcall而调用端在GetProcAddress时用的是未修饰的原始名。这两者之间的不匹配才是根因。我又检查了项目里其他几个导出函数发现有的用了CALLBACK有的没用。没用的那些函数导出名就是简单的_FunctionName形式__cdecl用原始名去掉下划线就能查到。而用了CALLBACK的导出名带了参数字节数后缀用原始名查不到。4.4 第四步验证假设为了确认这个判断我写了一个最小测试// 测试DLL __declspec(dllexport) int __stdcall FuncStdcall(int a) { return a; } __declspec(dllexport) int __cdecl FuncCdecl(int a) { return a; }编译后用dumpbin查看name _FuncCdecl _FuncStdcall4果然__stdcall的函数带了4后缀一个int参数4字节__cdecl的只有下划线前缀。然后分别用原始名去GetProcAddress// 这个能成功 GetProcAddress(hDll, _FuncCdecl); // 这个失败错误码127 GetProcAddress(hDll, FuncCdecl); // 这个能成功 GetProcAddress(hDll, _FuncStdcall4); // 这个失败错误码127 GetProcAddress(hDll, FuncStdcall);到这里问题完全确认了。5. 三种修复方案及各自的适用场景5.1 方案一用.def文件强制指定导出名这是最干净的做法。在DLL工程里添加一个.def文件EXPORTS ProcessData_ProcessData8或者更直接地EXPORTS ProcessData配合.def文件使用时需要在函数声明处去掉__declspec(dllexport)或者保留但确保.def文件里的名字是最终导出名。.def文件的优势是导出名完全由你控制不受编译器修饰规则影响。缺点是需要额外维护一个文件函数增删时要同步更新。5.2 方案二用extern C配合__cdecl如果不需要__stdcall的栈清理特性可以把导出函数改成__cdeclextern C __declspec(dllexport) int __cdecl ProcessData(int nCount, char* pBuffer);extern C阻止C的名字修饰__cdecl只加下划线前缀。这样导出名就是_ProcessData用ProcessData或_ProcessData都能查到取决于编译器设置。但要注意如果这个函数需要作为回调传给Windows API那调用约定必须是__stdcall不能改成__cdecl。5.3 方案三调用端适配修饰名如果DLL是第三方提供的你没法改DLL的编译方式那就只能在调用端适配。有两种做法第一种是硬编码修饰名PFN_PROCESSDATA pfn (PFN_PROCESSDATA)GetProcAddress(hDll, _ProcessData8);第二种是动态构造修饰名char szName[64]; sprintf(szName, _ProcessData%d, sizeof(int) sizeof(char*)); PFN_PROCESSDATA pfn (PFN_PROCESSDATA)GetProcAddress(hDll, szName);第二种做法稍微灵活一点但本质上还是依赖修饰规则换个编译器可能就不适用了。5.4 三种方案的对比方案适用场景优点缺点.def文件自己编译DLL导出名完全可控需额外维护文件extern C __cdecl不需要__stdcall特性简单直接不能用于回调场景调用端适配第三方DLL不改DLL脆弱依赖编译器规则6. 几个容易混淆的相关问题6.1 64位下CALLBACK还有影响吗在64位编译环境下Windows只有一种调用约定通常称为__fastcall但实际上是统一的寄存器传参规则__stdcall、__cdecl、CALLBACK这些宏都变成了空定义。所以64位下不会出现参数字节数的修饰后缀导出名就是原始名C的话仍然有名字修饰但那是另一回事。这意味着同一个DLL工程编译成32位和64位导出名可能不一样。如果你的代码需要同时支持两种架构这一点必须注意。6.2 GetProcAddress的大小写敏感性GetProcAddress的字符串匹配是大小写敏感的。ProcessData和processdata会被视为不同的名字。这一点在排查时容易被忽略——有时候你以为是调用约定的问题实际上只是大小写写错了。6.3 用序号导出时的注意事项如果DLL是用序号导出的.def文件中用序号指定那GetProcAddress需要这样调用GetProcAddress(hDll, MAKEINTRESOURCE(1));用序号导出的好处是不受名字修饰影响坏处是可读性差而且序号可能随版本变化。7. 我踩过的几个坑和实操建议第一个坑是过度依赖GetLastError。GetProcAddress失败后GetLastError返回127确实说明找不到程序但这个找不到可能是名字不匹配、可能是大小写问题、可能是修饰名问题。不要看到127就只往一个方向想。第二个坑是忽略了32位和64位的差异。我一开始在64位环境下测试怎么都复现不了问题后来切换到32位才看到修饰名。如果你在排查类似问题先确认目标平台是32位还是64位。第三个坑是调用端和DLL端的声明不一致。调用端声明函数指针时用了CALLBACKDLL端也用了CALLBACK看起来是一致的但GetProcAddress的查找过程根本不看你的函数指针类型声明。它只看字符串。所以声明一致不代表查找能成功。实操建议方面我现在的习惯是DLL工程一律用.def文件管理导出名不管用不用CALLBACK。这样导出名永远是干净的原始名调用端不用关心修饰规则。另外在调用GetProcAddress之前先用dumpbin /exports确认一下实际的导出名比盲目猜测高效得多。还有一个技巧如果DLL是你自己编译的可以在工程设置里把导出符号选项打开让编译器生成一个.exp文件里面会列出所有导出符号的最终名字。这个文件在排查导出问题时非常有用。8. 从这个问题延伸出去的思考GetProcAddress返回127这个问题表面上看是一个API使用问题实际上反映的是Windows平台下DLL导出机制的复杂性。调用约定、名字修饰、导出方式、编译架构这几个因素交织在一起任何一个不一致都可能导致查找失败。我在实际项目中还遇到过另一种情况DLL用__declspec(dllexport)导出了函数但同时在.def文件里也声明了导出结果导出表里出现了两个名字——一个是修饰名一个是.def里指定的名字。这种情况下用.def里的名字能查到用修饰名也能查到但用原始名不带下划线查不到。这种双导出的情况更隐蔽因为dumpbin的输出里会看到两行容易让人困惑。解决这类问题的根本思路是明确导出名的最终形态然后让调用端用完全一致的名字去查。不要假设我写了什么名字导出表里就是什么名字。在Windows平台上这个假设在32位环境下几乎总是错的。如果你正在设计一个需要跨模块调用的DLL接口我的建议是要么用.def文件锁定导出名要么用extern C加__cdecl要么在调用端做名字适配。三条路选一条走到底不要混着用。混着用的时候问题往往不会立刻暴露而是在某个特定编译配置下突然出现那时候排查成本就高了。
1. 一个返回值0引发的深夜排查如果你在Windows平台做过动态库加载相关的开发大概率见过GetProcAddress返回NULL的场景。常规思路无非是函数名拼错了、DLL没加载成功、导出符号被修饰了这几种。但有一种情况特别折磨人DLL明明加载成功了函数名也确认无误GetProcAddress就是返回0调用GetLastError()拿到127——找不到指定的程序。这个127错误码本身不稀奇稀奇的是它出现的条件。我最近就碰到了一个案例一个导出函数在DLL里定义得好好的用dumpbin看导出表也能看到符号但通过GetProcAddress去取地址就是拿不到。排查了大半天最后发现根因出在调用约定上——具体来说是CALLBACK这个宏在作祟。这篇文章会把整个排查链路完整还原出来包括我一开始走的弯路、中间用到的工具、最终定位到问题的那一瞬间以及后续怎么修复和验证。如果你也在做Windows下的DLL动态加载尤其是涉及回调函数导出的场景这篇内容应该能帮你省下不少时间。2. 先搞清楚GetProcAddress和127错误码到底在说什么2.1 GetProcAddress的工作机制GetProcAddress是Windows API中用来从已加载的DLL模块中获取导出函数地址的函数。它的签名长这样FARPROC GetProcAddress( HMODULE hModule, LPCSTR lpProcName );hModule是LoadLibrary或GetModuleHandle返回的模块句柄lpProcName是你想找的函数名或者用MAKEINTRESOURCE传入序号。函数返回一个函数指针失败时返回NULL。关键点在于GetProcAddress查找的是DLL导出表Export Table中的符号名。这个查找过程是精确匹配的——你传进去的字符串必须和导出表里的名字完全一致包括大小写实际上Windows的导出表查找是大小写敏感的。2.2 错误码127的含义当GetProcAddress返回NULL时调用GetLastError()通常会得到以下几种错误码错误码含义常见原因127ERROR_PROC_NOT_FOUND找不到指定的程序126ERROR_MOD_NOT_FOUND找不到指定的模块998ERROR_NOACCESS无效的访问权限127就是找不到指定的程序字面意思很直白系统在DLL的导出表里没有找到你指定的那个函数名。但问题在于很多时候你明明能看到那个函数就在导出表里。2.3 为什么明明有却找不到这是整个问题的核心矛盾。导出表里能看到符号但GetProcAddress说找不到。造成这种矛盾的原因通常有这几类名字修饰Name ManglingC编译器会对函数名进行修饰导出表里的名字可能是一串乱码般的修饰名而不是你写的原始函数名。调用约定影响修饰方式__stdcall、__cdecl、__fastcall等不同的调用约定会导致导出名的修饰规则不同。导出方式差异用__declspec(dllexport)导出和用.def文件导出最终生成的导出名可能不一样。序号导出有些DLL只按序号导出不按名字导出。我这次碰到的情况就是调用约定通过CALLBACK宏间接影响了导出名导致GetProcAddress用原始名字去查的时候匹配不上。3. CALLBACK宏是怎么把导出名搞乱的3.1 CALLBACK的本质定义在Windows SDK的头文件中CALLBACK宏的定义是这样的#define CALLBACK __stdcall也就是说CALLBACK就是__stdcall的一个别名。这个宏在Windows API中大量使用因为Windows的系统API默认就是__stdcall调用约定。那为什么会有这个宏历史原因。早期Windows开发中不同的编译器和平台对调用约定的写法不统一微软用CALLBACK、WINAPI、APIENTRY等宏来统一表示这是Windows标准调用约定。在32位环境下它们都展开为__stdcall在64位环境下Windows统一使用__fastcall约定实际上x64只有一种调用约定这些宏就都变成空定义了。3.2 __stdcall对导出名的修饰规则这是问题的关键所在。在32位编译环境下__stdcall调用约定会对导出函数名进行修饰规则是_函数名参数字节数举个例子如果你这样声明__declspec(dllexport) int __stdcall MyFunction(int a, int b);导出表里的名字会变成_MyFunction8因为两个int参数每个4字节总共8字节所以后缀是8。而如果你用的是__cdecl__declspec(dllexport) int __cdecl MyFunction(int a, int b);导出名就是_MyFunction只加一个下划线前缀没有参数大小后缀。3.3 为什么用了CALLBACK就出问题现在回到我的场景。DLL端的代码大概是这样写的// DLL端 __declspec(dllexport) int CALLBACK ProcessData(int nCount, char* pBuffer) { // 处理逻辑 return 0; }因为CALLBACK展开为__stdcall所以导出表里的实际名字变成了_ProcessData8而调用端的代码是这样写的// 调用端 typedef int (CALLBACK *PFN_PROCESSDATA)(int, char*); HMODULE hDll LoadLibrary(mydll.dll); PFN_PROCESSDATA pfn (PFN_PROCESSDATA)GetProcAddress(hDll, ProcessData); if (pfn NULL) { DWORD err GetLastError(); // 得到127 }调用端用ProcessData这个原始名字去查但导出表里存的是_ProcessData8自然匹配不上返回NULL错误码127。这里有个容易混淆的点调用端的函数指针类型声明里也用了CALLBACK这影响的是调用时的栈管理方式但不影响GetProcAddress的查找过程。GetProcAddress只认字符串它不管你调用端声明了什么类型。4. 完整还原我的排查过程4.1 第一步确认DLL是否加载成功遇到GetProcAddress返回NULL第一件事是确认LoadLibrary是否成功。这个案例中LoadLibrary返回了有效句柄说明DLL文件本身没问题依赖项也都满足。HMODULE hDll LoadLibrary(mydll.dll); if (hDll NULL) { // 这里没进来说明加载成功了 }4.2 第二步用dumpbin查看导出表接下来我用dumpbin /exports mydll.dll查看了导出表。输出大概是这样ordinal hint RVA name 1 0 00011234 _ProcessData8看到这个输出的时候其实答案已经摆在眼前了——导出名是_ProcessData8不是ProcessData。但当时我的第一反应是哦有修饰名那我用修饰名去查就行了于是改成了PFN_PROCESSDATA pfn (PFN_PROCESSDATA)GetProcAddress(hDll, _ProcessData8);这样确实能查到。但问题是这种写法太脆弱了——换个编译器版本、换个参数数量修饰名就变了。而且如果DLL是第三方提供的你没法保证它的导出名规则。4.3 第三步确认调用约定的一致性真正让我意识到问题本质的是对比了DLL端和调用端的声明。DLL端用了CALLBACK即__stdcall而调用端在GetProcAddress时用的是未修饰的原始名。这两者之间的不匹配才是根因。我又检查了项目里其他几个导出函数发现有的用了CALLBACK有的没用。没用的那些函数导出名就是简单的_FunctionName形式__cdecl用原始名去掉下划线就能查到。而用了CALLBACK的导出名带了参数字节数后缀用原始名查不到。4.4 第四步验证假设为了确认这个判断我写了一个最小测试// 测试DLL __declspec(dllexport) int __stdcall FuncStdcall(int a) { return a; } __declspec(dllexport) int __cdecl FuncCdecl(int a) { return a; }编译后用dumpbin查看name _FuncCdecl _FuncStdcall4果然__stdcall的函数带了4后缀一个int参数4字节__cdecl的只有下划线前缀。然后分别用原始名去GetProcAddress// 这个能成功 GetProcAddress(hDll, _FuncCdecl); // 这个失败错误码127 GetProcAddress(hDll, FuncCdecl); // 这个能成功 GetProcAddress(hDll, _FuncStdcall4); // 这个失败错误码127 GetProcAddress(hDll, FuncStdcall);到这里问题完全确认了。5. 三种修复方案及各自的适用场景5.1 方案一用.def文件强制指定导出名这是最干净的做法。在DLL工程里添加一个.def文件EXPORTS ProcessData_ProcessData8或者更直接地EXPORTS ProcessData配合.def文件使用时需要在函数声明处去掉__declspec(dllexport)或者保留但确保.def文件里的名字是最终导出名。.def文件的优势是导出名完全由你控制不受编译器修饰规则影响。缺点是需要额外维护一个文件函数增删时要同步更新。5.2 方案二用extern C配合__cdecl如果不需要__stdcall的栈清理特性可以把导出函数改成__cdeclextern C __declspec(dllexport) int __cdecl ProcessData(int nCount, char* pBuffer);extern C阻止C的名字修饰__cdecl只加下划线前缀。这样导出名就是_ProcessData用ProcessData或_ProcessData都能查到取决于编译器设置。但要注意如果这个函数需要作为回调传给Windows API那调用约定必须是__stdcall不能改成__cdecl。5.3 方案三调用端适配修饰名如果DLL是第三方提供的你没法改DLL的编译方式那就只能在调用端适配。有两种做法第一种是硬编码修饰名PFN_PROCESSDATA pfn (PFN_PROCESSDATA)GetProcAddress(hDll, _ProcessData8);第二种是动态构造修饰名char szName[64]; sprintf(szName, _ProcessData%d, sizeof(int) sizeof(char*)); PFN_PROCESSDATA pfn (PFN_PROCESSDATA)GetProcAddress(hDll, szName);第二种做法稍微灵活一点但本质上还是依赖修饰规则换个编译器可能就不适用了。5.4 三种方案的对比方案适用场景优点缺点.def文件自己编译DLL导出名完全可控需额外维护文件extern C __cdecl不需要__stdcall特性简单直接不能用于回调场景调用端适配第三方DLL不改DLL脆弱依赖编译器规则6. 几个容易混淆的相关问题6.1 64位下CALLBACK还有影响吗在64位编译环境下Windows只有一种调用约定通常称为__fastcall但实际上是统一的寄存器传参规则__stdcall、__cdecl、CALLBACK这些宏都变成了空定义。所以64位下不会出现参数字节数的修饰后缀导出名就是原始名C的话仍然有名字修饰但那是另一回事。这意味着同一个DLL工程编译成32位和64位导出名可能不一样。如果你的代码需要同时支持两种架构这一点必须注意。6.2 GetProcAddress的大小写敏感性GetProcAddress的字符串匹配是大小写敏感的。ProcessData和processdata会被视为不同的名字。这一点在排查时容易被忽略——有时候你以为是调用约定的问题实际上只是大小写写错了。6.3 用序号导出时的注意事项如果DLL是用序号导出的.def文件中用序号指定那GetProcAddress需要这样调用GetProcAddress(hDll, MAKEINTRESOURCE(1));用序号导出的好处是不受名字修饰影响坏处是可读性差而且序号可能随版本变化。7. 我踩过的几个坑和实操建议第一个坑是过度依赖GetLastError。GetProcAddress失败后GetLastError返回127确实说明找不到程序但这个找不到可能是名字不匹配、可能是大小写问题、可能是修饰名问题。不要看到127就只往一个方向想。第二个坑是忽略了32位和64位的差异。我一开始在64位环境下测试怎么都复现不了问题后来切换到32位才看到修饰名。如果你在排查类似问题先确认目标平台是32位还是64位。第三个坑是调用端和DLL端的声明不一致。调用端声明函数指针时用了CALLBACKDLL端也用了CALLBACK看起来是一致的但GetProcAddress的查找过程根本不看你的函数指针类型声明。它只看字符串。所以声明一致不代表查找能成功。实操建议方面我现在的习惯是DLL工程一律用.def文件管理导出名不管用不用CALLBACK。这样导出名永远是干净的原始名调用端不用关心修饰规则。另外在调用GetProcAddress之前先用dumpbin /exports确认一下实际的导出名比盲目猜测高效得多。还有一个技巧如果DLL是你自己编译的可以在工程设置里把导出符号选项打开让编译器生成一个.exp文件里面会列出所有导出符号的最终名字。这个文件在排查导出问题时非常有用。8. 从这个问题延伸出去的思考GetProcAddress返回127这个问题表面上看是一个API使用问题实际上反映的是Windows平台下DLL导出机制的复杂性。调用约定、名字修饰、导出方式、编译架构这几个因素交织在一起任何一个不一致都可能导致查找失败。我在实际项目中还遇到过另一种情况DLL用__declspec(dllexport)导出了函数但同时在.def文件里也声明了导出结果导出表里出现了两个名字——一个是修饰名一个是.def里指定的名字。这种情况下用.def里的名字能查到用修饰名也能查到但用原始名不带下划线查不到。这种双导出的情况更隐蔽因为dumpbin的输出里会看到两行容易让人困惑。解决这类问题的根本思路是明确导出名的最终形态然后让调用端用完全一致的名字去查。不要假设我写了什么名字导出表里就是什么名字。在Windows平台上这个假设在32位环境下几乎总是错的。如果你正在设计一个需要跨模块调用的DLL接口我的建议是要么用.def文件锁定导出名要么用extern C加__cdecl要么在调用端做名字适配。三条路选一条走到底不要混着用。混着用的时候问题往往不会立刻暴露而是在某个特定编译配置下突然出现那时候排查成本就高了。
：超时语义、虚假唤醒与实战避坑)
