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?
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
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.
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.
It does not seem like a good idea to me to have extra copies that windows does not know about (How will it get updated?)
Why can't you call LoadLibrary("usp10.dll") yourself as the first thing you do at startup?
Related
I'm writing a 32-bit C++ application on Windows 8.1 x64 using Visual Studio 2013 that depends on Python 3.3 and libVLC. I have python33.dll, libvlc.dll, and libvlccore.dll in the same directory as my executable, which I also have set as the working directory under Project > Properties > Debugging. According to MSDN, unless you're using the altered search path (which should only apply if you're using LoadLibraryEx to load the DLLs at run-time; in my case these DLLs are loaded at load-time), the application directory should always be searched before the system directory. However, according to Visual Studio, all three of these DLLs are being loaded from C:\Windows\SysWOW64. This is causing me problems as the version of libVLC I have there is much older than the one I'm trying to use.
That MSDN article only lists 3 exceptions to the normal search process. These DLLs are loaded as soon as the process starts, so obviously it couldn't be the system versions were already loaded (but just to be sure, I created a .local file since it mentioned redirection would override that, and it had no effect). I've checked the registry to see that they didn't somehow get registered as "Known DLLs", so that doesn't appear to be the problem. It's possible that python33 is being loaded as a dependency of Boost.Python, but even if it's loaded only by name the app directory should still be searched first, and in any case none of my other dependencies reference VLC. As a guess I tried marking the VLC libs as delay-load (I couldn't with Python due to data imports), and I got the following warnings, which I found interesting:
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
However, dumpbin shows that my compiled exe imports several functions from libvlc.dll.
I could of course replace or delete the system versions, but that's not really a solution if I ever attempt to distribute this application. I'm not really sure what else would be causing this. Can anyone suggest anywhere else for me to look?
I've created a word add-in, which uses one of my DLL's. The application works fine when I'm running it in Visual Studio (both debug or release mode), however when I try starting Word on it's own (and the add-in is still present) and then proceed to trigger a method which loads the DLL, I get a DLL error as shown in the picture below. I'm quiet certain that the problem is not related to x86/x64 compatibility issues as I've set the platform target to x86 for all projects. (The version of Word used for testing is also 32-bit). Any ideas as to what the problem might be will be greatly appreciated, thanks in advance!
So after a day of Googling, I found my solution. It turns out that Word (and Office programs in general) moves your dll's into separate temporary directories - found in:
$User\AppData\Local\assembly\dl3
My dll depended on other resources in the same directory, but because it was being moved separately into this temporary directory then the dll could not be loaded. To get around this, I loaded the dll manually from the directory that it was installed in using:
System.Reflection.Assembly.LoadFile(string path)
You can get the directory that it was installed in with these lines of code:
System.Reflection.Assembly assemblyInfo = System.Reflection.Assembly.GetExecutingAssembly();
//Location is where the assembly is run from
string assemblyLocation = assemblyInfo.Location;
//CodeBase is the location of the ClickOnce deployment files
Uri uriCodeBase = new Uri(assemblyInfo.CodeBase);
string ClickOnceLocation = Path.GetDirectoryName(uriCodeBase.LocalPath.ToString());
Let's say I have this at the top of a module:
Public Declare Function getCustomerDetails Lib "CustomerFunctions" () As Long
If I am running the program from the VB6 IDE, where should CustomerFunctions.dll be located?
If I am running the program executable, where should CustomerFunctions.dll be located?
When loading a standard DLL (rather than an ActiveX or COM dll), Windows applies the following rules;
If SafeDllSearchMode is turned on:
The Program directory.
The system directory. Either (Windows\System32 or Windows\SysWow64 depending if you are running on 64 bit or not).
The 16-bit system directory (Windows\System).
The Windows directory.
The current directory.
All directories that in the PATH environment variable.
If SafeDllSearchMode is disabled, the search order is as follows:
The Program directory.
The current directory.
The system directory. Either (Windows\System32 or Windows\SysWow64 depending if you are running on 64 bit or not).
The 16-bit system directory (Windows\System).
The Windows directory.
All directories that in the PATH environment variable.
My personal preference (rather than litter the System or Windows directory) is to create a developmentDLLs directory somewhere and add it to the PATH variable. When distributing the application place the DLL in the program's App directory. This way you have the least chance of interferring with other DLL's. For complete information on the loading of the DLL's see the MSDN.
Since this is not an ActiveX DLL, somewhat different rules apply.
When running in the IDE you could place it in either c:\windows\system32 or in the directory from which VB6 is running (e.g. c:\program files\microsoft visual studio...).
When running the program executable outside of VB6, you can place the DLL into either c:\windows\system32 or the application directory.
Keep in mind that I gave you a technical answer (e.g. placing the file into c:\windows\system32), which will work. However, the trend in the last decade has been to isolate the necessary components into the application directory.
I have a simple 32 bit app running. It uses Qt and other libraries. Having figured out manifests, I have a folder containing the app , manifests and dependent DLLs. Running this on the target machine under Windows 7 64 bit straight from a USB stick works. Copying this to a folder on the D:\ drive and it works.
Copying this to a folder under Program files (x86) and I get :
R6034. An application has made an attempt to load the C runtime library incorrectly.
I have a manifest for my executable. I also have the manifest for the msvc*.dll's in the folder as suggested elsewhere in this forum. So, why does this work everywhere except in the place it's supposed to be?
Dependency Walker will help here - run it on your .exe when it's in a working state and when it's not and compare the locations of the C runtime library your app is attempting to use (I believe it should be msvcrt.dll if you're in release, msvcrtd.dll if you're not) and you'll hopefully be able to spot a difference.
I'm not certain where you could go from there - perhaps deploy the correct version of the dll into the same folder as your .exe?
I have a driver which can be installed on Windows (XP/Vista/7). It's accessed via a native C++ DLL that 3rd-party applications link to, and which is also a Winsock Provider (WSP). It used to be installed under System32, but having seen advice not to, I changed it to install under ProgramFiles instead.
Now, the problem is that people are having to either copy it back into System32 or copy it into the application directory whenever they want to use it in their own applications, because Windows won't search the install directory under ProgramFiles when the application tries to load the DLL.
I've been unable to find any Microsoft documentation discussing this issue, so if System32 shouldn't be used then where should shared DLLs be installed?
The Windows side-by-side cache. Backgrounder info is here, technical reference is here.
I haven't seen anybody actually do this yet, other than Microsoft. Quite notable is that MSFT gave up on winsxs deployment for the C/C++ CRT and MFC runtime DLLs for VS2010, it was causing too many problems. They're back in c:\windows\system32. The managed equivalent of this (the GAC) is going strong though. Better tool support, probably.
I'm fairly sure that by a large margin everybody chooses app-local deployment.
Since it's a DLL linked to your driver maybe it's less of an issue, but I'd be wary of trying to share the DLL and would instead try to get all developers of client apps to keep their own version of the dll in their applications folders.
I've had too much fun in DLL Hell to want any more weird bugs because AppX overwrote the DLL with an old version that breaks AppY etc.
Anywhere on the path would work.
If this is only to be used with your set of apps (eg Qt4.dll) then in the root of "c:\program files\my company" would be good, or have a 'shared' folder below that.
If it's to be used by other apps that you don't know about (eg a video codec) then system32 makes sense (you will need admin rights when you install)
Fixed filesystem location
One possibility would be to install them in a sub-directory of Program Files, as already suggested by #Martin Beckett.
Variable filesystem location, fixed entry in Registry
If you don't want to install them at a fixed location, you could also store their location in the Windows Registry. You'd install some keys under HKEY_LOCAL_MACHINE\SOFTWARE that your applications could read to find out where the DLLs are located. Then the DLLs can be loaded at run-time.
P.S.: Preventing orphaned DLLs
You could go one step further and use the Registry, or some other storage (a file, say), to store information about which of your applications uses which of your DLLs. For example:
FooCommon.dll <- FooApp1, FooApp2, FooApp3
FooBar.dll <- FooApp1, FooApp3
FooBaz.dll <- FooApp2, FooApp3
Whenever one of your applications is un-installed, it removes itself from this map. Any uninstaller can then safely delete a DLL that is no longer in use by any application. That method is akin to reference-counting, and the idea is to prevent orphaned DLLs from accumulating on users' filesystem.
Native DLLs can be stored as side-by-side assemblies. See this reference for more information. This is separate from the .NET Global Assembly Cache, but it uses similar concepts. This blog post also has quite a few useful details about how DLLs get resolved as side-by-side assemblies.