Есть ли причины, почему перенаправление DLL не будет работать кроме присутствия декларации?

У нас есть приложение VB6 прежней версии, которое использует КСИ Crystal Reports для генерации распечатанных отчетов. Мы нашли через опыт, что механизм печати Crystal Reports отказывает, если он берет неверную версию usp10.dll (библиотека Windows Uniscribe).

У одного клиента последовательно есть проблемы печати об их машинах Windows 7 (выполняющий Предприятие Windows 7, 32-разрядное). Однако у нас есть несколько других клиентов, выполняющих различные выпуски Windows 7, которые не имеют никаких проблем.

На одной из машин, которая имела проблемы печати, я заметил, что была более старая версия usp10.dll (одно несовместимое с КСИ Crystal Reports) в папке C:\Program Files\Common Files\Microsoft Shared\Office10\. Я не уверен, какое приложение установило эти файлы, потому что у клиента нет Office 2002 установленным (таким образом, я предполагаю, что другое приложение установило их). Однако я временно переименовал файл, и наше приложение смогло распечатать правильно, таким образом, кажется, что наше приложение загружало ту версию файла первоначально, который вызывал катастрофические отказы.

Катастрофический отказ только происходит момент, пользователь пытается распечатать отчет. Наше приложение имеет прямые зависимости от craxdrt.dll (Библиотека времени выполнения Разработчика ActiveX Crystal Reports) и crviewer.dll (библиотека Crystal ActiveX Report Viewer), и катастрофический отказ происходит, печатаем ли мы непосредственно через craxdrt.dll или посредством управления Средством просмотра Отчета.

В прошлом мы решили этот вопрос путем копирования известной хорошей версии usp10.dll в каталог нашего приложения и создания .local файла для включения перенаправления DLL. На сайте для клиентов я попробовал это и также попробовал альтернативный подход создания .local папки для нашего EXE и размещения usp10.dll там, но никакой подход не работал над машиной, с которой я был подключен.

Я действительно замечал, что usp10.dll является "известный" DLL в Windows (он имеет запись в HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs), но я протестировал наше приложение на другой машине Windows 7 (работающий Professional Edition, 32-разрядный) здесь, которому также перечислили DLL как известный DLL в реестре, и при помощи Зависимости Walker, я видел, что перенаправление работало над тем компьютером. Это несколько сбивает с толку, так как документация Microsoft указывает, что известный DLL не может быть перенаправлен. Кроме того, когда я подразумевал в заголовке вопроса, наш основной EXE не использует файл манифеста (документация Microsoft указывает, что присутствие декларации, встроенной или автономной, отключает перенаправление DLL).

Так, мой вопрос, там какая-либо другая причина, почему перенаправление DLL работало бы над некоторыми машинами и не другими, и это имеет какое-либо отношение к различиям между Windows 7 и Windows XP? Я рассмотрел удаление всего в KnownDLLs ключ реестра, но так как перенаправление работало над машиной здесь, которая имела тот же набор KnownDLLs, Я не уверен, что это на самом деле решило бы вопрос, и я не хочу удалять тот ключ, если я не должен. У меня еще не было шанса соединиться с машиной клиента снова для выполнения Зависимости Walker, но я не уверен, что смог бы интерпретировать его журналы так или иначе (даже на машине, где это работало, я видел, что много LoadLibrary призывает к usp10.dll, указывающему на папку кроме перенаправленной папки, но некоторые вызовы были, по-видимому, перенаправлены, таким образом, я не уверен, что это означает любого).

Править: Я должен был также упомянуть, что каждый компьютер, который мы проверили также, имеет другую копию usp10.dll в System32 папка. Смотря на ответ Chris и это сообщение в блоге Larry Osterman, объясняющим немного больше о том, как известные DLLs работают, я понял, что это, вероятно, не включает в проблему вообще, так как наша программа не загружает копию usp10.dll это находится в System32 папка.

РЕДАКТИРОВАНИЕ № 2: После проигрывания вокруг с Зависимостью Walker еще немного на моей машине разработки VB6 (Windows XP SP3), где печать всегда работала, я смог подобрать некоторую информацию. Я представил наше приложение в Зависимости Walker и установил его для входа имен полного пути, и похоже, что одна из зависимостей Crystal Reports (другой DLL Crystal Reports) пытается загрузить 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 в нем.

Но еще раз меня все еще оставляют с основным вопросом: если эти компоненты ищут этот файл в таком количестве различных мест, как я могу гарантировать, что они будут все использовать ту же копию?