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

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.

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...

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".

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.

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