search

wixtoolset / issues

WiX Toolset Issues Tracker
http://wixtoolset.org/
129 stars 36 forks source link

Broken links for resolving "light.exe : error LGHT0217 : Error executing ICE action 'ICE01'. ..." #6254

Closed andy-schmidt closed 1 year ago

andy-schmidt commented 4 years ago

Bug report

I am trying to use WiX to build an installer as part of a Gitlab Continuous Integration Pipeline. I am using a Windows Server 2019 Core machine with the gitlab-runner service running under the NT Authority\LocalService account. The gitlab-runner service fetches build jobs from Gitlab and executes a shell script launching an Msys2 bash shell with a single command to invoke a make recipe. The compiler itself is Mingw64 gcc/g++. Everything builds fine except at the very end when light tries to build the MSI installer it fails with a series of errors of the form: light.exe : error LGHT0217 : Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wixtoolset.org/documentation/error217/ for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".

The problem is that when I follow the link provided in the error message, the webpage says see the links in the sidebar to resolve. But both of the links are broken. Would it be possible to update the webpage?

My build works fine from an interactive desktop. I believe the problem is related to running the build as a service under the NT Authority\LocalService account. But because the links describing the error in detail are broken I don't know if the root problem is

More details

Install a gitlab-runner service in Windows Server 2019 Core under the 'NT Authority\LocalService' account. Install Msys2 and Mingw64. Note that all the files in the directory C:\msys64\dev need to have an Access Control Entry added to allow the 'NT Authority\LocalService' account full control. icacls.exe can be used to do this. Additionally, the directory that the gitlab-runner account was installed into needs to an Access Control Entry added for NT Authority\LocalService to have full control along with object and container inheritance set.

In the source branch .gitlab-ci.yml file defining the build pipeline, make can be invoke from the shell executor using the command $env:MSYSTEM="MINGW64"; C:\msys64\usr\bin\bash --login -c 'make release'

kapsiR commented 3 years ago

We have the exactly same problem when using a service account or a local domain account for a windows service on the build server.

@barnson Can you elaborate a bit on the requirements to run the ICE actions successfully without giving the build service account administrator priviledges. (There are lots of resources that say the only way would be to disable the ICE checks entirely?!)

BMurri commented 3 years ago

ICE checks require access to the MSI install engine. That engine apparently has a hardcoded "deny" ACL for the two built-in non-administrator service accounts, as part of service hardening in the Vista era. Accounts don't have to be interactive, but they do have to not be based on either one of those two accounts. I don't know if per-service SID services are subject to the same restrictions or not (I haven't taken the time to try it out). Anything else requires either a domain-controlled account of some sort, or a manually managed account.

The alternatives are to suppress ICEs in the build and run them later (during test, perhaps?) or to replace the test runners with one that performs the merge and runs the tests completely in "UI".

kapsiR commented 3 years ago

@BMurri Thanks. Do you know which of the accounts/groups are affected? (Users / Domain Users?)

BMurri commented 3 years ago

I know that LocalService and NetworkService are affected, while LocalSystem is not affected because it's by definition an administrator.

I do not know if the service account types that I referred to before are affected or not. I also do not know if managed or virtual accounts are affected or not. It's quite possible that the restriction is that the account is logged in as a service that is the issue.

I'm pretty sure that accounts that are logged in as "batch" aren't affected if they aren't service accounts, so it might be possible to run builds from a service by batching the build jobs (using a non-service account). Then again, it may simply have to be an "interactive" account, I honestly don't know. My testing didn't reach that far.

I've been tempted to investigate running the validation by performing the merge and carrying out the actions described by MSFT (three stages of validation) without using any part of the prescribed API for performing validations (it's a COM library provided by the Windows Installer SDK). Testing needs to be done, however I haven't been on a team that's using MSI for several years now.

andy-schmidt commented 3 years ago

Thanks for the response

On Tue, Oct 12, 2021 at 7:22 AM Blair L Murri @.***> wrote:

I know that LocalService https://docs.microsoft.com/en-us/windows/win32/services/localservice-account and NetworkService https://docs.microsoft.com/en-us/windows/win32/services/networkservice-account are affected, while LocalSystem https://docs.microsoft.com/en-us/windows/win32/services/localsystem-account is not affected because it's by definition an administrator.

I do not know if the service account types that I referred to before are affected or not. I also do not know if managed or virtual accounts are affected or not. It's quite possible that the restriction is that the account is logged in as a service that is the issue.

I'm pretty sure that accounts that are logged in as "batch" aren't affected if they aren't service accounts, so it might be possible to run builds from a service by batching the build jobs (using a non-service account). Then again, it may simply have to be an "interactive" account, I honestly don't know. My testing didn't reach that far.

I've been tempted to investigate running the validation by performing the merge and carrying out the actions described by MSFT (three stages of validation) without using any part of the prescribed API for performing validations (it's a COM library provided by the Windows Installer SDK). Testing needs to be done, however I haven't been on a team that's using MSI for several years now.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wixtoolset/issues/issues/6254#issuecomment-941060061, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSIUII26SDF3SPMXWVSE7DUGRAA5ANCNFSM4SCH2L7Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

syswipe commented 2 years ago

Hi guys! Any updates? I have the same problem. My CI agent is running as a service using a separate user with all required permissions. And when I try to run some builds I got the same error. The only workaround I've found is to add -sval option to light.exe... When I run the same build script in an interactive session, all works perfectly.

BMurri commented 2 years ago

See my comments above.

Some day I'll have a couple hours to stage and run several experiments...

syswipe commented 2 years ago

@BMurri , thanks. I tried to investigate by myself using ProcMon, but I hadn't found any crimes...

gregcotten commented 1 year ago

Does anyone have a better workaround than "skip validation"?!

BMurri commented 1 year ago

I've been thinking about this but haven't had the chance to test some musings.

I'm pretty sure you don't want to build using an elevated account. So, I won't suggest that (although that works).

I know that authenticating as a service doesn't work. I know that logging in as an interactive user does work. I haven't tried a batch login yet. I'd be interested to know if that works or not.

The long-term alternative is to replace MSI's validation system with something that doesn't use the "official" use model. There is a plan in the WiX toolset to do just that, but it's been long delayed due to insufficient resources.

kapsiR commented 1 year ago

Just for anyone coming here and reading through the issue, this is the conclusion as documented now (1973ad8):

Anecdotal evidence suggests that typical hosted CI build machines use service accounts that are incompatible with validation and because the hosted machines cannot be configured, there is no workaround to run validation during the build. The only option is to suppress validation by setting <SuppressValidation>true</SuppressValidation> in your WiX MSBuild project.

anbkderivatives commented 1 month ago

Do you know how can we actually suppress the validation given that an msi file is generated by a maven plugin?

hron84 commented 1 month ago

For the record (and people coming from Google): If you do not use .wixproj for build an MSI file, you should pass -sval parameter to light.exe.

@anbkderivatives you should use goal parameter validate in your project's POM file, according to the WiX Maven plugin documentation: https://wix-maven.github.io/wix-maven-plugin/light-mojo.html#validate