How to get Visual C++ 2012 Update 2 statically linked applications to run on Windows XP
April 14, 2013 33 Comments
EDIT (June 26, 2013) – Microsoft has released the final version of Visual Studio 2012 Update 3 that completely fixes this issue. For more information on Update 3, please click here.
EDIT (May 11, 2013) – Microsoft has released an RC of Visual Studio 2012 Update 3 that fixes this issue which is “go live”, meaning if you can’t wait for the final Update 3 and need a Microsoft supported solution immediately, you can use it with production releases. For more info look here and to download look here. For a solution to use with Update 2, see below.
Due to a regression in Visual C++ 2012 Update 2, applications using ATL will no longer be able to run on XP, even if using built-in XP targeting support. This is due to a new dependency on InitializeCriticalSectionEx. Running an app on XP that was built with Visual C++ 2012 Update 2 will give you the following error message:
Entry Point Not Found
The procedure entry point InitializeCriticalSectionEx could not be located in the dynamic link library KERNEL32.dll
To fix this, I’ve published a new version of the xpsupport tool, namely XPSupport for VC11 Update 2 Version 1.02, on my skydrive. It simply wraps the InitializeCriticalSectionEx function with an XP compatible replacement, using techniques I’ve used in previous blog entries.
To use this solution, simply add build customizations (masm) to your project by right clicking on the project in solution explorer and choosing “build customizations” and check masm (targets, props) on, then add the three files (xpatl.cpp, xpatlwrap.asm, and xpatlwrap64.asm) contained in the zip file named: xpsupportvc11upd2v102.zip found here:
https://skydrive.live.com/redir?resid=1B361BF333E9AB82!153&authkey=!AEAOQJ4-LCqWQiw
Build your app, and now your app will run under XP.
EDIT: despite the title of this blog post, I received reports that this works also for dynamically linked apps (i.e. linking to MFC and the CRT dynamically)
More info about the cause found here:
credits to VSBs and others for reporting and researching this issue.
changelog:
1.00 2013-04-14 Initial Release
1.01 2013-04-15 added x64 support
1.02 2013-04-17 cleaned up Vista check
About tedwvc
Ted's Blog 
Thanks for the files; on inspection, these appear to be for 32-bit builds (or at least the asm code does not do anything for 64-bit). Is there a similar thing to do for x64, or am I missing something?
You’re right – for XP x64 and Windows Server 2003 x64 I didn’t publish the ASM, but will do so since you asked for it.
Hi Greg – I updated the article and uploaded the skydrive with the new version that contains the x64 asm file. Feel free to add all three files to the project since the asm files automatically include/exclude themselves from the appropriate builds at build time.
Pingback: How to get Visual C++ 2012 (VC 11 Beta) statically linked CRT and MFC applications to run on Windows XP | Ted's Blog
Many thanks. I will try this tomorrow and let you know how it goes. I’m using dynamic links for MFC but hit the problem due to using the CImage library, which links to some of the ATL static libs.
Lifesaver! Microsoft may not have completely forgot their older operating systems but they should have a few VMs running to test their updates.
Great work Ted, saved me a lot of headaches!
I have now checked this for an MFC DLL app that used ATL via CImage and it works in both x64 and x86 versions. Thank you.
On a separate issue, while perusing your blog via Chrome on an Android Tablet, the Follow pop-up obscures a large proportion of the screen and doesn;t seem to want to go away if you do not choose to Follow…
Hi Greg, thanks for confirming this works with dynamically linked apps also.
I turned off the “follow” button from the page (but it only allows me to turn it off for “logged off users”). Hopefully this will solve the problem, thanks for making me aware of it.
Thank you for this fix! I’m getting following exception: Run-Time Check Failure #1 – A cast to a smaller data type has caused a loss of data. If this was intentional, you should mask the source of the cast with the appropriate bitmask. For example: char c = (i & 0xFF);
Changing the code in this way will not affect the quality of the resulting optimized.
Fix: use DWORD instead of BYTE cast:
if ((DWORD)::GetVersion() >= 6) { // Vista or higher
another option is disabling runtime checks:
#pragma runtime_checks(“”, off)
…
#pragma runtime_checks(“”, restore)
I just realized the (BYTE) cast is needed there. Correct fix:
if ((BYTE)(::GetVersion() & 0xff) >= 6) { // Vista or higher
I’m sorry for confusion.
Thank you for the report and suggested solution – I will clean this up in the next release.
Thanks so much, Ted.
Thank you, Thank you, Thank you!
Thank you you saved me! I upgraded to VS 2012 and would have had to roll back to 2010 without this fix.
Is this not the job of those at MS? How can it break, if not on purpose?. Should you better leave it alone?
Not sure if serious…
Good point – it’s definitely the job of Microsoft but it was working In Update 1 but broken in Update 2. It was broken probably because of a mistake, not purposely. If we leave it alone we cannot work with Update 2, so something must be done while waiting for an official fix fro Microsoft. It was filed as a bug on connect many times already and they acknowledged the problem – see:
https://connect.microsoft.com/VisualStudio/SearchResults.aspx?SearchQuery=InitializeCriticalSectionEx
Just for reference, here ist the direct link to update 1 (all official MS links now redirect to update 2):
http://download.microsoft.com/download/8/A/5/8A5083CE-CD1C-4294-B094-A6CF8F95AD94/vsupdate_KB2707250.exe
Since I don’t like hacks and have no requirement for update 2, I will simply skip it. There is already update 3 CTP available, so it shouldn’t take long till update 3 gets released officially.
Thank you.
Since the development period given to us was short, it was saved very much.
I had the same issue and the workaround saved also my life. I add my compliments and thanks to the others’ : I avoided a very big headache..
I just add a note that may be useful for people not used to embed MASM files in the solution (like me :) ) : after adding the .asm files to the project, I had to right-click on them and specify that they were microsoft macro assembler files, in order to have a good result : by default, Visualstudio was excluding them from the build, so there was no good result even if, apparently, the solution was building without errors.
Thank you again very much !!
Thanks, it’s great to hear the solution helped. I’ve had the same issue as you had, it just ignored the asm file, then I finally realized, it was only if I didn’t do the step of right clicking on the project file (not the solution) and choosing build customizations, and checking “masm (targets, props)” before adding any ASM files. The key was that this step needs to be done BEFORE adding any ASM files to your project. If you add the ASM files before doing the step, then it will ignore your build customizations, and you can do your workaround instead.
Another workaround is to replace the atlsXXX.lib’s with the lib’s from update 1.
Just a note to say that I have installed Update 3 RC 1 and it seems to have fixed the XP problems for a build that uses MFC in a DLL and the CImage object, which links to the ATL library. This works in both x86 and x64. Note that there is a new mfc110.dll file.
Nothing extra seems to have been broken.
Thanks to Ted for the work-around while we waited…
Hi Greg, thanks for confirming,
Hi Ted,
I’m encountering this problem (not a valid win32 application when running on XP) for something I’m compiling with VS2012 Update 3. Any way to find out what exactly is the trigger for this?
Thanks
Did you choose the correct platform toolset in project properties? It has to be set to: Visual Studio 2012 – Windows XP (v110_xp)
Also there is a bug where sometimes in project properties – linker – system – minimum required version is blank and not set properly. It should be set to 5.01 (automatically by setting the platform toolset) but if it is still blank put 5.01 in there.
Hi Ted,
Thanks for the answer. Meanwhile we were in a tight spot, so we reverted to VS2008 for the components that were exhibiting the issue. We think it’s related to external libraries we’re linking to and for which we don’t know how they were compiled.
Thanks again.
Amit
Pingback: vs2012编译xp运行的mfc程序InitializeCriticalSectionEx解决方案 - 浊酒的博客
Hi, Ted,
I’ve got Visual C++ 2012 Update 4 but still have the “Entry Point Not Found” error. Could it be something that Update 3 fixed but broken by Update 4? I applied your workaround and it worked for Update 4.
Thanks.
BTW, I checked both “platform toolset” and “linker – system – minimum required version” in project properties and they all set correctly. But I still have this error unless I apply your workaround.
Interesting, it’s the first I’ve heard of it. Are you sure you haven’t inadvertently added your own direct call to InitializeCriticalSectionEx?
I am pretty sure. The same code runs on XP when build from VS2010. Also, there seems to be an work item about this update 4 problem from Microsoft Connect.
http://connect.microsoft.com/VisualStudio/feedback/details/814247/vs2012-4-v110-xp-broken-the-procedure-entry-point-initializecriticalsectionex-could-not-be-located-in-the-dynamic-link-library-kernel32-dll
Read the work item from Microsoft Connect again and found that the problem is caused by DLL compiled without XP Platformtoolset. I’ve got the same situation. Need to recompile the DLL again. Sorry for the confusion.
Thanks, see also https://tedwvc.wordpress.com/2014/01/01/how-to-target-xp-with-vc2012-or-vc2013-and-continue-to-use-the-windows-8-x-sdk/ if you want to avoid the XP platform toolset.