DllNotFoundException 表明运行时找不到指定DLL,主因是路径、架构或依赖问题:需确认DLL在可执行文件同目录或系统搜索路径中,确保平台目标(x86/x64)匹配,用Dependencies检查隐式依赖,并可用SetDllDirectory显式指定加载路径。
遇到 DllNotFoundException,说明 P/Invoke 调用时找不到指定的动态链接库(DLL),不是代码写错了,而是运行时环境缺了关键“拼图”。核心问题通常出在路径、架构、依赖或部署上,而不是 P/Invoke 声明本身。
Windows 加载 DLL 有明确搜索顺序:当前目录 → 系统目录(如 System32)→ PATH 环境变量所列目录。P/Invoke 默认只按这个规则找,不会自动查 bin/Debug 或项目根目录。
Process Monitor(Sysinternals 工具)过滤进程名 + “PATH”和“CreateFile”,能清楚看到它到底去哪找了哪些路径32 位程序无法加载 64 位 DLL,反之亦然。常见坑是:开发机是 64 位,但项目设成了 x86,结果调用 system32 下的 64 位 DLL 就失败(因为 x86 进程实际访问的是 SysWOW64)。
bit 也要留意)dumpbin /headers xxx.dll 查看 DLL 架构(在 VS 开发人员命令提示符中运行)你的 DLL 可能依赖其他 DLL(比如 VC++ 运行时、OpenSSL、特定显卡驱动库)。即使你放对了主 DLL,缺了它的依赖,照样抛 DllNotFoundException。
Dependencies(现代替代 Dependency Walker,支持 Win10/11)打开你的 DLL,看红色标记的缺失模块如果必须从非标准路径加载(比如插件目录、用户配置目录),别靠系统搜索,主动干预更可靠。
SetDllDirectory(@"C:\MyApp\NativeLibs"),后续所有 P/Invoke 都会优先从此路径找LoadLibrary + GetProcAddress 手动加载(需 DllImport("kernel32.dll") 引入),适合按需加载或容错处理SetDllDirectory 影响整个进程,多线程下要小心;建议在 Main 方法开头尽早调用基本上就这些。DllNotFoundException 看似吓人,其实是个“找不到东西”的直白提示。盯住路径、架构、依赖三层,再配上工具验证,95% 的情况都能快速定位。不复杂,但容易忽略细节。