locked
"Side-by-Side configuration information contains errors" with KB 971090 RRS feed

  • Question

  • I'm running into an issue where the executables built with Visual Studio 2005 & KB971090 fail to run on machines that don't have Visual Studio installed.  I've tried installing the Visual Studio redistributable (both 2005 and 2008) without resolving the issue.  I've ensured that the machine is fully patched.  The target machines are running Windows XP (32 bit).

    The failure I'm seeing is:
     Side-by-Side configuration information contains errors.This application has failed
    Using dependency walker I found the dlls it was reporting as missing on the machine and checked the Windows\WinSxS directory and the paths were there for the versions I found in the redist\x86 directory for the machine the application was built on.  I copied the corresponding dlls to the application's directory and while it resolved event id 59 for the corresponding dlls it didn't resolve the SxS error.

    Uninstalling KB 971090, full rebuild, copy (removing the dlls I copied as well) fixes the issue.

    The full list of updates to VS2005 I used for building the application are:
    KB937061
    KB935225
    KB947315
    KB947738
    KB926601

    Is there a redistributable that includes the necessary dlls?  Is there a bug perhaps in how the manifest is getting generated after this KB is installed?

    Thursday, July 30, 2009 6:45 PM

Answers

All replies

  • How are you deploying VC runtime with your app? Bootstraper or merge modules?

    Please mark the post answered your question as the answer, and mark other helpful posts as helpful.
    Visual C++ MVP
    Thursday, July 30, 2009 8:52 PM
  • I downloaded the latest and greatest vcredist from Microsoft downloads today for 2005 and 2008 and ran it and it was still a problem on the client machine.  I'm not familiar with how to set up either of those so I honestly don't know.  We don't have an install for this as our clients are other members of our team.
    Thursday, July 30, 2009 10:11 PM
  • If you installed the security update, the 9.0.30729.4148 version of vcredist should be in your Windows SDK folder, typically C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\vcredist_x86 and C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\vcredist_x64.

    Please mark the post answered your question as the answer, and mark other helpful posts as helpful.
    Visual C++ MVP
    Thursday, July 30, 2009 10:44 PM
  • Neither of those directories are on my machine.  The closest I have is C:\Program Files\Microsoft SDKs\Windows\v6.0 and it does not have a BootStrapper directory inside it.
    Thursday, July 30, 2009 10:55 PM
  • Sorry, that's for VS2008. For 2005 it is under Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages

    Please mark the post answered your question as the answer, and mark other helpful posts as helpful.
    Visual C++ MVP
    Thursday, July 30, 2009 11:12 PM
  • Hello Brent,

    As KB KB937061 is the security update for Microsoft Visual Studio 2005 Service Pack 1, did you try to install the Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) into the client machine?

    http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en

    As Sheng suggested, you can also install the package from the BootStrapper Packages folder.

    http://msdn.microsoft.com/en-us/ms235291(VS.80).aspx

    Thanks,
    Rong-Chun Zhang
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Friday, July 31, 2009 6:47 AM
  • The best way to solve this problem is to open up your built EXEs and DLLs in a resource editor and take a look at the generated binary manifests.  If there are any manifests that contain references to BOTH 762 and 4053 versions of the CRT, MFC or ATL, then they are wrong.  They need to have references to just one version.  You'll need to see why references are being pulled in to multiple sets of redistributables.   It could be a static library or some other issue.

    Rong-Chun, if installing the tools security update 971090, then there should be no need for the first redistributable you mentioned on the target machine.  The first one you mentioned is the old redistributable (version 762) which was from years ago.  Obviously if installing the tools security update, then your app targets a new version of the redistributables, which is 4053, which is the ones in the bootstrapper packages folder.

    Friday, July 31, 2009 12:20 PM
  • Hi Ted, do you have ideas as to how to trace which static lib is the culprint? I've done a recursive search through all output files (well, *.* on the source directory, anyway) for the 'invalid' assembly version "8.0.50727.762", but no dice. I enabled Verbosity in the Manifest tool in the project properties, but there wasn't any additional output, seemingly.

    *edit*.. wait a sec. I would have to recompile each and every static linked library that static-linked to the old version of the runtime CRT library, don't I?
    Friday, July 31, 2009 1:17 PM
  • I also experienced what sounds like the same problem yesterday after installing KB971090 on our build machine.  C++ DLLs compiled with VS 2005 that had a dependency on MSVCR80 were failing to load on our test machines according to Dependency Walker.  We use InstallShield 2009 to install the redistributables during our application install, but after this update, it seems like they are no longer in synch.

    James
    Friday, July 31, 2009 2:19 PM
  • They won't be.  This security update is unusual, it updates header files.  vc\atlmfc\include\mfcassem.h gets updated, possibly vc\include\crtassem.h.  The change will cause your binaries to contain a manifest with a different version number for the MFC (possibly CRT) libraries.  Your installer probably still installs the old DLLs.  It needs to be updated.

    I don't think MSFT updated the redistributables installer yet.  If you are using it to deploy the libraries on a target machine, you might want to consider uninstalling the update until this is sorted out.  Or switch to your own installer that uses the merge modules.

    Hans Passant.
    • Proposed as answer by JamesKnudson Friday, July 31, 2009 5:35 PM
    Friday, July 31, 2009 4:43 PM
  • *edit*.. wait a sec. I would have to recompile each and every static linked library that static-linked to the old version of the runtime CRT library, don't I?

    Exactly!!! All static libs must be recompiled.  Once you do this keep checking your embedded manifests and make sure only one version is listed.

    But as nobugz said, and I recommend also to uninstall this update for the time being and block it from the list of offered updates on your machines. 
    Friday, July 31, 2009 5:07 PM
  • One other possible solution is to use the define _USE_RTM_VERSION in all stdafx.h files.  But it's got its own set of quirks and problems though unfortunately (like not working well in MFC DLLs), which were only just addressed in 2008 SP1 (_BIND_TO_CURRENT_VCLIBS_VERSION)
    Friday, July 31, 2009 5:15 PM
  • Hello Brent,

    You can also try to install the following Visual C++ runtime on the target machine to see if the issue still happens

    Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update
    http://www.microsoft.com/downloads/details.aspx?familyid=766a6af7-ec73-40ff-b072-9112bab119c2&displaylang=en

    Thanks,
    Rong-Chun Zhang
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, August 3, 2009 9:10 AM
  • There's an updated version of vcredist_x86.exe in KB973544 that correctly installs the 8.0.50727.4053 versions of the vc dependencies.

    My test XP machine required this version to work with my binaries (created with a KB971090 patched VS).

    The vcredist_x86.exe that comes with KB971090 dates to july 12th , the vcredist_x86.exe from KB973544 to july 19th.
    Monday, August 3, 2009 9:12 AM
  • Might as well recompile every library to link dynamically to the runtimes... That would've prevented this issue, right?
    I've uninstalled the patch for the time being.
    Monday, August 3, 2009 1:57 PM
  • They won't be.  This security update is unusual, it updates header files.  vc\atlmfc\include\mfcassem.h gets updated, possibly vc\include\crtassem.h.  The change will cause your binaries to contain a manifest with a different version number for the MFC (possibly CRT) libraries.  Your installer probably still installs the old DLLs.  It needs to be updated.

    I don't think MSFT updated the redistributables installer yet.  If you are using it to deploy the libraries on a target machine, you might want to consider uninstalling the update until this is sorted out.  Or switch to your own installer that uses the merge modules.

    Hans Passant.

    I am having similar issues as reported by OP. To confirm the issues are caused by latest updates, I just want to make sure I uninstall latest updates and then rebuild the code. But I am not sure how can I uninstall these updates. Any ideas?

    Edit: Never mind the questions, I figured how to uninstall and clean it.
    Tuesday, August 4, 2009 9:59 PM

  • Hello Brent,

    I am writing to check the status of the issue on your side. Would you mind letting me know the result of the suggestions? If you have any additional question, welcome to post here.

    Have a great day!

    Thanks,
    Rong-Chun Zhang
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Wednesday, August 5, 2009 3:23 AM
  • Hi to all at MSFT,
    the problem is still open. The security updates for VS2005 SP1 (KB971090) and VC_Redist for VS2005 (KB97392) have incompatible versions of the VC-Redist.

    After installing the security update to VS2005 SP1 the needed redis version for clients is 4053. The security patch patches the VC_Redist of version 762.

    So all clients has to update to 4053 of the redists. In large companies is this a serious problem!

    Will MSFT will provide a solution for this issue?

    A solution might to rollout KB973544 via Microsoft Update.


    Friday, August 7, 2009 4:04 PM
  • Your client doesn't need the redist.  Revision 762 installed on their machine would be automatically updated by Windows Update.  You can get the updated redist for future installations from here...

    Hans Passant.
    Friday, August 7, 2009 5:25 PM
  • No, that is not correct. We have checked this, the windows update doesnt install the redist version 8.0.50727.4053, which is needed to run compiled applications with VS2005 SP1 and security update KB971090.

    The client can run the applications only if you have installed the new redists for VS2005. This is not acceptable.
    Saturday, August 8, 2009 10:51 AM
  • AZ_123 is correct: actually Hans, the revision 762 of MFC/CRT doesn't get updated to 4053 by the Windows Update "end user" (non-developer) update.  Only ATL 763 gets updated automatically by Windows Update for the "end user" security update, i.e. those that do not have Visual Studio installed at all)
     
    If they had updated all 3 in the "end user" update then there would be less issues relating to this update.  At least users would be none the wiser.  Now as it is, all binaries must be updated when an ISV ships an update patch and new redist or MSMs must be included with the ISV update to his customers.

    I agree with AZ_123 that this situation is not acceptable and I'm hoping for a new vcblog post clarifying this for users shortly. 
    Sunday, August 9, 2009 3:40 PM
  • I'll post a blog entry shortly that contains a workaround for this issue.
    Monday, August 10, 2009 12:46 PM
    • Proposed as answer by Dan Korn Friday, August 14, 2009 5:50 PM
    • Marked as answer by Rong-Chun Zhang Wednesday, September 9, 2009 5:56 AM
    Monday, August 10, 2009 8:32 PM
  • That looks good, but I have well over 100 projects built using batch files.  Has anybody heard about when CRT will be updated as part of the End User Update?  This is making us postpone a software release.  I guess that I could try taking our customers into buying Visual Studio and then updating, but I think they will get tense. :)
    Tuesday, August 11, 2009 3:27 PM

  • RobertBr - this should not postpone a release - use the CL environment variable as I suggested, it will take you 95% of the way without any source changes at all.  The annoying thing is that step 3 is only necessary because of a silly bug in VC2005SP1's handling of MFC _USRDLL projects.  If you have a lot of these, then hopefully using a common stdafx.cpp would be practical (as there's not usually that much in a stdafx.cpp file).   You could also replace the dllmodul.obj with a modified one in the actual lib file if that's easier. or include the dllmodul.obj in a common static library of your own, it would be used instead of the one provided by MFC lib folder.

    As KB971090 is a very important security update I can no longer recommend uninstalling it, as the fixes to ATL are crucial if you're affected.  Please see:
    http://blogs.msdn.com/vcblog/archive/2009/08/05/active-template-library-atl-security-updates.aspx
    • Edited by Ted_ Tuesday, August 11, 2009 11:58 PM
    Tuesday, August 11, 2009 3:42 PM
  • So a Windows security update changed the behavior of the linker and broke binary compatibility of the executables that I'm building? Sorry, but that's just wrong. I've been tearing my hair out for the last day and a half trying to figure out why what I built last week from tagged source code under revision control is different than what I built with the same tools on the same machine today. Yes, mea culpa for not noticing that one of the Windows updates in the last batch was an update to Visual Studio itself, but the Microsoft does recommend installing all "high-priority" updates, and it's my standard practice to follow that advice so that I can make sure our executables will work on up-to-date customer machines. At least that was my policy until today. I'll be more careful about this in the future. So, thanks to Ted et al for figuring this out, and a big raspberry to Microsoft for this little surprise, which apparently faked out even its own employees on this forum who didn't know that the standard redistributables longer match what the linker is generating. Anyone know if there are similar dragons lurking in the latest batch of updates (KB960859 et al)?
    Wednesday, August 12, 2009 4:22 PM
  • Ted - I have over 100 projects many of which use the same source code in different compilers.  A common stdafx is not going to fix the problem.  I also do not want to go through and modify all of the projects.  It would take forever and has a decent probability of breaking something...  What I would really like is for MSFT to finish fixing the problem they created with this half-done update.
    Wednesday, August 12, 2009 4:48 PM
  • I'm sorry I haven't been on in some time--we are in alpha at the moment and I haven't had time to evaluate the recommendations.  A quick read regarding the solutions presented excludes recompiling as we link to some libraries produced externally without source.  The only real solution is a vcredist based one and preferably one that gets pushed through windows update.  We could handle it without that but that is a lot of manual labour to update machines instead as a number of internal tools are distributed through source control syncs to internal clients without VS.
    Wednesday, August 12, 2009 8:56 PM
  • I do not speak for Microsoft but this is what I understand to be the official line:
    (1) rebuild everything, including all third party libraries, static libraries, pre-buit DLLs that may use a particular version of the libraries
    (2) ship the new vcredist_x86.exe or MSM files or applocal (choose your preferred deployment)

    This has always been the official line. 

    I also understand this is unacceptable for all the reasons you mentioned.  The circumstances that came together created the perfect storm are as follows:

    1) The fact that the libraries had not changed since December of 2006.   So people were just simply not aware of the impact of this change.  Change something that hasn't changed for 3 years and you're going to upset people, even though it's always been the official line to rebuild and reship new redist.
    2) The fact that nothing was said in the security PR that CRT/MFC was being updated along with ATL. So people were caught off guard
    3) The reliance on manifests (goes without saying)
    4) The fact that VC2005 defaults to using the current version of the libraries in your manifest, with no way to choose (e.g. RTM, SP1, or SP1+security update). Note in VC2008 this is no longer thie case unless _BIND_TO_CURRENT_VCLIBS_VERSION is used. 
    5) The fact that _USE_RTM_VERSION is buggy under VC2005 for the same reasons that I mentioned the workaround in step 3 of my workaround instructions.  One of the Microsoft object files is hard linked to the latest version of the libraries (dllmodul.obj). 

    The way I suggest to avoid the problems relating to point 3 above (modifying your stdafx.cpp file) was a hard one to decide upon.  There may be a more "hands free" way to do this and I've suggested a couple in other posts.

    Note, in VC2008 you don't even need to worry about the bug in point 3 because it was fixed in 2008 SP1.  So with VC2008 you can completely do this targeting with one environment variable.  That's as hands free as you can get and will fit into most automated build processes.
    Wednesday, August 12, 2009 9:47 PM
  • Ted,
    Please explain your last part about VC2008 being able to do this with an environment variable. 
    Thanks Roy
    Friday, August 14, 2009 4:41 PM
  • Hi Roy, with the compiler, they support an environment variable named CL that will add the compile option you specify to any compile you do.   You could set this in your operating system's system properties from control panel, or in a batch file. 

    So for example, based on my instructions at http://tedwvc.wordpress.com you could use a modified version of targetsxs.h for VC2008, i.e.

    #ifndef __midl
    #define _SXS_ASSEMBLY_VERSION "9.0.30729.1"
    #define _CRT_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION
    #define _MFC_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION
    #define _ATL_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION

    #ifdef __cplusplus
    extern "C" {
    #endif
    __declspec(selectany) int _forceCRTManifestCUR;
    __declspec(selectany) int _forceMFCManifestCUR;
    __declspec(selectany) int _forceAtlDllManifestCUR;
    __declspec(selectany) int _forceCRTManifestRTM;
    __declspec(selectany) int _forceMFCManifestRTM;
    __declspec(selectany) int _forceAtlDllManifest;
    #ifdef __cplusplus
    }
    #endif
    #endif

    then use environment variable CL and set it to
    /FIc:\path\targetsxs.h

    where path is the path you put your targetsxs.h file

    Then build and it should change the target to the VC2008 SP1 version

    Friday, August 14, 2009 8:34 PM
  • Thanks much.

    I was not aware of the CL variable.  Since I want to bind to the lastest version, (I distribute them via merge module with my application) it seems that my easiest path is to set CL=/D_BIND_TO_CURRENT_CRT_VERSION#1


    Thanks Roy
    Sunday, August 16, 2009 4:47 PM
  • Hi Ted,
    I've been hit by the same problem (VS 2005).

    re: (2) ship the new vcredist_x86.exe or MSM files or applocal (choose your preferred deployment)
    I am using the merge modules (msm files) to distribute the runtime components but I can't find the relevant merge modules anywhere.  Do you know where they would be on a microsoft site.  (The vcredist_x86 is on my PC but I'd rather not have to redo part of the installation routine to use that instead of the merge modules).

    Thanks,
    Andy
    Monday, August 17, 2009 8:57 AM
  • Our team were previously distributing CRT libraries using private assemblies. This method, with version 4053 seems no longer available. The resulting binary comes up with the following error message at run time. The run-time message goes away and the application runs after I run x86_vcredist.exe (and WinSxS/... is populated).  Our team would rather not require vcredist.exe to run.

    Is there still an option for private assemblies?

    The application failed to initialize properly (0xc0150002)
    • Edited by macetw Monday, August 17, 2009 12:52 PM
    Monday, August 17, 2009 12:37 PM
  • macetw, private assemblies should still work fine with the updated security versions (4053).  Just make sure you update your private assemblies and manifest files to the 4053 versions.  And make sure you don't have mixed versions in your manifests embedded in your built binaries (search all your *.intermediate.manifest and make sure only 4053 is listed).  Or of course you just need to use the workaround of changing the manifests to use the 762 versions (link to blog page above)
    Monday, August 17, 2009 3:51 PM
  • Hi guys,

    I faced the same issue on my Windows Server 2008 machine.
    I tried the manual windows update and it installed couple of security updates.but it did not solve the issue.
    This time i changed the "Windows Update" and "Windows Installer" services "Startup type" to "Automatic(Delayed Start)" and restarted my machine.
    This solved the problem.

    Hope this information helps you.

    Thanks
    Appala Naidu Uppada
    Friday, November 13, 2009 11:20 AM
  • Wednesday, April 13, 2011 11:59 AM
  • I have two questions on the subject, hope you guys can help.

    1) When I look at the manifest for my dll it shows that it has dependencies on two versions of the same assembly. Is there a good explanation to this and how can I fix that? I don't want to have to redistribute two run time libraries. I used Dependency Walker to see if there are in fact dependencies on two different version of the assemblies but I can find only dependices on one.

     

    2) Am I allowed to redistribute run time libraries and re-distributable packages (is there no copyright infrignment)?

     

    Thanks for the previous posts.


    Friday, June 24, 2011 4:28 AM