最直接方法是用dumpbin工具在VS开发人员命令提示符中执行dumpbin /exports my.dll，关注ordinal、name和entry point三列，注意函数名显示“???”说明未按C风格导出。
用dumpbin查看DLL导出函数最直接
Windows平台下，dumpbin 是微软官方工具，无需写代码就能快速列出DLL所有导出符号。它读取PE文件的导出表（Export Table），结果可靠且不依赖运行时环境。
常见错误是直接双击运行 dumpbin——它必须在Visual Studio开发人员命令提示符中使用，否则会报“不是内部或外部命令”。路径不对或未初始化环境变量时，dumpbin /exports my.dll 会失败。
- 打开“x64 Native Tools Command Prompt for VS XXX”（版本需匹配你的DLL编译器）
- 执行：
dumpbin /exports path\to\your.dll - 关注输出中的“ordinal”、“name”和“entry point”三列；若某函数名显示为“
???”，说明该函数未按C风格导出（即没加extern "C"或.def文件未声明） - 如需导出到文本文件，加重定向：
dumpbin /exports my.dll > exports.txt
用LoadLibrary + GetProcAddress验证函数是否真能调用
dumpbin 只看声明，不代表函数能实际加载调用。有些DLL导出的是序号（ordinal）而非名称，或函数被标记为 PRIVATE（仅链接器可见），此时 GetProcAddress 会返回 NULL。
典型场景：你从 dumpbin 看到函数名 InitEngine，但 GetProcAddress(hMod, "InitEngine") 返回空指针。这往往是因为DLL用 .def 文件导出时写了 NONAME，或者用了 __declspec(dllexport) 但编译器做了名字修饰（name mangling）。
立即学习“C++免费学习笔记（深入）”；
- 先用
LoadLibrary加载DLL，检查返回值是否非NULL - 对每个导出名调用
GetProcAddress(hMod, "func_name")，不要只信dumpbin输出 - 若函数名带修饰（如
?CreateInstance@@YAPAVMyClass@@XZ），得用修饰后的全名，或改用序号方式：GetProcAddress(hMod, (LPCSTR)1)（1 是 ordinal 值） - 调用后记得
FreeLibrary，避免句柄泄漏
用Dependency Walker或Dependencies工具看实时依赖与导出
当 dumpbin 显示函数但 GetProcAddress 失败，或DLL有延迟加载、条件导出逻辑时，静态分析不够用。Dependencies（现代替代品，开源免费）能模拟真实加载过程，显示哪些导出实际被解析、哪些因缺失依赖而跳过。
容易踩的坑是误用老版 Dependency Walker（depends.exe）：它不支持Win10+的API集（API Sets）机制，常把合法导出标为“missing”，造成误判。
- 下载最新版
Dependencies（github.com/lucasg/Dependencies） - 拖入DLL，点“Scan”；左侧树状图展开“Exports”，右键可复制函数名
- 注意看“Status”列：绿色表示可解析，灰色表示无实现（stub）、重定向或被屏蔽
- 它还能显示函数是否来自导入库（.lib）而非本DLL，避免你追错源头
C++代码里遍历导出表要小心PE结构偏移
如果非要自己解析PE头读导出表（比如做插件扫描器），别硬啃《Windows PE权威指南》——多数人漏掉关键校验：32位和64位DLL的NT头大小不同，IMAGE_NT_HEADERS 后紧跟的 IMAGE_DATA_DIRECTORY 数组索引也不同。导出表位置由 OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT] 给出，但这个字段在某些壳或混淆DLL里可能被清零或伪造。
真正稳定的做法是：先用 MapViewOfFile 映射DLL文件（非 LoadLibrary），再手动解析。否则用 LoadLibrary 后读内存，会受ASLR、重定位影响，地址算不准。
- 务必检查
NumberOfNames和NumberOfFunctions是否匹配，不一致说明导出表损坏或被篡改 - 函数名地址是RVA（相对虚拟地址），必须加上模块基址才能访问；别直接当指针解引用
- 字符串比较用
strcmp而非wcscmp——PE导出表里函数名永远是ANSI字符串，哪怕DLL本身是Unicode编译 - 大多数情况下，不如直接调用
dumpbin或Dependencies的CLI模式，省去PE解析的边界case
导出表结构本身不复杂，但绕不开Windows加载器细节。真正卡住人的，往往不是怎么读，而是读出来之后发现那个函数根本不能调——名字对不上、调用约定不匹配、参数类型隐式转换失败。动手前，先确认你要的函数确实是按C ABI导出的。
