从Win10 VS2019迁移至Win11 VS2022时DLL加载失败求助

排查建议 #

• 使用Dependencies工具（替代旧版Dependency Walker）动态检查DLL加载流程，它能实时显示哪个依赖项加载失败，包括依赖的依赖的问题——dumpbin仅能查看静态导入表，无法捕捉延迟加载或运行时依赖缺失。
• 确认目标DLL是32位（X86）编译版本：虽然syswow64是32位DLL的系统目录，但如果你的DLL实际是64位，32位主应用会直接加载失败。
• 复制DLL到主应用的执行目录，尝试不用全路径调用：Win11对系统目录的访问限制更严格，即使指定全路径，也可能因安全策略（如Smart App Control）被拦截，移到应用目录可排除系统目录的权限/拦截问题。
• 重新安装32位VS2013 Visual C++ Redistributable：Win11默认不预装VS2013的运行库，即使syswow64中有msvcr120.dll等文件，版本或完整性可能不符合DLL的编译要求。
• 启用Windows加载日志：在注册表HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\YourApp.exe下添加ShowSnaps=dword:00000001，运行应用后查看事件查看器的“Windows日志-应用程序”，获取具体的加载失败模块信息。
• 验证函数导出的调用约定：用dumpbin /exports MyFile.dll检查MyFile_open_device的导出方式，确认是__cdecl调用约定——若DLL内实际是__stdcall，VS2022的.NET运行时可能比VS2019的.NET Framework更严格，直接导致加载失败。

Win10/Win11 及 VS2019/VS2022 可能的变更点 #

系统层面（Win10 → Win11） #

• 系统目录安全限制增强：Win11的Smart App Control、系统文件保护机制对非微软签名的DLL加载到syswow64等系统目录的拦截更严格，即使文件存在也可能被阻止加载。
• 32位程序兼容性适配变更：Win11对部分老旧32位API的兼容性做了调整，若你的C++ DLL依赖某些已被标记为废弃或移除的Win32 API，会导致加载时依赖缺失。
• UAC虚拟化行为变更：Win11的UAC虚拟化对系统目录的重定向逻辑更严格，非管理员权限的32位程序访问syswow64时，可能被重定向到用户虚拟目录，导致实际访问的不是你放置的DLL。

开发工具层面（VS2019 → VS2022） #

• .NET运行时行为差异：若你的VB应用从VS2019的.NET Framework迁移到VS2022的.NET 5+/Core，DllImport的路径解析、调用约定校验逻辑更严格——.NET Framework可能容忍部分调用约定不匹配的情况，而.NET Core会直接抛出加载失败错误。
• 项目默认配置变更：VS2022默认的项目设置（如平台目标、运行库选项）可能与VS2019不同，若误将32位项目配置改为Any CPU或64位，会导致加载32位DLL失败。
• 调试环境权限差异：VS2022的调试器默认权限策略可能比VS2019更严格，调试时加载系统目录下的自定义DLL会被拦截，需手动以管理员身份启动VS2022调试。

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