Problems with Windows Installer package

Question

I have a client that is having problems with our the .msi installer for our application. WiX was used to create this installer. The application has installed just fine on dozens of other machines, but on his machine it displays the message:

This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer Package.

My guess is that it is one of these two possibilities:

1. The version of Windows Installer on the client's machine is out of date.
2. The .msi he has could be corrupted.

What is the most likely possibility, or are there other possibilities that I'm not aware of?

I think I've recreated the user's problem. If, from a command shell, I run MyFile.msi, then it successfully loads, then I get this in the log file:

=== Verbose logging started: 2/12/2009  10:34:38  Build type: SHIP UNICODE 4.00.6001.00  Calling process: C:\Windows\System32\msiexec.exe ===
MSI (c) (F4:04) [10:34:38:795]: Resetting cached policy values
MSI (c) (F4:04) [10:34:38:795]: Machine policy value 'Debug' is 0
MSI (c) (F4:04) [10:34:38:795]: ******* RunEngine:
           ******* Product: C:\Users\kelley\Downloads\PixelActiveCityScape_v1_6_Demo.msi
           ******* Action:
           ******* CommandLine: **********
MSI (c) (F4:04) [10:34:38:802]: Machine policy value 'DisableUserInstalls' is 0
MSI (c) (F4:04) [10:34:38:830]: Note: 1: 1402 2: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer 3: 2
MSI (c) (F4:04) [10:34:39:140]: SOFTWARE RESTRICTION POLICY: Verifying package --> 'C:\Users\kelley\Downloads\PixelActiveCityScape_v1_6_Demo.msi' against software restriction policy
MSI (c) (F4:04) [10:34:39:141]: Note: 1: 2262 2: DigitalSignature 3: -2147287038
MSI (c) (F4:04) [10:34:39:141]: SOFTWARE RESTRICTION POLICY: C:\Users\kelley\Downloads\PixelActiveCityScape_v1_6_Demo.msi is not digitally signed
MSI (c) (F4:04) [10:34:39:142]: SOFTWARE RESTRICTION POLICY: C:\Users\kelley\Downloads\PixelActiveCityScape_v1_6_Demo.msi is permitted to run at the 'unrestricted' authorization level.
MSI (c) (F4:04) [10:34:39:189]: Cloaking enabled.
MSI (c) (F4:04) [10:34:39:190]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (F4:04) [10:34:39:197]: End dialog not enabled
MSI (c) (F4:04) [10:34:39:197]: Original package ==> C:\Users\kelley\Downloads\PixelActiveCityScape_v1_6_Demo.msi
MSI (c) (F4:04) [10:34:39:197]: Package we're running from ==> C:\Users\kelley\AppData\Local\Temp\40a3581.msi
.
.
.

However, if I run msiexec /i MyFile.msi /l*v MyLog.TXT, I get this:

 === Verbose logging started: 2/12/2009  10:32:19  Build type: SHIP UNICODE 4.00.6001.00  Calling process: C:\Windows\sy
stem32\msiexec.exe ===
MSI (c) (FC:F0) [10:32:19:597]: Resetting cached policy values
MSI (c) (FC:F0) [10:32:19:597]: Machine policy value 'Debug' is 0
MSI (c) (FC:F0) [10:32:19:597]: ******* RunEngine:
           ******* Product: .\PixelActiveCityScape_v1_6_Demo.msi
           ******* Action:
           ******* CommandLine: **********
MSI (c) (FC:F0) [10:32:19:599]: Note: 1: 2203 2: .\PixelActiveCityScape_v1_6_Demo.msi 3: -2147287038
MSI (c) (FC:F0) [10:32:19:600]: MainEngineThread is returning 2
=== Verbose logging stopped: 2/12/2009  10:32:19 ===

And this shows this dialog box:

This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package.

So it seems like a permissions issue, but I'm not exactly sure why and how I can fix it. Do I maybe have to digitally sign the .msi file?

Answer 1

it work when i use the absolute path ms file

example:

msiexec.exe /i .\a.msi

msiexec.exe /i c:\a.msi

Answer 2

Solution: 1) run the cmd as the administrator, 2) F:\SOFTWARES>msiexec /i node-v4.5.0-x64.msi

Answer 3

I ran into this issue ("MainEngineThread is returning 2") as well. This thread was useful to narrow down the issue, but I have not fully solved it.

In our case, we suspect the problem is related to BitLocker and/or calling msiexec with relative paths (such as "msiexec /i ..\foo.msi"). Running "..\foo.msi" directly works, running "msiexec /i foo.msi" in the proper folder also works.

Maybe these clues will help someone else. In our case, we will change the directory structure to avoid the "..".