windows - 除了 list 以外，是否有其他原因导致DLL重定向不起作用的原因？

Question

我们有一个旧的VB6应用程序，该应用程序使用Crystal Reports XI生成打印报告。我们已经通过经验发现，如果Crystal Reports打印引擎选择了错误版本的 usp10.dll (Windows Uniscribe库)，则它会崩溃。

一位客户在他们的Windows 7计算机(运行Windows 7 Enterprise，32位)上始终遇到打印问题。但是，我们还有一些其他客户在运行各种版本的Windows 7，但没有任何问题。

在其中一台出现打印问题的机器上，我注意到文件夹usp10.dll中有一个较旧版本的C:\Program Files\Common Files\Microsoft Shared\Office10\(一个与Crystal Reports XI不兼容)。我不确定哪个应用程序安装了这些文件，因为客户没有安装Office 2002(所以我假设是另一个应用程序安装了它们)。但是，我临时重命名了文件，并且我们的应用程序能够正确打印，因此看来我们的应用程序最初正在加载该版本的文件，这导致了崩溃。

仅当用户尝试打印报告时才发生崩溃。我们的应用程序直接依赖于 craxdrt.dll (Crystal Reports ActiveX Designer运行时库)和 crviewer.dll (Crystal ActiveX Report Viewer库)，无论是否通过 craxdrt.dll 或直接打印，崩溃都会发生通过报表查看器控件。

过去，我们已通过将已知的 usp10.dll 良好版本复制到我们应用程序的目录中并创建一个.local文件来启用DLL重定向来解决此问题。在客户站点上，我尝试了此方法，还尝试了为EXE创建.local文件夹并将 usp10.dll 放置在其中的另一种方法，但是这两种方法均不适用于我连接到的计算机。

我确实注意到 usp10.dll 是Windows中的“已知” DLL(它在HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs中有一个条目)，但是我在另一台Windows 7计算机(运行Professional Edition，32位)上测试了我们的应用程序，该计算机也具有DLL在注册表中被列为已知DLL，并且通过使用Dependency Walker，我可以看到重定向在该计算机上正常进行。这有点令人困惑，因为Microsoft documentation指出无法重定向已知的DLL。另外，正如我在问题标题中所暗示的那样，我们的主EXE不使用 list 文件(Microsoft文档指出， list 文件(嵌入式或独立)的存在会禁用DLL重定向)。

因此，我的问题是，是否有其他原因导致DLL重定向在某些计算机而不是其他计算机上起作用，并且这与Windows 7和Windows XP之间的差异有关系吗？我曾考虑删除KnownDLLs注册表项中的所有内容，但是由于重定向在此处使用的是一组相同KnownDLLs的计算机上运行，​​因此我不确定这是否能真正解决问题，因此我不想删除该问题。关键，如果我不需要的话。我还没有机会再次连接到客户的机器上以运行Dependency Walker，但是我不确定我是否仍然能够解释其日志(即使在工作的机器上，我也看到了很多LoadLibrary调用 usp10.dll 指向指向重定向文件夹以外的其他文件夹，但是显然某些调用已被重定向，因此我不确定这是什么意思。

编辑:我还应该提到，我们检查过的每台计算机在usp10.dll文件夹中也都有另一个System32副本。在看Larry Osterman的Chris的answer和this blog post解释了更多有关已知DLL的工作原理后，我意识到，这可能根本不算问题，因为我们的程序没有加载usp10.dll中的System32副本。文件夹。

编辑＃2 :在Dependency Walker上运行了VB6开发机器(Windows XP SP3)后，在该机器上始终可以进行打印，在此基础上，我可以搜集一些信息。我在Dependency Walker中分析了我们的应用程序，并将其设置为记录完整路径名，并且看起来其中一个Crystal Reports依赖项(另一个Crystal Reports DLL)尝试在给出多个(硬编码)路径之前从多个(硬编码)路径加载 usp10.dll 并仅按文件名要求它。事实证明，它首先尝试从Crystal Reports的bin文件夹加载它，然后尝试从C:\Program Files\Common Files\Microsoft Shared\Office10\usp10.dll加载它。如果在任何一个位置都找不到它，它只会向Windows请求usp10.dll(它将在System32中抓取一个)。但是，即使这样也不是一致的。有时，它在Office10文件夹中请求文件，然后似乎忽略了它找不到文件的事实，而其他时候，出现了一系列LoadLibrary调用，看起来像Crystal Reports代码正在积极寻找替代文件文件在不同位置的副本。更令人困惑的是，至少其中一个Crystal Reports组件看起来实际上对 usp10.dll 具有加载时间依赖性，因此该组件似乎总是以System32的形式获得副本。

我仍然不是100％清楚为什么在这种情况下该客户的计算机上无法使用.local重定向，但是我认为这部分解释了为什么该特定客户遇到问题，因为所有有问题的计算机都具有Office10文件夹里面有明显不兼容的usp10.dll版本。

但是，我仍然有一个基本问题:如果这些组件在那么多不同的地方寻找该文件，我如何保证它们都将使用相同的副本？

Answer 1

我的第一个念头是:.manifest文件及其所包含的所有内容都是在2002/2003年添加到Windows XP中的。
为什么您的应用程序使用@＃$％-以及您的应用程序为此使用的库-为什么不使用此技术来解决这个小“dll hell ”问题。这正是他们要解决的方案。

接下来，我非常确定“KnownDlls”仅涵盖操作系统实际上在System32中找到的dll。我希望在随机路径位置(如在Office2002文件夹中)查找dll，我希望至少能够通过一些内部的健全性检查(is-the-dll-a-real-KnownDlls-candidate)测试。并且PATH是在系统文件夹之后搜索的，因此在...\Office10\中找到usp10.dll时-它不能是真正的已知dll(根据定义)。

下一步，我还确保.local文件没有按照您的想象做。 .local文件的文档根本没有任何意义，因为它的真正含义是，应用.local文件后dll的搜索顺序通常是dll通常的默认搜索顺序-exe文件夹始终在系统文件夹之前进行搜索反正。

.local唯一可能造成潜在差异的时间是应用程序在调用loadLibrary时使用显式路径加载dll(或使用对LoadLibrary进行更改的搜索路径标记或使用SetDllSearchDirectory API)。在执行加载的exe或dll的所有情况下，都选择了非常特定的dll-应用作者希望通过某种方式覆盖该dll。 .local文件不能(无论如何对我来说)无法更改仅由其名称指定的任何dll文件的搜索行为。

因此，如果将usp10.dll安装到system32中，则尽管您的本地副本(和.local文件)，也可能会将其作为KnownDll取回然后再使用。
如果它在路径上的其他位置，则无论如何都应首先使用exe文件夹中的副本-(假设DLL的加载方式为LoadLibrary(“usp10.dll”))。

即使您竭尽全力创建一个程序集来包含已知良好的usp10.dll，然后使您的应用程序依赖于该程序，我仍然认为传递给LoadLibrary的完全限定路径将彻底破坏任何搜索逻辑-包括在相关程序集列表中查找dll。

因此，您的问题使我感到困惑。使用的usp10.dll应该是

如果存在，则为system32中的那个(因为KnownDlls覆盖了exe文件夹中的那个)

是您的应用程序文件夹中的那个，因为如果KnownDlls遗漏了，搜索逻辑将始终首先找到它。

除非usp10.dll实际上是一个com dll，或者在注册表中有完整的标准路径供消费者用来加载它，在这种情况下，加载的路径应该是:

是您的应用程序文件夹中的那个，因为这似乎是可能应用.local文件的一种情况。

鉴于KnownDLL中DLL的存在抑制了.local的功能，并且鉴于Crystal Reports dll是病理性的...

我能建议的是:

该线程包含一个名为PatchIAT的函数-将其导入您的代码中。

在Crystal Reports dll中使用任何功能之前(这会导致它们去寻找usp10.dll)-调用LoadLibrary以获取dll的句柄，然后在该句柄上调用PatchIAT，以将dll对LoadLibrary的调用重定向到您的函数EXE工具。

在您的EXEs LoadLibraryThunk过程中，将对系统LoadLibrary的所有调用都传递出去，除非它为usp10.dll的显式路径(在这些调用上)返回错误代码。

Disable antialiasing for a specific GDI device context