2

We are not quite sure what triggered this error to start showing up in our builds.

light.exe : error LGHT1105: Validation could not run due to system policy. To eliminate this warning, run the process as admin or suppress ICE validation.

We are hoping to understand better what circumstances could trigger it, so we can work backwards and fix whatever is causing it.

  1. We are already running as administrator
  2. We checked our antivirus settings, and the source and output folders are excluded from scans.
  3. We checked the size of the environment block using a debugger and it is only about 5.5k.
  4. We tried adding both of these settings to the wixproj mentioned in the command line:
<RunWixToolsOutOfProc>true</RunWixToolsOutOfProc>`
<SuppressValidation>true</SuppressValidation>`
  1. We checked and there were no Software Restriction Policies enabled.
e:\tools\managed\v4.0\WiX3.7\bin\Light.exe -out f:\obj.amd64fre\common\testplugin\msm\objfre\amd64\testplugin.msm -pdbout f:\obj.amd64fre\common\testplugin\msm\objfre\amd64\testplugin.wixpdb -nologo -sw1096 -wx -cultures:null -dPseudoCulture=tk-TM -dps-ps=1 -dProductVersion=10.0.1234.0 -dROOT=e:\rootpath -d_BuildArch=amd64 -dOBJECT_ROOT=f:\obj.amd64fre -d_BuildAlt=objfre\amd64\ -ext e:\tools\managed\v4.0\WiX3.7\bin\WixIIsExtension.dll -ext e:\tools\managed\v4.0\WiX3.7\bin\WixUtilExtension.dll -sice:ICE61 -contentsfile f:\obj.amd64fre\common\testplugin\msm\objfre\amd64\testplugin.msm.wixproj.BindContentsFileListnull.txt -outputsfile f:\obj.amd64fre\common\testplugin\msm\objfre\amd64\testplugin.msm.wixproj.BindOutputsFileListnull.txt -builtoutputsfile f:\obj.amd64fre\common\testplugin\msm\objfre\amd64\testplugin.msm.wixproj.BindBuiltOutputsFileListnull.txt -wixprojectfile e:\common\testplugin\msm\testplugin.msm.wixproj -fv -b f:\binaries.amd64fre\SCOnline f:\obj.amd64fre\common\testplugin\msm\objfre\amd64\testplugin.wixobj

Error:

5>light.exe : error LGHT1105: Validation could not run due to system policy. To eliminate this warning, run the process as admin or suppress ICE validation. [e:\common\testplugin\msm\testplugin.msm.wixproj]

Expect: No error.

David Holcomb
  • 21
  • 2
  • Just want to verify that you can run validation manually? (using [Orca](https://stackoverflow.com/a/48482546/129130)). I guess it might also help to do a **`procmon.exe`** session to see if it yields some clues? [Quick procmon.exe sample](https://stackoverflow.com/a/47792474/129130). Do you see the problem on multiple machines? Are you on an SOE? (corporate standard computer setup with restrictions). – Stein Åsmul Sep 18 '19 at 00:14
  • I suppose you could also try the latest official [WiX 3.11](https://wixtoolset.org/releases/) or the pre-release [3.14](https://wixtoolset.org/releases/development/). – Stein Åsmul Sep 18 '19 at 00:31
  • We don't normally run the validation manually. It normally runs as part of a pre-defined workflow using a service account. However, we can reproduce the problem easily by re-running the failed command manually. The problem started happening on all of our build machines. We will try the procmon tip to see if it yields any new info. – David Holcomb Sep 18 '19 at 17:23
  • So validation worked with Orca? (To get the tool: with Visual Studio installed, try searching for **`Orca-x86_en-us.msi`** - under **`Program Files (x86)`** - install it. To run validation: `Tools menu` `=>` `Validate...`). Something could have happened with the service account - obviously. Is it a [password-less managed service account](https://learn.microsoft.com/en-us/windows/security/identity-protection/access-control/service-accounts) or a regular account? – Stein Åsmul Sep 18 '19 at 19:02
  • I assume it is a real account since you can reproduce the problem (unless you do a runas). There must be something in the latest Windows update then, or some change to your environment of late. I guess you should check with your admins - and I assume you did? Windows update? Hmm, I got nothing today, I sense this is something very simple though. Maybe check my [deployment mnemonic (down the page)](https://stackoverflow.com/a/25005864/129130) and not really helpful here I think, but my [debugging ideas list](https://stackoverflow.com/a/53530377/129130). – Stein Åsmul Sep 18 '19 at 19:20
  • I tried Orca. From a second computer running Windows 10, I can open the MSM on the problem computer and run validation. But from the problem computer, I get the error "The validation engine could not start" as soon as I attempt to start validation. – David Holcomb Sep 18 '19 at 21:05
  • The problem is not related to the service account the automation normally runs under. Both the service account and my interactive login get the same LIGHT error. – David Holcomb Sep 18 '19 at 21:06

1 Answers1

0

You said you checked that SRP wasn't enabled, but did you happen to check if AppLocker was enabled? I started getting the same errors on my machine after enabling AppLocker ("light.exe : error LGHT1105" from WiX and "The validation engine could not start" from Orca).

Unfortunately there's no AppLocker rule you can set up to allow MSI validation to succeed, even though installation will work. There's two options, and neither are good:

  1. Delete all AppLocker rules for Windows Installer and uncheck "configured" for it. Or change it to "audit only" instead of "enforce rules".
  2. If you have local admin rights, rename C:\Windows\System32\AppLocker\Msi.AppLocker to e.g. Msi.AppLocker.temp-disabled before starting a build, then rename it back after the build.

See here for more details.

aplum
  • 188
  • 1
  • 8