WiX 3.0 throws error 217, while being executed by continuous integration

Question

This is the error that is thrown by our automated build suite on Windows 2008, while running ICEs (after migrating from WiX 2.0 to WiX 3.0):

LGHT0217: Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#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.". in light.exe(0, 0)

The FAQ is now deleted, however, the text from it said: In WiX v3, Light automatically runs validation-- Windows Installer Internal Consistency Evaluators (ICEs) --after every successful build. Validation is a great way to catch common authoring errors that can lead to service problems, which is why it’s now run by default. Unfortunately, there’s a common issue that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to fail. For details on the cause and how to fix it, see Heath Stewart's Blog and Aaron Stebner's WebLog.

Additionally, these are the errors that show up in the event log:

MSIInstaller: Failed to connect to server. Error: 0x80070005 Product: [ProductName] -- Error 1719. 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.

Intuitively:

• VBScript and JScript were registered under admin.
• Integration service has permissions for the desktop interaction and all the files
• Builds succeed, when executed manually on the same machine by another user or even user logged in as integration account (via RDP)

I'm out of ideas so far.

How do I solve this problem while keeping ICE validation?

Resurrectionism

Great that the FAQ url in the errormessage is broken... – Stannum

Answer 1

End of the story:

After fiddling with the permissions of the integration account, DCOM, service activation, etc. without any luck, I finally simply disabled ICE validation in the continuous integration build, while still keeping it in the local build.

To disable ICE validation you can set SuppressValidation to true in the .wixproj file:

    <PropertyGroup>
        <SuppressValidation>true</SuppressValidation>
    </PropertyGroup>

Or pass the -sval command line option to light.exe.

Resurrectionism

This was the best answer I could come up with, too. It appears that the account which the build process runs under needs to elevate in order to connect to the Windows Installer Service to run ICEs. I thought about giving the build process admin permissions in order to solve the problem, but figured just disabling it on the CI build is just as much of a problem for now. – Brockie

How did you disable the ICE validation? – Belgian

@Chu, see the additions in the answer – Pernickety

Thats not really an answer, rather a, not very good, workaround. – Mcmanus

Maybe this is not a good workaround, but this is the only way I found to generate my MSI. So thank you Rinat ! – Doreathadoreen

For others considering this answer as a viable solution, you should understand that violating ICE can bring you troubles in trying to adhere to f.ex msdn.microsoft.com/en-us/library/windows/desktop/… As well as production on-site formalized checks. In short. Do not solve your issue by disabling ICE checks. – Mcmanus

No need to supress validation. Check my answer 3 posts under. – Beckon

Neither messing with the environment nor giving my build agent user administrator privileges worked for me. Both WiX Toolset issue 3968 and a post by Rob Mensching on WiX-Users say the only reliable workaround is disabling ICE. Something like WiX's ICE Breakers project might fix things someday. – Naji

My findings are very sadly the same as above. I too had to disable validation, I also removed registry keys (if they existed), checked env size (it was way below 30K) and also ran with elevated privileges. It just gave the same error all the time - the link in the error also goes to a 404 page which isn't great. It's just not a reliable tool and this stops that. I used the -sval on the command line. – Illa

Answer 2

Adding the TFS build controller account to local admin group and restarting the windows service did the job for me.

Mcmanus

But that is against Team Build best practices, see: msdn.microsoft.com/en-us/library/dd578625 – Unruffled

I agree that it's a bad practice, and not something I personally enjoy doing, but it's the lesser of two evils. Disabling ICE validation completely for your MSIs versus making the build account an administrator. – Flaming

To further reflect on @Jeff s comment, its really an obvious choice: use time on properly securing a build machine safely on the ontranet, or disable a check that potentially breaks stuff like "designed for windows server" logo verification. – Mcmanus

It would be great to understand what exact permissions are required instead of giving full admin role... – Disunity

In my company it is not allowed to do this. As Ivan commented above, does anybody know which exact permissions are necessary? (BTW we tried this suggested solution temporarily and it worked) – Juju

Answer 3

I found the root cause. I tried everything I found, including custom validator extension similar to one posted in Re: [WiX-users] light.exe failed randomly when running ICEs..

It's not a concurrency issue as suggested in various threads. It's caused by a too large Process Environment Block (PEB).

It turns out Windows Installer can’t handle a process environment block larger than 32 kB. In my environment, due to number of variables set by the build system and their size (for example, PATH variable containing multiple duplicated values), PEB was about 34 kB.

Interestingly, per Environment Variables, Windows XP and 2003 had a hard limit of PEB set to 32 kilobytes. That would probably cause an easy-to-catch build break in an earlier phase of the build. Newer Windows' doesn’t have such limit, but I guess that Windows Installer developers limited their internal environment buffers to 32 kB and fail gracefully when the value is exceeded.

The problem can be easily reproduced:

• Create a .bat file which sets environment variables which size exceeds 32 kB. For example, it can be 32 lines of set Variable<number>=<text longer than 1024 characters>
• Launch cmd.exe
• Execute the batch file you created
• From the same cmd.exe window:
  • Try building the MSI package using WiX with ICE validation on OR
  • Run smoke.exe to validate your package OR
  • Simply run msiexec /i Package.msi
• All the above commands will end up reporting Error 1719 - Windows Installer could not be accessed.

So, the solution is - review your build scripts and reduce number and size of environment variables so they all fit into 32 kB. You can easily verify the results by running:

set > environment.txt

The goal is to get file environment.txt smaller than ~30 kB.

Supersonic

This appears to be the issue I was hitting as well. I was suspecting concurrency but there weren't enough MSIs building in parallel. Thanks so much for sharing this solution. Would love to know how you finally debugged it. – Piero

I assume you mean it is one of the causes of the issue because my environment variables are less than 2K. – Chu

Worked for me too, thanks. But my threshold is lower. 6KB (-> 5900 characters) worked. 10 KB (-> 9300 characters) shows the error. Running on Windows Server 2016 within electron-builder 20.39.0 – Cyr

My environment.txt is ~ 7 KB. So this is probably not the problem then. 🤔 – Kristie

Worked for me too: I was using electron-builder using CSC_LINK variable with base64-encoded certificate, causing the environment to be too large. To fix this, I stored the certificate in a file and set CSC_LINK to the certificate filename. – Leora

This was my issue as well. On Windows 10 – Entablature

Answer 4

The correct description (without a solution, except if adding the CruiseControl account into local administrators group can pass as a solution) of the problem:

Quote from Wix 3.5 & Cruise Control gives errorLGHT0217:

ICE validation needs an interactive account or administrator privileges to be happy. See for example WiX Projects vs. TFS 2010 Team Build (2009-11-14) or Re: [WiX-users] Help with building patch (2009-11-20).

Floorer

Answer 5

imagi is totally right! I could not believe this is the true answer. Supressing validation and making TFS user Administrator are not good solutions. Plus I could not find NT\Authority to add it to Administrators group and was totally stuck in this.

I got the same error on Windows Server 2012 Datacenter as Build Agent. To solve the problem :

1. List item
2. Go to Environment Variables on the build agent machine
3. Create two System Variables
4. "PF86" which is equal to "C:\Program Files (x86)"
5. "PF" which is equal to "C:\Program Files"
6. They are so short because I want to save characters.I made them without the final backslash because TEMP, TMP and others were made so and I decided to stick to MS standard for these variables.
7. Edit PATH variable by substituting every "C:\Program Files (x86)" with %PF86% and every "C:\Program Files" with %PF%
8. Close and build and enjoy!
9. It worked for me. :)

UPDATE I found a better solution : Rapid Environment Editor will do all this and even more for you. Automatically.

Beckon

Answer 6

I faced the same problem and did not like to suppress ICE validation. My setup: I used my own computer as a build agent on Visual Studio Online (VSO). My solution was to change the account used to run the service on my machine. Instead of using Network Service or Local Service I simply made the service log on with my own account which had all the necessary rights.

Rama

This is exactly what was happening to me. The account under which the build services were running had permission issues. I changed the user and the build now passes – Physicist

Answer 7

From http://wix.sourceforge.net/faq.html#Error217:

In WiX v3, Light automatically runs validation-- Windows Installer Internal Consistency Evaluators (ICEs) --after every successful build. Validation is a great way to catch common authoring errors that can lead to service problems, which is why it’s now run by default. Unfortunately, there’s a common issue that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to fail. For details on the cause and how to fix it, see Heath Stewart's Blog and Aaron Stebner's WebLog.

Susurrant

Did anything in that link actually help you fix this problem? – Achaean

That didnt work for me. I have a brand new server with 2008 R2 x64 and the dll's are registered under HKLM not HKCU. – Mcgann

Both of those links are dead. Please include the actual supposed solution in the answer. – Codpiece

One of the links is here. devblogs.microsoft.com/setup/… – Furlough

Answer 8

I was getting same ICE error, but the problem turned to be corrupted Windows Installer Service. This solution worked for me: http://support.microsoft.com/kb/315353

1. Log on to your computer as an administrator.
2. Click Start, and then click Run.
3. In the Open box, type cmd, and then click OK.
4. At the command prompt, type msiexec.exe /unregister, and then press ENTER.
5. Type msiexec /regserver, and then press ENTER.
6. Restart Windows

Also, verify that the SYSTEM account has full control access permissions to the HKEY_CLASSES_ROOT hive in the Windows registry. In some cases, you may also have to add Administrator accounts.

Jumbled

Answer 9

I got this error from my Azure build agent running on-premises. My solution was to upgrade its user account from "Network Service" to "Local system account".

Fruitless

Answer 10

I have some suggestions.

• Try updating the Microsoft Installer version on the build server
• Make sure you use the newest release of WiX 3.0, since it's 3.0 release stable now.
• If all else fails, try running the build service under a specific build user who you can fiddle with permissions for...

Lifeboat

1. Yes; 2. Latest; 3. I can change permissions of integration account. – Resurrectionism

Try adding the build user to the DCOM local users group. – Lifeboat

Didn't work that time. I ended up disabling ICE validation in the integration build. – Resurrectionism

Answer 11

Go to your build machine and restart the Windows Installer service

Barbell

Answer 12

None of the above suggestions worked for me, for me the anti-virus (mcafee) came into the picture and looks like it updated the vbscript.dll registry entry to a wrong DLL location. These are the things to keep in mind:

1. Some of the WiX ICE validations are implemented using VBSCRIPT.
2. So while compiling the MSI, the build server would need access to the c:\windows\system32\vbscript.dll.
3. Chances are that somehow the user that runs your build lost access to this DLL.
4. As mentioned in the above answers do look for the admin access/registry access and make sure your user has it.

Here are the steps that I took to fix the issue:

1. Open cmd (run as admin) on the build agent machine.
2. Run RegEdit
3. Select the root, then click ctrl + f and Search for the following registry entry : {B54F3741-5B07-11cf-A4B0-00AA004A55E8}
4. Look for the InprocServer32\Default Key

1. On my build agent, the path was replaced with a mcafee DLL location. I updated the path back to c:\windows\system32\vbscript.dll
2. Editing the registry entry was not easy, as it was a protected registry entry. I used the below link to get access permissions changed before I could edit the property: Edit protected registry entry

Once I updated the path, everything started working as usual.

Immolate

Answer 13

My solution is similar to Vladimir's one. My CI user was admin of the computer.

But the following steps were mandatory to allow my jenkins build to succeed:

• log in as CI user using rdp
• open a dos command prompt
• execute: %windir%\system32\msiexec.exe /unregister
• execute: %windir%\system32\msiexec.exe /regserver

then i got a successfull job

Addressee