最直接命令是dumpbin /exports mylib.dll，需在VS开发者命令提示符中执行，确保架构匹配（x64 DLL用x64工具链），否则报“invalid or corrupt file”错误。
用dumpbin查看DLL导出函数最直接
Windows SDK 自带的 dumpbin 是最快验证 DLL 导出符号的方式，无需写代码、不依赖运行时环境。它读取 PE 文件头和 .edata 节，直接解析导出表（Export Directory Table），结果准确且稳定。
常见错误是误用 dumpbin /imports（看导入）或漏加 /exports 参数：
-
dumpbin /exports mylib.dll—— 正确，输出序号、RVA、名称、序号（ordinal） -
dumpbin /headers mylib.dll—— 只能看到节信息，看不到函数名 - 在非 VS 开发者命令提示符中运行会报“'dumpbin' 不是内部或外部命令”——需先运行
"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars64.bat"（路径按实际版本调整）
用LoadLibrary + EnumProcessModules不可行，别试
有人试图用 LoadLibrary 加载 DLL 后调用 EnumProcessModules 或遍历内存模块，这条路走不通。原因很实在：EnumProcessModules 只返回已加载模块的句柄和大小，不提供任何符号信息；Windows 不在运行时维护导出函数名到地址的反向映射。
真正能拿到导出名的只有两种方式：静态解析 PE 文件（如 dumpbin、objdump、自写解析器），或通过 GetProcAddress 逐个尝试已知函数名（但前提是名字已知）。
立即学习“C++免费学习笔记（深入）”；
所以如果你的目标是“发现未知导出函数”，必须走静态分析，不能依赖运行时 API。
用MinGW的objdump替代dumpbin（跨平台/无VS场景）
没有 Visual Studio 时，MinGW-w64 自带的 objdump 同样可靠，且支持 Linux/macOS 下交叉分析 Windows DLL：
-
objdump -x mylib.dll | grep "Ordinal\|Name"—— 快速过滤导出节 -
objdump -p mylib.dll—— 输出完整 PE 头，含 Export Directory RVA 和 Size - 注意：
objdump对某些编译器（如 MSVC 默认）生成的 DLL 解析更全；而对 MinGW 编译的 DLL，若用了--disable-auto-import，可能显示为间接跳转 stub，此时要结合-d反汇编确认真实目标
相比 dumpbin，objdump 不依赖 Windows 环境，适合 CI 流水线中做二进制检查。
自己写PE解析器要小心IMAGE_EXPORT_DIRECTORY结构偏移
手动解析 PE 文件时，最容易出错的是定位 IMAGE_EXPORT_DIRECTORY：它不在固定偏移，必须从 DOS 头 → NT 头 → 可选头 → 数据目录第 0 项（IMAGE_DIRECTORY_ENTRY_EXPORT）逐层跳转。硬编码偏移（比如直接读 0x80 处）大概率失败。
关键字段处理要点：
-
AddressOfNames指向函数名 RVA 数组，不是字符串数组本身；每个元素是 4 字节 RVA，需加上镜像基址才得真实地址 -
AddressOfNameOrdinals和AddressOfFunctions都是 RVA 数组，三者长度由NumberOfNames决定，但NumberOfFunctions可能更大（存在未命名导出） - 函数名比较要用
strcmp或lstrcmpA，别用wcscmp——绝大多数 DLL 导出名是 ANSI 字符串，即使模块是 Unicode 编译的
真正麻烦的不是读数据，而是处理重定位、节对齐（SectionAlignment vs FileAlignment）、以及某些打包器（如 UPX）破坏导出表的情况——这时候连 dumpbin 都会报错，就得先脱壳。
