We include a 3rd Party lib+DLL that recently causes a lot of trouble on installations. Using dependencywalker, we found that the dll itself refers to two different Versions of
MSVCR80.DLL:
Version 8.0.50727.4053 and
Version 8.0.50727.42
alt text http://img101.imageshack.us/img101/1734/dependencywalk2.jpg
In MOST cases installation makes no problems, even if we distribute none of both versions. But in a number of cases our installation just does not start. We then find messages in the windows system event log from the SideBySide manger: "Version of DLL does not match". In most cases again this problem can be resolved, by installing the .NET framework (although we do not use this). But now we have a case where this does not help.
I know that a solution would be, to install both versions as a shared assembly, but that seems not to be easy, and besides that i would prefer a much simpler solution. Does anybody know a workaround?
Can i somehow use only one version of the Dll?
EDIT:
I now tried cristians advice:
D:\Develop\LEADTOOLS15\patch_maifest>mt.exe -inputresource:ltkrn15u.dll;#1 -out:old.manifest
Microsoft (R) Manifest Tool version 5.2.3790.2075
Copyright (c) Microsoft Corporation 2005.
All rights reserved.
mt.exe : general error c101008c: Failed to read the manifest from the resource of file "ltkrn15u.dll". Ressource not found.
If i view the dlls dependencies with full paths, i see the following:
alt text http://img340.imageshack.us/img340/4122/dependencywalk3.jpg
The lower MSVCR80.DLL is the one withe Version ...42. I dont understand this. Why does MSVCP80.DLL refer to a different Version of MSVCR80.DLL than the one besides it. Is that maybe a problem of the dependencywalker ?
Your best option is to ship the needed DLLs within your applications installer package. Use at least the version that your 3rd party DLL depends on.
Microsoft offers standalone installers for its runtime DLLs (vcredits_*). The latest version for VisualStudio 2005 can be downloaded here. That is also the version that your DLL is linked against. You can silently launch the redistributable package from your installer.
As a manual workaround for already installed systems, simply apply the redist installer on the target machine.
If you choose this method, you don't need to be afraid of version conflicts, as applications depending on an older versions will be redirected to always use the most recent one.
For a better understanding you have look at this MSDN articles.
You have to change / update the manifest resource from the dlls.
mt.exe -inputresource:dll_with_manifest.dll;#1 -out:old.manifest
mt.exe -manifest new.manifest -outputresource:dll_with_manfiest.dll;#1
Sometimes the RT_MANIFEST (type 24) resource type doesn't have the #1 index in resource table, you should use a Resource Viewer (ResourceHacker, or ResEdit) and find out the index number. I have seen cases when the manifest has the #2 index number.
Related
My application relies on DBGHELP.DLL functions, especially the information about the loaded DLLs by the target processes. However, many times it fails on Windows versions lower to Vista (you know XP is still there!). Looked around and found that installed/present DBGHELP.DLL on the target system is old, and doesn't support many new features (For example, few flags of MiniDumpWriteDump are not supported in older versions).
This page mentions about the DbgHelp versions and vaguely mentions about distributing the DBGHELP.DLL (and other DLLs). DLLs shipped with OS must not be shipped (agreed, and no issues about it). Then it says latest DLL out of "Debugging Tools For Windows" should be shipped.
My question is: Which version can be/should be shipped with the application? Pick the latest one and assume it will work in lowest OS (XP)? Of course, I won't ship Debug version of this DLL. The "DbgHelp versions" page doesn't mention about supportability for specific OSes - so we may assume that even latest version will be supported on XP.
I would put the DLL in the application directory itself, and may conditionally call functions like SetDllDirectory. If needed, the DLL itself and/or any functions of DBGHELP.DLL may be loaded dynamically.
Related:
SymInitialize failed with error 2147483661
https://groups.google.com/forum/#!topic/microsoft.public.windbg/9V6sbsu8_js
One of the missing file error occurs as the file is deleted or corrupted. There is a different approach to its fix on the different windows versions. If you certainly need to fix dbghelp.dll missing error you need to install Microsoft Direct X follow the step-by-step method from installation of it.
We are facing an issue at the customer site; the Customer has built his application using VS2010 Runtime dated 19th Feb 2011 and version 10.0.40219.1
The customer’s app uses our dll, which is also built using the VS2010 Runtime but slightly older version.
We have an option in out installer where you can skip the installation of VC Runtime re-distributable, here the customer would have skipped as he already has the runtime installed.
The problem here is if the customer’s app starts first and then loads our DLL, then there is no issue. but in another scenario if the customer’s App loads only msvcr100.dll and does not load msvcp100.dll
And then later when our dll is loaded , then we get an error “R6030 CRT Not initialized”
Is this because of runtime incompatibility issue, should the runtime and the application be compiled with exact same version ?
Yes! I would recommend that you program is always delivered with the CRT you build with.
But I wonder about this. Internally the newer DLLs are binary compatible with the previous build. So because you build with the older version, the newer version "shouldn't" break you application.
I always avoid this problem in using a local installation for the VC Runtimes.
I don't know the cause exactly, but I found that the R6030 runtime error can be resolved by changing Microsoft IME 2010 to Microsoft standard IME in some computer. It may be related to Microsoft office 2010. Also, please uncheck "image protect service" at windows - start - msconfig - service tab.
Refer the following screenshots. Sorry for that the language in the screenshots is Korean.
Microsoft IME change
Image Protect Service
I've been looking online and at my registry and I think not, but it would be nice if we could get a definitive answer on here.
Just the run time, as in for re-use on the client side.
I see it is possible for VC10, http://blogs.msdn.com/b/astebner/archive/2010/05/05/10008146.aspx, but prior to that we need to call the MsiQueryProductState API. Perhaps just give all the clients MSVCR100.DLL already?
The most common practice is to install the CRT your application was built with, regardless.
I think this practice comes from the v90 and lower CRTs, because there were multiple versions of each redistributable that could be installed, and though MSVCR90.DLL exists on the system, it may not be the version your application uses.
I believe this was changed with the v100 CRT, and now Microsoft guarantees that newer versions of the CRT will be usable in place of an older version, but I would still attempt to install the CRT your application was linked with.
It is still possible to do a private install of the Dll's into the application's folder. I recently installed 3 different version of the VC9 runtime when I was setting up my Visual Studio Express environments. All show up in Control Panel and appear to be readily removable.
For that reason I believe the current best practise to be to perform a private install (I think that is the terminolgy MS uses) of the required DLL's (for managed code you need the managed DLL and the native version) in tha app's folder.
I'm using Visual Studio 2008 for C++. When compiling, Visual Studio compiles against the header files of the VC 9.0 libraries. However, there are different versions of this library available:
v9.0.21022.8 (= RTM)
v9.0.30729.17 (= SP1)
v9.0.30729.4148 (= SP1 with security update)
I'd like to know whether it is possible to tell Visual Studio which version it should compile against.
The reason I think this is important is because the application's installer needs to make sure that the correct version of the Microsoft Visual C++ 2008 Redistributable Package is installed. To me it feels like I don't have any control over this dependency, as apparently some Windows Update (not a Visual Studio update) can change this dependency. I'd like to keep using the same version to avoid the overhead of making the installer upgrading the Redistributable Package.
Note that this situation is different from my earlier question, as that one was about link time. Neither am I looking for a way to control the version that is put in the embedded manifest file, as that is explained here.
The manifest that's included with your binaries is automatically generated by the VS build system. Important headers that determine the version dependency that's emitted into the manifest are vc\include\crtassem.h and crtdefs.h. The former declares the CRT version. Note that it already has support for the RTM version vs the "latest" version with the _BIND_TO_CURRENT_CRT_VERSION macro. The latter contains #pragma comment directives to embed the /manifestdependency linker option into the .obj file, which in turn makes the linker auto-generate the manifest.
You don't have to do it this way, you can simply turn off the linker options that generate the manifest and write your own. That gives you complete control over the CRT version that your app binds to. Whether you are ahead with this is a bit questionable. You would probably still be shipping the old version of the CRT that got updated in July of last year, it contained a critical security bug. Customers tend to be a bit unhappy about getting software installed on their machine that has well documented and solved security flaws.
The next thing you'd have to do is take control of the deployment of the DLLs. You'll have to deploy the DLLs into the WinSxS side-by-side cache yourself.
That will work, if you figure out how, but it isn't likely to survive for very long. Windows Update, if enabled, may discover that the machine is using an unpatched version of the DLLs and will update it. And deploy a publisher policy to redirect load requests. It is likely that your machine has such a policy file in place if you see your manifested version request resulting in the load of another version. The somewhat unescapable conclusion is that this is MSFT's DLL and they'll do with it what they think is necessary. Look at applocal deployment to avoid this.
It's this just a question of which directory your configuration is set to build against. As long as you have all the versions of headers on your machine and the libraries they link against I don't see why this can't be a new configuration for each version.
If the issue is things like SP1, there's not much you can do. Microsoft considers the runtime, in effect, a component of the operating system. It therefore gets updates and patches the same as any OS component.
There shouldn't be a problem with this, normally - the patches are bugfixes and security updates after all. In principle, each change should make your apps more stable. Not quite always true, but in any case there isn't much you can do about it.
There are options to change the runtime, but they are related to thread-safety and similar issues. There's a few relevant places in the project properties. In particular, in the C/C++/Code Generation tab you can select which run-time library to use.
If you are seriously worried, you can choose a statically linked non-DLL runtime. Users can still update their runtime DLL, but it won't improve the stability of your app when they do so.
You can do this using manifest resource files, which are written in XML.
We had to do this at a previous place of employment, unfortunately (or perhaps, more fortunately), I was not exposed to the in depth details of how it was done. This article looks about the closest to what we did that I could find on the subject.
Update0
Here is MSDN documentation regarding manifest file generation, and their use in isolating applications and building side by side assemblies.
As you might be aware an update to visual studio 2005 was auto updated on most machines last week. This update included a new version of the visual c runtime library. As a result any binaries built after the update also require a new redistributable installed on client systems.
See http://support.microsoft.com/kb/971090/
And here is the installer for the new redistributable:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=766a6af7-ec73-40ff-b072-9112bab119c2
This is fine for distributing new binaries to customers, I will ship the new redistributable with the installer and it will all work.
However I am really worried about my ability to hotfix existing customer sites if they discover a bug. In this case normally I would just send the dll or exe that was fixed.
However if I do this now, I will have to send these customers the new redistributable and now I will be using two different versions of the c runtime library in the same executable.
Is this a problem?
Can this cause my application to crash?
What happens if I allocate memory in one dll then deallocate it in another? Normally this works if the same release runtime library is used. I went through the our code about 3 years ago cleaning this up, but I cannot be sure that I have found and fixed all occurrences.
Is the allocate/deallocate in different dlls still a problem? Now that in the era of smart pointers etc it is very had to enforce this.
Can I control what runtime library version I depend on by changing manifests?
Any pointers or advice would be grateful.
Updated: I have just noticed this question
VC++: KB971090 and selecting Visual C Runtime DLL dependencies This is very similar, but my question is more concerned with using two different version of the runtime in one executable.
The version number specified in the application’s manifest file/resource only specifies the minimum version required to run the application. The default behavior of the loader is to first check the WINDOWS\WinSxS folder for the identical version or a superseding version of a dependency identified in an application manifest, and to use that version regardless of whether or not a private assembly containing the dependency has been provided with the application. (See http://msdn.microsoft.com/en-us/library/aa375674(VS.85).aspx).
So chances are your old binaries will also use the latest version of the Microsoft run time library anyway. Try to run the release build of your application (built before you update your Visual Studio) on a fully patched machine and use process explorer to see which DLLs it loads. The only problem is you will have to include the new run time redistributable file in your patch.
If you are still worried, you can try the method described here: http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/
Yes you will not have to wait too much to see the problems using two runtime libraries.
If you allocate memory with a runtime and try to release it with another, your application will crash. It is and will continue being a problem.
Only the runtime what reserved the memory can track it. It is imposible for the other runtime to know how much memory you reserved.
You may want to read this, is a really good post about linking with msvcrt.dll.
I have heard (only by rumour) that if the manifest gives two versions of the CRT that only differ by minor revision number, then the application ends up only using the newer version at runtime. Ie, you do not run into problems with with multiple CRTs.
This is only rumour, and I'd love to hear a concrete answer on this.
See also: Visual Studio 2005 security updates and CRT DLL versions in manifest