Always ask the developer before applying a security fix or service pack to Visual Studio that need changed the C++ runtime DLLs ATL/MFC/CRT - by Martin Richter

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


47
0
Sign in
to vote
ID 662511 Comments
Status Closed Workarounds
Type Suggestion Repros 0
Opened 4/17/2011 1:25:51 AM
Access Restriction Public

Description

Some security fixes and all service packs to Visual Studio changed the code base and the libraries. New runtime DLLs for MFC and CRT were introduced.
The problem is that the developer doesn't recognize this, but it will affect the complete build of all his components. Otherwise his software might not work as expected.
And this might be against his will! The impact on the complete distribution of his software is large.

The change of the import libraries isn't detected by the build system a full rebuild is not triggered for all components (static libs etc.). As a result, program files with multiple manifest entries for the CRT/MFC are created for VS-2005 and VS-2008.

As a further impact: There are third party libraries from other companies. Maybe they are not available soon for the CRT/MFC of  this specific security fix. As a result they also cause multiple manifest entries to be created.
(This is also caused by the fact that the usage of _MFC_NOFORCE_MANIFEST, _ATL_NOFORCE_MANIFEST and _CRT_NOFORCE_MANIFEST was never documented. Third party libs should always be created with this defines set VS-2005, VS-2008)
Also if the developer does not roll out the new VCRedist component the newly created software may not run, because the runtimes with this new version are not found.

The impacts of such a security fix in VS-2010 are less critical because there a no longer manifests for it (Hallelujah!). But there is still no guaranty that that software build with the new code from the security fix, will run with the old runtimes. Again: At least for VS-2005/2008 this doesn’t work), and it is still true that running a program build with a higher SP than the installed runtime version might not work, or cause problems.
Another reason:
- The developer builds and ships his software with A.EXE and B.DLL linking statically or dynamic to the CRT/MFC/ATL.
- Now a security fix is installed (usually the developer isn’t informed about that!!!)
- Now he builds a new revision of B.DLL as a fix and just wants to roll out this single file.
- There is no guaranty that this will work. And for dynamic linking to VS-2005 and VS-2008 this may fail and causes extreme problems, because the target machine of the user isn’t prepared for this.

So the developer needs a method to “freeze” his development tools so that he can control how his software is build!
But even here installation of a new security fix doesn't trigger a full build for all components (the import libs are not checked in the build system, and they are published with an older date of some build-target that a developer has on his machine).
If installed they have to force a new build so that the security fix will be linked into the targets in case of static linkage to CRT and MFC.
Otherwise this is useless at all.
I.E. I have EXE files that didn't change since month, but are part of my setup. Some linked statically to CRT/MFC. Result: They didn't contain the fix even installed on my machine.

The impact of such a security fix to a complete build environment is so large that this should never happen without the knowledge and will of the developer.

And I don't want to think about a developer team, which might use different patched Versions of VS.
So from my point of view it is an error and a large problem for developer that security fixes are installed without asking him!

Resolution:
I miss documentation about the impact of such security fixes and how a developer has to care about this.
At least such a security fix should display a warning message box.
Or this fixes should only be installed on demand of the developer.
The developer needs a method to freeze is development tools to s specific version of the CRT/MFC/ATL.
Sign in to post a comment.
Posted by Raman [MSFT] on 12/11/2012 at 4:00 PM
Thanks for your feedback. The future model of servicing VS has changed to follow a regular cadence of Updates. In case of critical security updates however, especially if the VS installed components (such as CRT) are also used by other installed software, it becomes necessary to apply the fix. We will look into how we provide greater education around such issues in future. However, at this stage we are unable to make changes into the deployment process.

Thank you
Visual C++ Team
Posted by Raman [MSFT] on 12/11/2012 at 3:59 PM
Thanks for your feedback. The future model of servicing VS has changed to follow a regular cadence of Updates. In case of critical security updates however, especially if the VS installed components (such as CRT) are also used by other installed software, it becomes necessary to apply the fix. We will look into how we provide greater education around such issues in future. However, at this stage we are unable to make changes into the deployment process.

Thank you
Visual C++ Team
Posted by Raman [MSFT] on 12/11/2012 at 3:59 PM
Thanks for your feedback. The future model of servicing VS has changed to follow a regular cadence of Updates. In case of critical security updates however, especially if the VS installed components (such as CRT) are also used by other installed software, it becomes necessary to apply the fix. We will look into how we provide greater education around such issues in future. However, at this stage we are unable to make changes into the deployment process.

Thank you
Visual C++ Team
Posted by Frank Rast on 5/10/2011 at 7:05 AM
It is indeed the case that our company was forced to focus on fixing issues because of the automatic update of the CRT. I vote to leave the decision to the developer when to update. I know it is not recommended to deliver the CRT with the application, but it should be a supported scenario. When libraries compiled with a previous version of the CRT are linked in then the manifest refer to mixed CRTs. In this case the application will not start on a clean system (ie. without side-by-side CRT installed).
Posted by Ted_ on 4/27/2011 at 6:47 PM
To me there's no appreciation or understanding on Microsoft's part, about this issue (at the management level, so therefore the implementors/programmers don't care about it either since they don't understand it) - I see that the same thing that happened in July/August of 2009 with KB971090 (even after the negative feedback) was repeated for these latest round of security updates.

However, in the latest case there was no user education about the security update like there was back in July/August 2009 (detailed video on Channel 9 explaining the impact and need for the update). In this case there was limited info about the impact on developers/end users so nobody understood why it was required. When such a hidden (background) tools and/or redist update is done there at least needs to be major info on what it impacts at both the tools and redist levels (for both developers and end users), especially when it's rushed out and shipped with bugs that bring down servers.
Posted by Scott McPhillips on 4/20/2011 at 10:48 AM
Martin's suggestion is extremely important and vital to prevent invisible disruption of development projects. (1) Make it visible and be informative. (2) Make the timing of such updates controllable by developers.
Posted by David Lowndes on 4/20/2011 at 9:32 AM
Of course, to make the decision on whether to install or not, we'd need sufficient quality information on what an update did.
Posted by Microsoft on 4/17/2011 at 2:15 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)