New VS2015 Update 3 Runtime breaks MFC apps built with VS 2015 Update 2

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.



How do I service the Universal CRT if a bug is encountered?

Recently a serious bug in the Universal CRT was discovered that breaks all MFC apps due to MFC’s use of _sntscanf_s in its DDX_Text routine for doubles.

This raises an interesting point.  The bug is in the Universal CRT.  No longer can you just grab a new vcredist_x86.exe or new runtime DLL and plop it into your app folder (along with an applocal MFC of course) You now have to worry about the fact that this bug is in a system component, ucrtbase.dll.   This is due to the “great refactoring” of the CRT:

So then, how do we service ucrtbase.dll?  Do we just wait for it to show up in Windows Update?  Get the Universal CRT SDK and build a redist?

One possible answer lies here:

Answer is: applocal distribution (in the same folder as your app) They originally prohibited this from applocal distribution, but then change their minds.  This is a problem for apps that have multiple folders.

Note: in order to do this applocal distribution properly, you cannot simply just include ucrtbase.dll.  You have to include a series of 23 other flies, named api-ms-win-core.*.dll, a list of which can be found here.  Ugly, but it works.

But, according to Microsoft, from the second comment on this blog post:

“On Windows 10, the real Universal CRT in the system directory will always be used, even if you have the Universal CRT DLLs included app-locally”

So on Windows 10 how do I fix a bug in ucrtbase.dll?  Do I require a Windows Update to get that serviced?  Seems like it. In other words not possible to ship an app that’s totally self contained and has all bug fixes.

Can we call this DLL Hell 3.0?

Apps created with CRT and MFC vNext (11) cannot be used on Windows XP SP3

I filed a bug relating to no longer being able to target XP when creating a Visual C++ vNext app. I got a reply from a member of the Microsoft libraries team stating this is by design and only Vista and above or Windows Server 2008 SP2 and above can be targeted when creating a vNext application.

Please read the following and vote on it, add comments to it as well. If you believe that being able to create a single binary that can target XP and above, and still have access to the latest compilers, libraries, and headers that vNext provides (i.e. not have to use the “native multi-targeting” feature, then please see below:

KB2465367 – a repeat of the KB971090 roll-out problems?

Today Microsoft released KB2465367, a Microsoft Visual C++ 2005 tools update. See:

KB2465367 download

For those of you that remember the problems that KB971090 caused to developers, I suggest you look at this patch carefully before rolling this out, to see if it affects your particular development environment. To remind you of this, please go and read my blog article about KB971090 at:

NOTE: I’ve confirmed that the exact same technique used to update the VC libraries and DLLs in KB971090 are used in KB2465367 also. That is, the manifest version of your app will be increased to 8.0.50727.5592 (from 8.0.50727.762 which was the original SP1, or 8.0.50727.4053 which was the July 2009 security update). This security update contains the new MFC fixes, as well as the original ATL fixes from July 2009.