当我的DLL存在于应用程序目录中时，为什么要从SysWOW64加载它们？ 我使用Visual Studio 2013在Windows 8.1 X64上编写了一个32位C++应用程序，它依赖于Python 3.3和LIVVLC。我的可执行文件所在的目录中有python33.dll、libvlc.dll和libvlccore.dll，我还将其设置为“项目>属性>调试”下的工作目录，除非您使用的是更改后的搜索路径（只有在运行时使用LoadLibraryEx加载DLL时才应使用该路径；在我的情况下，这些DLL是在加载时加载的），否则应始终在系统目录之前搜索应用程序目录。然而，根据VisualStudio，所有这三个DLL都是从C:\Windows\SysWOW64加载的。这给我带来了问题，因为我在那里使用的libVLC版本比我尝试使用的版本要旧得多

那篇MSDN文章只列出了正常搜索过程的3个例外。这些DLL会在进程启动时立即加载，因此很明显，这不可能是因为系统版本已经加载（但为了确保，我创建了一个.local文件，因为它提到重定向将覆盖该文件，并且没有任何效果）。我检查了注册表，看看它们是否以某种方式注册为“已知DLL”，所以这似乎不是问题所在。python33可能是作为Boost.Python的依赖项加载的，但即使它只按名称加载，也应该首先搜索app目录，而且在任何情况下，我的其他依赖项都不会引用VLC。作为猜测，我尝试将VLC LIB标记为延迟加载（由于数据导入，我无法使用Python），我得到了以下警告，我觉得很有趣：

1>LINK : warning LNK4199: /DELAYLOAD:libvlc.dll ignored; no imports found from libvlc.dll
1>LINK : warning LNK4199: /DELAYLOAD:libvlccore.dll ignored; no imports found from libvlccore.dll

但是，dumpbin显示我编译的exe从libvlc.dll导入了几个函数

---

当然，我可以替换或删除系统版本，但如果我试图分发此应用程序，这并不是一个真正的解决方案。我真的不确定还有什么会导致这种情况。有人能建议我去其他地方看看吗？

如果包含代码的相关部分，那会很有帮助。我对此没有问题，但我不确定那会是什么。DLL没有加载到代码中；这是所有VS项目设置。对DLL的搜索总是从存储EXE的目录开始。除了在操作系统目录中存储可执行文件这一非常不明智的做法之外，您没有留下任何面包屑来猜测EXE的外观或存储位置。使用SysInternals的进程监视器查看程序在目录中搜索DLL的顺序。感谢您的建议。我现在不在我的开发电脑前，但当我回来后，我会尝试一下，看看是否可以包含一些额外的信息。为了澄清，我没有将这些DLL放在系统目录中，它们已经在那里了。我在这台计算机上也有Python和VLC的独立版本，我只能假设它们是由安装人员安装的。我将此项目设置为在构建结束时将可执行文件复制到所需的目录中，但我从未将其更改为从那里实际运行，因此它已经用完了项目目录@汉斯，如果你想把你的建议作为回答，我会接受的。正如你所说，我没有留下任何线索，这是事实；我很久以前就设置好了，这对我来说并不奇怪。