Does the latest Visual Studio 2005 Security Update cause C runtime library issues when hot fixing customer sites

Question

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.

Cordwainer

Answer 1

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/

Waistline

Thanks your right. After some experiments I had discovered this too but forgot to answer the question. – Cordwainer

Answer 2

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.

Raouf

Answer 3

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

Daffi