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.
We are already running as administrator
We checked our antivirus settings, and the source and output folders are excluded from scans.
We checked the size of the environment block using a debugger and it is only about 5.5k.
We tried adding both of these settings to the wixproj mentioned in the command line:
<RunWixToolsOutOfProc>true</RunWixToolsOutOfProc>`
<SuppressValidation>true</SuppressValidation>`
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.
Related
Setup: IntelliJ IDEA 2022.2.2, Erlang 25.0
I am trying to run the Erlang code available at https://erlangbyexample.org/send-receive. I am able to run in werl and Windows command line. But I am getting the error "init terminating in do_boot" when I run in IntelliJ.
I checked a similar issue reported in this question , wherein the solution was to convert list input to integer/s. However, my Erlang code does not expect any input, it just expects the function name.
Please provide a pointer to resolve the issue.
"C:\Program Files\Erlang OTP\bin\erl.exe" -pa F:/1TB/P/workspace-IntelliJ-Erlang1/out/production/workspace-IntelliJ-Erlang1 -pa F:/1TB/P/workspace-IntelliJ-Erlang1 -eval send_recv:run(). -s init stop -noshell
{"init terminating in do_boot",{undef,[{send_recv,run,[],[]},{erl_eval,do_apply,7,[{file,"erl_eval.erl"},{line,744}]},{init,start_it,1,[{file,"init.erl"},{line,1234}]},{init,start_em,1,[{file,"init.erl"},{line,1220}]},{init,do_boot,3,[{file,"init.erl"},{line,910}]}]}}
init terminating in do_boot ({undef,[{send_recv,run,[],[]},{erl_eval,do_apply,7,[{_},{_}]},{init,start_it,1,[{_},{_}]},{init,start_em,1,[{_},{_}]},{init,do_boot,3,[{_},{_}]}]})
Crash dump is being written to: erl_crash.dump...done
I configured RunConfiguration to BUILD before RUNNING ("Before launch" section). As result, RunConfiguration was creating an empty folder "../out/production/workspace-IntelliJ-Erlang1" without .beam files, if the folder does not exist. It would delete any existing .beam files if the folder exists. Hence, the RUN was failing eventually.
As a workaround, I removed the BUILD before RUNNING option from RunConfiguration. And, I manually built using BuildProject before RunConfiguration.
TODO: I will check why was not RunConfiguration able to generate the .beam file.
Check if there is a file called send_recv.beam in either of the directories specified as code path in the -pa arguments. (The undef error means that it can't find the function send_recv:run/0, more often than not because it can't find the compiled module.)
My guess is that this file is actually in the directory where you ran Erlang from the command prompt, but IntelliJ runs Erlang using another working directory. The current working directory is part of the code path by default, which would be why this works from the command prompt but not within IntelliJ.
I'm trying to install the 3.10.2 version of the Wix Toolset Installer but when I launch the installer nothing happens. Pulling up the log file reveals the following errors:
[15A4:1580][2016-03-04T07:54:57]e000: Error 0x80070005: Failed to launch clean room process: C:\Users\MALLAR~1\AppData\Local\Temp\1\{BA709DF5-6D54-418B-9760-DD363E3FE5DD}\.cr\wix310.exe
[15A4:1580][2016-03-04T07:54:57]e000: Error 0x80070005: Failed to run untrusted mode.
I am unable to find anything related to this error.
3.10.2 introduced the clean room concept to mitigate dll hijacking attacks. This involves copying itself to a clean folder in the user's temp directory and then doing most of the work from that new process. Aggressive AV products might interfere with this. For more information about clean room see http://wixtoolset.org/development/wips/5184-burn-clean-room/ and https://www.firegiant.com/blog/2016/1/20/wix-v3.10.2-released/.
NAnt build script fails with this message
External Program Failed: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe (return code was -1066598274)
What can this mean?
The SVN "getting" sometimes get out of whack.
Reboot.
If that doesn't work:
Login as the identity that is causing the issue above.
Issue a svn.exe list command (or anything, but 'list' is the easiest) and make sure you have the certificate downloaded correctly. (as in, from the command line)
Basically, do some basic stuff to correct the svn "getting".
I'm having some strange issues with WiX on my local machine. The problem is intermittent, but after a few rebuilds of the solution, the WiX project starts throwing ICE validation errors.
If I go into my AppData\Local\Temp folder and delete all the temporary folders that contain the MSI, the solution compiles again. A short while later, the problem starts happening again. Having to keep clearing down the temp folders isn't a sustainable or satisfactory solution.
Has anyone else encountered this issue? The validation error codes seem to always be a combination of ICE30, ICE38, ICE64 and ICE91
Update:
As requested, here are the entries from the most recent failure:
error LGHT0204: ICE38: ICE Internal Error 1002. API Returned:
1615. error LGHT0204: ICE38: Error 2235: /OU.AppFramework.Includes.msi, _Profile, UPDATE Directory SET
_Profile=0 error LGHT0204: ICE64: ICE Internal Error 1001. API
Returned: 1615. error LGHT0204: ICE64: Error 2242:
OU.AppFramework.Includes.msi, _Profile, ALTER TABLE Directory ADD
_Profile SHORT TEMPORARY HOLD error LGHT0204: ICE91: ICE
Internal Error 1001. API Returned: 1615. error LGHT0204: ICE91:
Error 2242: OU.AppFramework.Includes.msi, _Profile, ALTER TABLE
Directory ADD _Profile SHORT TEMPORARY HOLD
Interestingly, this failure occurred before I left the office last night, and the solution compiled OK when I came in this morning. As it seems to centre on the temp directory where the MSI is build by WiX, could it be the build process locking the file?
Update 2:
And now we're back to over 600 errors, mostly repetition of this error:
error LGHT0204: ICE30: ICE Internal Error 100. API Returned: 1615.
error LGHT0204: ICE30: Error 2235: AppFramework.Includes.msi,
_ICE30SFN, SELECT Directory_Parent, Directory, DefaultDir, _ICE30SFN, _ICE30LFN FROM Directory WHERE
Directory.Directory=? AND Directory_Parent<>?
Update 3:
The problem still exists even after trying the suggestion by #limpan. There are a couple of warning given by light that are caused by the MSI output folder being locked when light tries to access the MSI:
Warning 549 The directory '\AppData\Local\Temp\2opu3hxf' is in use and cannot be deleted. light.exe
Try adding <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> to your WiX project file.
We've had the same issue for a while, and tried various workarounds including deleting the temporary files and setting the msbuild environment variable. These all appeared to work for a while, but eventually (sometimes after a few days) the problem would come back again.
I noticed that on my machine devenv.exe was the process that was locking the files that light.exe was trying to delete. I also stumbled across an unrelated thread which mentioned this project setting to make the WiX tools run out of process. I thought it could be worth a try and it appears to have cured the problem for us (so far...)
I had this issue as well and solved it in my environment.
Short answer:
Add the environment variable MSBUILDDISABLENODEREUSE=1 and restart Visual Studio
Long answer:
There was a warning during build that I first didn't see since I was too focused on the error:
Failed to delete temporary directory: C:\Users[username]\AppData\Local\Temp\5[uniqueFolderName] light.exe
I tried to remove the folder manually, but it was in use by another process.
It turns out that a lot of MSBuild.exe processes are started during build and then not closed again.
You can read more about the reason for that and what you can do to change that behavior in Stack Overflow question msbuild.exe staying open, locking files.
This thread: it and the solution in this thread:
I hope this answer can help someone else.
For ICE30: ICE Internal Error 100. API Returned: 1615, please try this and see if it works:
Close all instances of Visual Studio (may be just the one that matters but just in case)
Go to C:\Documents and Settings\\****user id****\\Local Settings\Temp\.
Clear all the folders that look like this .. 's12qgaks'. Basically it contains the MSI files
Open the solution and recompile.
Good luck!
I too had faced same the issue. In project properties, go to Tool Settings and click Suppress ICE validation.
For me MSBUILDDISABLENODEREUSE=1 (or /nr:false on command line) did not solve the problem.
But <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> did its job done.
I had the same issue. It turned out to be my Anti Virus software (OfficeScan) It had the intermediate files created by Light.exe locked and the validation process failed. Excluding the temp folder from virus scan or turning off ICE validation is not an acceptable solution.
If anyone has a better solution. I would like to know.
I'm analyzing existing Windows Store applications and modifying them to make sure my company's obfuscator works with them.
I've ran into a bit of a problem doing that though. I can grab an APPX package from the store easily enough(requires Fiddler to get the URL). I can then just use any unzip program to extract the appx to a folder. I can then take the assemblies in the APPX and modify the IL a bit. I then remake and sign the package:
makeappx pack /d "mypackage" /p "mypackage.appx"
signtool sign /fd sha256 /f temporarykey.pfx mypackage.appx
I then get an error with signtool though:
SignTool Error: An unexpected internal error has occured
Error information: "Error: SignerSign() failed." (-2147024885/0x800700b)
And then of course get an error when trying to install it with the standard powerscript file created by Visual Studio for installing/sideloading any APPX package.
Found package: C:\....mypackage.appx
Error: The package is not digitally signed or its signature is corrupted
I've used this exact process for packages generated from Visual Studio. Are temporary keys tied to a particular package or something? What am I missing? Is this a bug in signtool?
Apparently, you can't just take any temporary key and sign the APPX with it. In particular the certificate subject lines must match(the "publisher name"). I do not know of a better way of determining what the subject line much actually be. First, try to use signtool and sign the APPX file with any temporary key. Now go to Event Viewer. Then to Applications and Services and then Microsoft and then Windows and then AppxPackaging and finally Microsoft-Windows-AppxPackages/Operational. There should be an error event that just happened from that build. Check it. It should say something like
Error 0x800700B: The app manifest publisher name (CN=random-hex-number) must match the subject name of the signing certificate (CN=MyWrongName)
So, now make sure to hang on to that random-hex-number. That needs to be the subject line of the certificate and is the cause of the error. To generate a working certificate:
makecert.exe mycert.cer -r -n "CN=random-hex-number" -$ individual -sv private.pkv -pe -cy end
pvk2pfx -pvk private.pkv -spc mycert.cer -pfx mytemporarykey.pfx
Now finally, you should have a temporary key that will work with signtool!
Hopefully this answers serves other people well.