July 10, 2016 1 Comment
Update: 07/21/2016: This issue is fixed! As noted on the connect bug in a comment made by James McNelis, “this is fixed by the update to Visual Studio 2015 Update 3 that was made available on July 20, 2016. We would advise all of our developer customers to move forward to this update.”
An earlier commenter noted, “This issue has been fixed by KB3165756 version 14.0.25424.00, released on 07/20/2016. The member m_bIsDragged has been removed from CMFCToolBarButton. The fix contains the new VC Runtime 14.0.24212.0. When you install this on a client machine MFC apps built with VS 2015 Update 2 will run without issues.” The comment further asks when the new runtime would be deployed via Windows Update. James replied that there are no plans to do so.
So if you do deploy apps targeting VS 2015 Update 3, please ensure you use the 14.0.24212 runtime included with this July 20th update. (previous one was 14.0.24210)
How to get this patch? If you’ve already installed Update 3 do not use the Update 3 installer again, it won’t detect that anything needs installing. You must use the patch located here instead:
As noted on the above page, the fix for this issue is included in the July 20th update.
Original blog post (written before the fix was made available):
The following is courtesy of a connect bug that was recently filed.
There is also an MSDN forum thread about this:
Credit for below goes to the original poster, none of this is mine (the text has been copied verbatim from the connect bug). Just passing the info forward to show that binary breaks (due to DLL Hell) still occur after all these years.
When you build an MFC app with Visual Studio 2015 Update 2, which creates a temporary CMFCToolBarButton object on the stack, and run it on a machine with VC Runtime 14.0.24210.0, which comes with VS 2015 Update 3, then the app is broken.
In a Debug build you get this error:
“Run-Time Check Failure #2 – Stack around the variable ‘ToolbarButton’ was corrupted”
In a Release build the reaction depends on what on the stack is overwritten. In my case the app doesn’t start at all.
The problem is caused by the new BOOL member m_bIsDragged in class CMFCToolBarButton.
So memory layout differs between Update 2 and 3. When initializing m_bIsDragged in the constructor, the (stack) memory behind the ToolBarButton is overwritten.
My thoughts: this type of bug is difficult to fix because some people may have already taken a dependency on the new MFC that shipped with VS2015 Update 3. Now what happens if they try to revert this back to the Update 2 header signature for existing apps (i.e. get rid of m_bIsDragged). Now in order to really solve this properly they have to change MFC to be dynamic, somehow. I think they could somehow check, at runtime, what MFC version the app has built with, and do something fancy to avoid this. I don’t think it’s going to be easy though. Or they could sacrifice the few for the many (and just backtrack to Update 2 definition), or just forget this happened and force all apps to upgrade to the new signatures (worst solution).
The fact that this problem still occurs tells me that binary compatibility is not being checked actively. Adding members to MFC headers is a big no-no.
That is kind of scary to me as you could have a critical app that is shipping, that just breaks due to new DLLs having been provided by some other third party, or even Windows Update (for security updates). Again the only way to avoid this is using applocal DLLs, but that kills security and is error prone, and doesn’t do anything for those people that already shipped, expecting MFC to do the right thing between updates.