Burn packages crash with STATUS_ILLEGAL_INSTRUCTION on old hardware

[wixbot]

Apparently, Visual Studio 2012 by default generates code that contains SSE2 instructions, but around here we have some crusty old hardware with AthlonXP processors, which do not support SSE2, but do support running Windows 7. On one of these machines, I tried to install a test build of our new WiX/Burn based installer and it crashed with code c000001d (STATUS_ILLEGAL_INSTRUCTION).

From the MSDN (https://msdn.microsoft.com/en-us/library/vstudio/7t5yh4fd%28v=vs.110%29.aspx):

Because the x86 compiler generates code that uses SSE2 instructions by default, you must specify /arch:IA32 to disable generation of SSE and SSE2 instructions for x86 processors.

Originally opened by jeremydrake+wix

[wixbot]

I did a quick test last night, and this patch seems to do the trick (I don't see a way to attach a file offhand, but it's small, so here it is inline). I also noticed and fixed a typo on $(Plaform) vs $(Platform) (missing t) in an existing line. Note that the default setting for EnableEnhancedInstructionSet is NotSet, but I included that explicitly for vc10 since I was handling the other cases already.

diff --git a/tools/WixBuild.vcxproj.props b/tools/WixBuild.vcxproj.props
index 3e9fe33..b864446 100644
--- a/tools/WixBuild.vcxproj.props
+++ b/tools/WixBuild.vcxproj.props
@@ -91,7 +91,22 @@
     </Link>
   </ItemDefinitionGroup>

-  <ItemDefinitionGroup Condition=" '$(Plaform)'=='arm' ">
+  <ItemDefinitionGroup Condition=" '$(Platform)'=='Win32' and '$(PlatformToolset)'=='v100'">
+    <ClCompile>
+      <EnableEnhancedInstructionSet>NotSet</EnableEnhancedInstructionSet>
+    </ClCompile>
+  </ItemDefinitionGroup>
+  <ItemDefinitionGroup Condition=" '$(Platform)'=='Win32' and '$(PlatformToolset)'=='v110_xp'">
+    <ClCompile>
+      <EnableEnhancedInstructionSet>NoExtensions</EnableEnhancedInstructionSet>
+    </ClCompile>
+  </ItemDefinitionGroup>
+  <ItemDefinitionGroup Condition=" '$(Platform)'=='Win32' and '$(PlatformToolset)'=='v120_xp'">
+    <ClCompile>
+      <EnableEnhancedInstructionSet>NoExtensions</EnableEnhancedInstructionSet>
+    </ClCompile>
+  </ItemDefinitionGroup>
+  <ItemDefinitionGroup Condition=" '$(Platform)'=='arm' ">
     <ClCompile>
       <CallingConvention>CDecl</CallingConvention>
     </ClCompile>

Originally posted by jeremydrake+wix

[wixbot]

AssignedTo set to bobarnson
Release changed from v3.9 to v3.11

[n32]

Please help an end user here: Some of our critical applications can no longer be updated because the software publisher switched to Wix and it has this bug. We would migrate our data to a newer platform but we need to install those updates first in order to use the latest export features. When will this patch be integrated into the toolset? Is there a way to extract the contents of a Wix installer package and manually move the files into place?

[robmen]

This bug is in the WiX v3.11 release which starts soon.

In the mean time, you can use dark.exe to decompose a bundle. The output will not be just the MSIs so you'll have to do some work to gather the parts you need, but it will all be there.

[jchoover]

Or on a non ancient machine one could /layout and just install the bits.
Not as great but a quick and dirty fix. Not sure if that would work if it's
an embedded payload, as I can't remember if we extract the embedded content
on a layout.

On Wednesday, January 20, 2016, Rob Mensching notifications@github.com
wrote:

This bug is in the WiX v3.11 release which starts soon.

In the mean time, you can use dark.exe to decompose a bundle. The output
will not be just the MSIs so you'll have to do some work to gather the
parts you need, but it will all be there.

—
Reply to this email directly or view it on GitHub
#4876 (comment).

[robmen]

Fixed