这问题我之前在桌面程序打包部署时碰到过类似的，大概率是文件系统重定向或者DLL搜索路径的权限差异在搞鬼，咱们一步步拆解排查和解决：

一、先定位DLL的实际加载路径 #

首先得搞清楚非管理员模式下到底加载了哪个路径的DLL，和管理员模式的差异在哪里：

• 用Process Monitor（ProcMon）抓两次运行的日志：分别以管理员和非管理员启动程序，过滤Load Image事件，对比两次加载目标DLL的路径。
• 重点看是不是系统目录（比如C:\Windows\SysWOW64）或者用户虚拟目录里的旧版DLL被优先加载了——非管理员权限下，UAC的文件重定向机制很容易把程序对Program Files目录的写入请求转到用户的虚拟存储区，那里可能残留了旧版本的DLL。

二、检查安装目录权限与UAC重定向 #

1. 去用户虚拟目录看看：路径一般是C:\Users\<你的用户名>\AppData\Local\VirtualStore\Program Files(x86)\<你的程序安装目录>，如果这里有目标DLL，大概率是之前程序试图写入安装目录被重定向，导致旧版本留在这里，非管理员运行时优先加载了这个。
2. 检查InstallShield的权限配置：确保安装包给程序安装目录设置了非管理员用户的读取权限——默认安装到Program Files(x86)的话，非管理员默认只有读取权限，但如果安装包配置错误，可能连读取都没有，程序就会去系统目录找DLL。

三、验证DLL依赖与Manifest配置 #

1. 用VS自带的Dependencies工具或者旧版的Dependency Walker，检查程序依赖的DLL版本，确认安装目录里的DLL版本是正确的，没有和系统目录里的版本冲突。
2. 检查应用程序的Manifest文件：Release模式下的程序有没有嵌入正确的Manifest？如果Manifest里没有指定DLL的版本或者搜索路径，系统会按照默认的DLL搜索顺序找，很容易优先加载系统目录的旧版本。可以在Manifest里添加<probing privatePath="."/>，让程序优先从本地安装目录加载DLL；如果是有版本要求的DLL，还可以添加<file>元素指定具体版本。

四、调整InstallShield打包配置 #

1. 确认所有依赖的DLL都被正确打包到安装目录，没有遗漏或者错误地指向了系统目录的文件。
2. 避免在安装时把DLL注册到系统全局目录（比如SysWOW64），除非是必须的系统级DLL——全局注册的DLL很容易被其他程序覆盖，导致版本冲突。

五、临时测试方案（用于验证） #

如果怀疑是Wow64文件系统重定向导致的，可以在程序启动时调用Wow64DisableWow64FsRedirection函数临时禁用重定向，测试是否能加载正确的DLL。不过这只是临时验证，不建议作为长期解决方案，最好还是从路径和权限上解决根源问题。

内容的提问来源于stack exchange，提问作者Im-Harrison