Warning - Microsoft updated the VC2005 CRT

[sinbad]

I got bitten by this today and it had me swearing for ages. All of a sudden certain builds I was working on ceased to function on other machines with the typical "The application failed to start because it was configured incorrectly" error, that you can expect when you haven't installed the CRT on the machine in question. I was puzzled because binaries from v1.6.3, released less than a week ago, worked fine on this machine. Everything looked fine in the WinSxS folder as far as I was concerned.

However, while fixing a security bug, this week Microsoft bumped the version of the 2005 CRT to 8.0.50727.4053 instead of 8.0.50727.672, which I picked up yesterday on my dev machine. I didn't realise this had happened, so when I deployed a new build from an OGRE-using application, I suddenly started getting this error when as far as I was concerned the CRT was fine.

The vc_redist.exe's on Microsoft's site currently only cover the 762 version of the CRT, not 4053. The only way to fix this is to re-deploy using Windows Installer against your newly built app, or applying the security update on the machine that has had this run for the 762 version.

This had me cursing for over an hour today, I hope this helps avoid someone else having the same issue.

[Assaf Raman]

I saw that update in the windows auto update, it is too big to download with my Thailand cellular internet connection, but I was thinking that this could be the case, and as it turned out from your post – it is.
Thanks for the update.
I guess the solution for now is to add the new "msvcp80.dll" and "msvcr80.dll" to your setup and bin dir, right?

[xavier]

So, they updated your build environment in such a way that VC8 SP1 now has two different DLLs it will use? How insipid... This means that they also updated the .lib against which your apps link?

[Fish]

This is one of those times when us MinGW users Roll On the Floor Laughing.



-Fish

[jacmoe]

I am glad to be using VC9

That's so typically in your face Microsoft.

Only Symantec is worse, IMO.

[xavier]

This is one of those times when us MinGW users Roll On the Floor Laughing.



-Fish

That's OK, the rest of us using Visual C++, spend the time you spend laughing, actually getting work done. :p

[Assaf Raman]

I was thinking for a while to recompile the CRT so I will have TCMalloc from google-perftools as the memory manager like explained on this page, this can also resolve this type of issue – because I will use my own compiled CRT in the distribution.
Has any of you ever done it?

[xavier]

Never had a need, myself.

Wouldn't it be simpler to implement Ogre (or other API) memory management interfaces to use tcmalloc or dlmalloc, instead of having to futz around with a custom CRT that you have to track and install on all target machines?

[Assaf Raman]

I already have to do it in many cases - so why not swap the memory manager as well?

[sinbad]

So, they updated your build environment in such a way that VC8 SP1 now has two different DLLs it will use? How insipid... This means that they also updated the .lib against which your apps link?

Yep - having investigated, it appears that it only updates the CRT to 4053 on machines that have Visual Studio 2005 installed, on my other machines it only updated it to 3053, which means apps built from VC2005 SP1 with the patch applied don't work on other machines even if they've run Windows Update. Because, as far as I can tell, they haven't updated the vc_redist.exe package yet, the only way to resolve it is to create your own Windows Installer to install the new runtime, say using WiX. I fixed it on my other machines by rebuilding the OGRE Demos installer (ogre/Samples/Common/setup) and running it on the machines, then everything was fine.

For convenience, I built a simple setup routine to install just the runtimes: http://sourceforge.net/projects/ogre/fi ... i/download

I don't blame MS for fixing security issues in the CRT, but for Christ sakes they should tell us when making a change as significant as this. At least with SP1 we were consciously agreeing to change our dev runtimes, not having them changed under our feet with no real notice.

[xavier]

Because, as far as I can tell, they haven't updated the vc_redist.exe package yet, the only way to resolve it is to create your own Windows Installer to install the new runtime, say using WiX.

They never did, IME. It has never worked for me, and I've always had to resort to the workaround you mention. PITA.

At least with SP1 we were consciously agreeing to change our dev runtimes, not having them changed under our feet with no real notice.

Agree 100%. In your investigation, did anyone bitch about this in MS forums? And what was MS's response if so?

[Praetor]

I still bundle the CRT and the manifest with my apps because I a) don't trust the redist and b) don't like making my users download something if I'm not already using an installer. It's been annoying explaining to non-tech users why they have to download something from MS when I've sent them an app in a zip file.

[sinbad]

At least with SP1 we were consciously agreeing to change our dev runtimes, not having them changed under our feet with no real notice.

Agree 100%. In your investigation, did anyone bitch about this in MS forums? And what was MS's response if so?

I haven't, I thought about it but then figured that would just be wasting more of my time

[Assaf Raman]

I just found this : Create projects easily with private MFC, ATL and CRT assemblies

This idea can also solve the issue, right?

[xadhoom]

Interesting solution. Have you been able to successfully launch the demo? I tried like described but still get the SxS errors like the first post describes...

xad

[Assaf Raman]

I will try later today.

[xavier]

Interesting solution. Have you been able to successfully launch the demo? I tried like described but still get the SxS errors like the first post describes...

xad

Same -- tried this ages ago and like the first VC8 SP1 CRT installer, it just doesn't work.

[Assaf Raman]

Release worked for me.
I downloaded the sample project, compiled release config of the solution, copied the dll and manifest files from the other zip to the release dir, double clicked the exe and it runs.

[Assaf Raman]

Here is a depends screenshots.

[xavier]

Could you be more specific? We spent days on this last year and it would have been most excellent if we could have obtained the same results. Unless something has changed with the VC8 CRT DLLs, there is no way you got those results solely following the directions in that link...

[Assaf Raman]

Release worked for me.
I downloaded the sample project, compiled release config of the solution, copied the dll and manifest files from the other zip to the release dir, double clicked the exe and it runs.

Did this work for you? What step doesn't work?

[Assaf Raman]

I think I am seeing what you talk about - it doesn't run on my xp. strange.

[Assaf Raman]

OK, it does work, one file was missing for it to work.
I only copied the following files to the exe path: msvcr80.dll, msvcp80.dll, Microsoft.VC80.CRT.manifest
But the exe didn't run.
I found out that I was missing this file: Microsoft.VC80.MFC.manifest
After adding it - the exe runs.
I don't know why you need an MFC manifest, but it is only 1K in size - so who cares?

[EDIT] I am talking about a new command line app I created to test this, I added the include file to it and didn't use MFC.

[Assaf Raman]

Seems that it only works for me when I use precompiled headers and the include is the first include of the PCH file (StdAfx.h or smiler)

[Assaf Raman]

Sometimes it is hard to add precompiled headers flag to existing projects, you get all sort of strange link errors (even before this include).
I found a way around this - just add an new h file with include to that file, a cpp file with include to the new h file, then set ONLY TO THAT FILE the precompiled headers with the PCH being the new h file. It works.
Do this only if you can't use the precompiled headers flag the normal way.