除了清单的存在之外，还有其他原因导致 DLL 重定向不起作用吗？

发布于 2024-09-13 02:28:35 字数 3469 浏览 3 评论 0原文

我们有一个旧版 VB6 应用程序，它使用 Crystal Reports XI 生成打印报告。我们根据经验发现，如果 Crystal Reports 打印引擎选择错误版本的 usp10.dll（Windows Uniscribe 库），它就会崩溃。

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

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

崩溃仅在用户尝试打印报告时发生。我们的应用程序直接依赖于craxdrt.dll（Crystal Reports ActiveX Designer Runtime 库）和crviewer.dll（Crystal ActiveX Report Viewer 库），并且崩溃发生在以下情况：我们直接通过craxdrt.dll或通过Report Viewer控件进行打印。

过去，我们通过将已知良好版本的 usp10.dll 复制到应用程序目录并创建 .local 文件以启用 DLL 重定向来解决此问题。在客户站点，我尝试了这个，还尝试了为 EXE 创建 .local 文件夹并将 usp10.dll 放入其中的替代方法，但这两种方法都没有在我连接的机器上工作。

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

所以，我的问题是，是否还有其他原因导致 DLL 重定向在某些计算机上起作用而在其他计算机上不起作用，这是否与 Windows 7 和 Windows XP 之间的差异有关？我曾考虑过删除 KnownDLLs 注册表项中的所有内容，但由于重定向是在具有相同 KnownDLLs 集的计算机上进行的，因此我不确定这是否会发生。实际上解决了问题，如果不需要，我不想删除该密钥。我还没有机会再次连接到客户的计算机来运行 Dependency Walker，但我不确定我是否能够解释其日志（即使在它所在的计算机上）工作时，我看到很多 LoadLibrary 对 usp10.dll 的调用指向重定向文件夹以外的文件夹，但有些调用显然已重定向，所以我不确定这意味着什么）。

编辑：我还应该提到，我们检查的每台计算机在 System32 文件夹中也有另一个 usp10.dll 副本。看看克里斯的答案和Larry Osterman 的这篇博文详细解释了已知 DLL 的工作原理，我意识到这可能根本不影响问题，因为我们的程序没有加载 System32 文件夹中的 usp10.dll 副本。

编辑 #2：在我的 VB6 开发机器 (Windows XP SP3) 上玩了一些 Dependency Walker 后，打印始终可以正常工作，我能够收集到一些信息信息。我在 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。

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

原文

We have a legacy VB6 application that uses Crystal Reports XI to generate printed reports. We've found through experience that the Crystal Reports print engine crashes if it picks up the wrong version of usp10.dll (the Windows Uniscribe library).

One customer is consistently having printing issues on their Windows 7 machines (running Windows 7 Enterprise, 32-bit). However, we have a few other customers running various editions of Windows 7 that are not having any problems.

On one of the machines that was having printing issues, I noticed that there was an older version of usp10.dll (one incompatible with Crystal Reports XI) in the folder C:\Program Files\Common Files\Microsoft Shared\Office10\. I'm not sure what application installed these files, because the customer doesn't have Office 2002 installed (so I assume another application installed them). However, I temporarily renamed the file and our application was able to print correctly, so it seems that our application was loading that version of the file originally, which was causing the crashes.

The crash only happens the moment the user tries to print a report. Our application has direct dependencies on craxdrt.dll (the Crystal Reports ActiveX Designer Runtime library) and crviewer.dll (the Crystal ActiveX Report Viewer library), and the crash happens whether we print directly through craxdrt.dll or through the Report Viewer control.

In the past, we have resolved this issue by copying a known good version of usp10.dll into our application's directory and creating an .local file to enable DLL redirection. At the customer site, I tried this, and also tried the alternate approach of creating a .local folder for our EXE and placing the usp10.dll in there, but neither approach worked on the machine I was connected to.

I did notice that usp10.dll is a "known" DLL in Windows (it has an entry in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs), but I tested our application on another Windows 7 machine (running Professional Edition, 32-bit) here that also had the DLL listed as a known DLL in the registry, and by using Dependency Walker, I could see that the redirection was working on that computer. This is somewhat confusing, since the Microsoft documentation states that known DLL's cannot be redirected. Also, as I implied in the question title, our main EXE does not use a manifest file (the Microsoft documentation states that the presence of a manifest, embedded or standalone, disables DLL redirection).

So, my question is, is there any other reason why DLL redirection would work on some machines and not others, and does this have anything to do with differences between Windows 7 and Windows XP? I had considered deleting everything in the KnownDLLs registry key, but since the redirection was working on a machine here that had the same set of KnownDLLs, I'm not sure that would actually resolve the issue, and I don't want to delete that key if I don't need to. I haven't yet had a chance to connect to the customer's machine again to run Dependency Walker, but I'm not sure I would be able to interpret its logs anyway (even on the machine where it was working, I saw a lot of LoadLibrary calls for usp10.dll pointing to a folder other than the redirected folder, but some calls were apparently redirected, so I'm not sure what that means either).

EDIT: I should have also mentioned that every computer we've checked also has another copy of usp10.dll in the System32 folder. Looking at Chris's answer and this blog post by Larry Osterman explaining a bit more about how known DLLs work, I realized that that probably doesn't factor into the problem at all, since our program isn't loading the copy of usp10.dll that is in the System32 folder.

EDIT #2: After playing around with Dependency Walker some more on my VB6 development machine (Windows XP SP3), where the printing has always worked, I was able to glean some information. I profiled our application in Dependency Walker and set it to log full path names, and it looks like one of the Crystal Reports dependencies (another Crystal Reports DLL) tries to load usp10.dll from multiple (hard-coded) paths before giving up and just asking for it by filename. It turns out that it tries to load it from the Crystal Reports bin folder first, then tries to load it from from C:\Program Files\Common Files\Microsoft Shared\Office10\usp10.dll. If it can't find it at either location, it just asks Windows for usp10.dll (which will grab the one in System32). But even this isn't consistent. Sometimes it asks for the file in the Office10 folder, and then appears to ignore the fact that it couldn't find the file, while other times there are a series of LoadLibrary calls where it looks like the Crystal Reports code is actively looking for alternate copies of the file in different locations. Even more confusing is that at least one of the Crystal Reports components looks like it actually has a load-time dependency on usp10.dll, so that component always seems to get the copy in System32.

I'm still not 100% clear why the .local redirection wouldn't work in this situation on this customer's computers, but I think that partly explains why this particular customer is having problems, since all of the computers with the problem have an Office10 folder with an apparently incompatible version of usp10.dll in it.

But, once again, I'm still left with the basic question: if these components are looking for this file in so many different places, how can I guarantee that they will all use the same copy?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

手心的温暖 2024-09-20 02:28:35

我的第一个想法是：.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 中，它可能会被选为 KnownDll，然后使用 - 尽管您有本地副本（和 .local 文件）。
如果它位于路径上的其他位置，则无论如何应该首先使用 exe 文件夹中的副本 - （假设 LoadLibrary("usp10.dll") 是加载 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 实现。

在您的 EXE LoadLibraryThunk 过程中，传递对系统 LoadLibrary 的任何调用，除非它是指向 usp10.dll 的显式路径 - 在这些调用上 - 返回错误代码。

禁用特定 GDI 设备上下文的抗锯齿功能

My first thought: .manifest files and all they imply were added to windows XP in 2002/2003.
Why the @#$% does your app - and the libraries your app uses for that matter - not use this technology to solve this little "dll-hell". It is exactly the scenario they were developed to solve.

Next, im pretty sure that "KnownDlls" only covers dlls that the OS actually finds in System32. Finding dll's in random path locations (as in a Office2002 folder) i would hope at least would fail some internal sanity check (is-the-dll-a-real-KnownDlls-candidate) test. And the PATH is searched after system folders, so by the time a usp10.dll is found in ...\Office10\ - it' cant be a real known dll (by definition).

Next, Im also sure that the .local file isn't doing what you think it is. The documentation for .local files makes no sense at all because all it really says is, the search order for dlls after a .local file is applies, is exactly the default search order for dll's normally - the exe folder is always searched BEFORE system folders anyway.

The only time .local actually makes a potential difference is when an application uses an explicit path to load a dll in a call to loadLibrary (or uses the altered search path flag to LoadLibrary or uses the SetDllSearchDirectory API). All cases where the exe or dll doing the loading is choosing a very specific dll - that you the app author wants to override in some way. .local files cannot (Seem to me anyway) change the search behaviour for any dll files that are specified by just their name.

So, if usp10.dll is installed into system32, its probably going to be picked up as a KnownDll and then used - despite your local copy (and .local file).
If its somewhere else on the path, the copy in your exe's folder should be used first anyway - (assuming LoadLibrary("usp10.dll") is the way the dll is loaded).

Even if you go to all the effort of creating an assembly to contain your known-good usp10.dll, and then made your app dependent on that, I still think that a fully qualified path passed to LoadLibrary will defeat any search logic at all - including looking for the dll in the list of dependent assemblies.

So, your problem confuses me. The usp10.dll used should be

the one in system32 if present (because of KnownDlls overring the one in your exe's folder)
the one in your application folder, because search logic will always find this one first if KnownDlls is a miss.

unless usp10.dll is actually a com dll, or there is a fully qualified path to it in the registry that consumers use to load it, in which case the one loaded should be :

the one in your application folder, because this seems to be the one case where .local files might apply.

Given that the presence of the DLL in KnownDLLs is inhibiting the functionality of .local, and given that Crystal reports dlls are pathalogical ...

All I can suggest is:

This thread contains a function called PatchIAT - import it into your code.

Before using any functionality in the Crystal Reports dlls (That causes them to go looking for usp10.dll) - call LoadLibrary to get a handle to the dll, then call PatchIAT on the handle, to redirect the dll's call to LoadLibrary to a function your EXE implements.

In your EXEs LoadLibraryThunk procedure, pass on any calls to the system's LoadLibrary, unless its for an explicit path to usp10.dll - on those calls - return an error code.

Disable antialiasing for a specific GDI device context

回复收藏 0 原文

梦冥 2024-09-20 02:28:35

该解决方案实际上非常简单，但我花了一段时间才弄清楚它为什么有效。

在客户计算机上，我将 usp10.dll 从 C:\Windows\System32 （已知良好版本）复制到文件夹 C:\Program Files \Common Files\Business Objects\3.0\bin（其中安装了大多数 Crystal 组件）。然后，我运行了 bin 文件夹中已存在的 crdeploy.reg 文件：该文件添加了 HKEY_LOCAL_MACHINE\SOFTWARE\Business Objects\Suite 11.0\Crystal将 项报告给注册表，并将值 CommonFiles 设置为 C:\Program Files\Common Files\Business Objects\3.0\bin。

由于今天早些时候我无法连接到客户的计算机，因此我在 Windows 7 虚拟机上对该问题进行了更多测试。正如我在一次编辑中提到的，在这台计算机上，Crystal Reports 从未在 C:\Program Files\Common Files\Business Objects\3.0\bin 目录中查找 usp10.dll strong>，因此它会立即尝试加载 C:\Program Files\Common Files\Microsoft Shared\Office10 文件夹中的副本。

事实证明，当 Crystal Reports 调用 LoadLibrary 时，它会检查以下文件夹中的 usp10.dll：

If HKEY_LOCAL_MACHINE\SOFTWARE\Business Objects\Suite 11.0 \Crystal Reports\CommonFiles 存在于注册表中，它使用该路径调用 LoadLibrary。
如果注册表项不存在，或者该文件夹中不存在 usp10.dll，Crystal Reports 将使用 C:\Program 调用 LoadLibrary Files\Common Files\Microsoft Shared\Office10\usp10.dll 作为路径。
如果在 Office10 文件夹中找不到该文件，它只会将文件名 (usp10.dll) 传递给 LoadLibrary，然后使 Windows 在 System32 中加载副本。

因此，在我的测试 Windows 7 计算机上，我没有设置 CommonFiles 注册表项，因此 Crystal Reports 始终加载 usp10.dll 版本，该版本位于 < code>Office10 文件夹，即使将 usp10.dll 的副本放入 C:\Program Files\Common Files\Business Objects\3.0\bin 后也是如此。一旦我将注册表项设置为指向正确的位置，Crystal Reports 就会加载该文件的正确版本。

在客户的计算机上，注册表已将 CommonFiles 路径设置为正确的文件夹，但我们应用程序的安装程序并未将 usp10.dll 安装到该文件夹，因此它仍在 Office10 文件夹中获取副本。

为客户提供的最终解决方法非常简单：

将 usp10.dll 版本从 System32 复制到 C:\Program Files\Common Files \Business Objects\3.0\bin。
运行 bin 文件夹中的 crdeploy.reg 文件，确保 CommonFiles 注册表项存在且指向 C :\Program Files\Common Files\Business Objects\3.0\bin。

我原本以为将 usp10.dll 的副本放入 bin 文件夹中可以解决客户计算机上的问题，但正如我所说，这在我的计算机上不起作用Windows 7 测试机因为我缺少 CommonFiles 注册表项，所以我犹豫是否要考虑发布修复。

另外，为了帮助其他遇到此问题的人，涉及的 usp10.dll 版本为：

1.405.2416.1：这是 Office10 文件夹中的版本，以及导致 Crystal Reports 崩溃的问题。当您打印报表时，当 Crystal Reports 调用 usp10.dll 中的函数之一时，会发生访问冲突（我没有原始堆栈跟踪，但我认为这是 ScriptApplyDigitSubstitution< /code> 函数）。
1.626.7600.16385：这是一个已知的良好版本，可以与 Crystal Reports 正确配合使用。该版本似乎是 Windows 7 中默认安装的版本。

还有其他版本，例如默认安装在 Windows XP 中的 System32 文件夹中，也可以与 Crystal Reports 配合良好。

The solution was actually pretty simple, but it took me a while to figure out why it worked.

On the customer machine, I copied usp10.dll from C:\Windows\System32 (which is known-good version) into the folder C:\Program Files\Common Files\Business Objects\3.0\bin (where most of the Crystal components are installed). I then ran a crdeploy.reg file that was already present in in the bin folder: this file adds a HKEY_LOCAL_MACHINE\SOFTWARE\Business Objects\Suite 11.0\Crystal Reports key to the Registry and sets the value CommonFiles to C:\Program Files\Common Files\Business Objects\3.0\bin.

Since I couldn't connect to the customer's machine earlier today, I did some more testing of the issue on a Windows 7 virtual machine. Like I mentioned in one of my edits, on this computer Crystal Reports never looked in the C:\Program Files\Common Files\Business Objects\3.0\bin directory for usp10.dll, so it would immediately try to load the copy in the C:\Program Files\Common Files\Microsoft Shared\Office10 folder.

It turns out the when Crystal Reports calls LoadLibrary, it checks the following folders for usp10.dll:

If HKEY_LOCAL_MACHINE\SOFTWARE\Business Objects\Suite 11.0\Crystal Reports\CommonFiles is present in the Registry, it calls LoadLibrary using that path.
If the registry key is not present, or usp10.dll doesn't exist in that folder, Crystal Reports will call LoadLibrary with C:\Program Files\Common Files\Microsoft Shared\Office10\usp10.dll as the path.
If the file isn't found in the Office10 folder, it passes just the filename (usp10.dll) to LoadLibrary, which then causes Windows to load the copy in System32.

So, on my test Windows 7 machine, I didn't have the CommonFiles registry key set, so Crystal Reports always loaded the version of usp10.dll that was in the Office10 folder, even after putting a copy of usp10.dll in C:\Program Files\Common Files\Business Objects\3.0\bin. Once I set the registry key to point to the right place, Crystal Reports loaded the correct version of the file.

On the customer's machine, the registry already had the CommonFiles path set to the right folder, but our application's setup program wasn't installing usp10.dll to that folder, so it was still picking up the copy in the Office10 folder.

The final workaround given to the customer was stupidly simple:

Copy the version of usp10.dll from the System32 into C:\Program Files\Common Files\Business Objects\3.0\bin.
Run the crdeploy.reg file in the bin folder to ensure that the CommonFiles registry key exists and is pointing to C:\Program Files\Common Files\Business Objects\3.0\bin.

I had originally thought putting a copy of usp10.dll into the bin folder would fix the problem on the customer's machines, but like I said, this didn't work on my Windows 7 test machine because I was missing the CommonFiles registry key, so I was hesitant to consider the issued fixed.

Also, in case it helps anyone else experiencing this problem, the versions of usp10.dll involved were:

1.405.2416.1: This is the version in the Office10 folder, and the one that causes Crystal Reports to crash. When you print a report, an access violation occurs when Crystal Reports calls one of the functions in usp10.dll (I don't have the original stacktrace, but I think it was the ScriptApplyDigitSubstitution function).
1.626.7600.16385: This is a known good version that works correctly with Crystal Reports. This version seems to be the one installed in Windows 7 by default.

There are other versions, such as installed by default in Windows XP in the System32 folder that also work fine with Crystal Reports.

回复收藏 0 原文

滿滿的愛 2024-09-20 02:28:35

我刚刚在运行 Server 2008 R2 的 TS 上遇到了类似的问题。事件日志中的错误：

Log Name: Application
Source: Application Error
Date: 5/23/2012 10:32:37 AM
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: 
Description:
Faulting application name: crw32.exe, version: 11.0.0.1282, time stamp: 0x422d5c77
Faulting module name: usp10.dll, version: 1.420.2600.5969, time stamp: 0x4bc88269
Exception code: 0xc0000005
Fault offset: 0x00014ee4
Faulting process id: 0x1744
Faulting application start time: 0x01cd38f8ce57fbd5
Faulting application path: C:\Program Files (x86)\Business Objects\Crystal Reports 11\crw32.exe
Faulting module path: C:\Program Files (x86)\Common Files\Microsoft Shared\Office10\usp10.dll

我尝试将 usp10.dll 从 \Windows\System32 复制到 C:\Program Files (x86)\Common Files\Business Objects\3.0\bin。然后运行 crdeploy.reg 文件，但由于服务器上有 64 位操作系统，因此必须手动更新 regkey 以包含 (x86)。 Crystal Reports 应用程序仍然无法识别该 DLL，它一直在 \Office10 文件夹中查找。所以我只是重命名了该文件夹中的 DLL 副本，然后再次从 \System32 复制。这就像一个魅力，而且 DLL 上的文件版本与 Mike Spross 发布的完全相同。

I just had a similar issue on a TS running Server 2008 R2. Error from Event log:

Log Name: Application
Source: Application Error
Date: 5/23/2012 10:32:37 AM
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: 
Description:
Faulting application name: crw32.exe, version: 11.0.0.1282, time stamp: 0x422d5c77
Faulting module name: usp10.dll, version: 1.420.2600.5969, time stamp: 0x4bc88269
Exception code: 0xc0000005
Fault offset: 0x00014ee4
Faulting process id: 0x1744
Faulting application start time: 0x01cd38f8ce57fbd5
Faulting application path: C:\Program Files (x86)\Business Objects\Crystal Reports 11\crw32.exe
Faulting module path: C:\Program Files (x86)\Common Files\Microsoft Shared\Office10\usp10.dll

I tried copying usp10.dll from \Windows\System32 into C:\Program Files (x86)\Common Files\Business Objects\3.0\bin. Then ran the crdeploy.reg file but had to manually update the regkey to include (x86) due to 64bit OS on server. The Crystal Reports app still wouldn't recognize the DLL, it kept looking in the \Office10 folder. So I just renamed the copy of the DLL in that folder then copied from \System32 again. That worked like a charm, also the file versions on the DLL were exactly the same that Mike Spross posted.

回复收藏 0 原文