On Tuesday 28 July we released guidance and updates to assist developers using our Active Template Library (ATL) to prevent creating controls or components with potential security vulnerabilities. Vulnerabilities in libraries are a rare, but industry wide issue, that requires broad collaboration and action by the community at large to effectively resolve.
Developers who have built controls using the ATL should take immediate action to review their control to identify if it is vulnerable and take appropriate action to rebuild their control using the updated ATL library and distribute a non-vulnerable version of their control to their customers.
If you develop any controls with ATL then please take a look at the guidance on MSDN detailing the steps required to identify and address affected controls. Also, we cover the issue in a Channel9 video.
So George and I had a look at this again today and wondered if your deployment scenario hits one of these configurations (or a variant thereof):
You are using AppLocal deployment of the CRT and there are no installations of the CRT in WinSxS (for example on a clean machine.)
App.exe manifest references CRT V9.0.1
Abc.dll manifest references CRT V9.0.2
In this scenario the question is which version of the CRT can be deployed AppLocal? The solution here is to use a config file for the files with the lower versions to redirect to the newer version (config file causes app.exe to be redirected to CRTV9.0.2)
You are using WinSxS deployment of the CRT via payload MSMs (these have the actual dlls) without the policy redirection MSMs (these are the redirection xml config files) – these are separate files.
In this scenario the question is which version of the CRT can be deployed to the WinSxS? The solutions here are 1) install the later version of the MSMs along with their corresponding redirection MSMs or 2) to install both versions of the CRT via the two payload MSMs (not preferred - be careful as you end up with two versions of the CRT loaded in your process.)
Of course you may not be using AppLocal or MSMs. George and I would be happy to have a call with you on this. You can email me at my_first_name at Microsoft dot com and we can set up a time.
Just wanted to note that I've been hit too.
-Build a setup some days ago and customer installed it on his machine.
-Customer reported a bug, which could be easily fixed.
-Installed the critical update.
-Fixed the bug just recompiled the specific DLL and told the customer that he can just replace the DLL and doesn't need to do the setup again, since our setup requires rebeoot
Looking and trying to find the cause.
looking, looking, looking ...
Since I'm sort of old school guy I opened the old and the new version of the dll in hexviewer and saw they are referencing different CRT versions!
Please don't change my headers/lib behind my back without telling me.