views:

1576

answers:

4

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?

UPDATE: 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. Maybe I have to digitally sign the .msi file?

+6  A: 

Background:

I have noticed the exact same message when a MSI installer file was not downloaded completely, or was corrupted by my antivirus program, or was mangled by my FTP client.

The error message is actually coming from msiexec.exe, which is the executable program of the Windows Installer system that actually interprets the MSI installer files and installs the software on target the client's machine(s).


To check the integrity of the MSI file:

Calculate the MD5sum of a known-good copy of your MSI installer file using something like md5.exe. Have the client do the same thing for his copy, and then compare the hashes. If the results are different, then the client's copy of the MSI installer file is positively corrupt.


For example:

On your end:

C:\Documents and Settings\yourbox\Desktop>md5.exe AcroRead.msi
C587C739666E26B2A9B1F5BBAF358808  AcroRead.msi

On the client's end:

C:\Documents and Settings\theclient\Desktop>md5.exe AcroRead.msi
90AFFBD9A1954EC9FF029B7AD7183A16  AcroRead.msi
eleven81
Good idea about the md5 check.
Michael Kelley
I created a GUI utility to check hashes when I ran into this issue a while ago. You can find it here if you're interested: http://www.binaryfortress.com/hashtools/
Jon Tackabury
That is a nice tool, Jon T. Thanks!
eleven81
+1 Good view on how to check
Romain Hippeau
+2  A: 

You could try to start the MSI in the command line and get a log file.

like so: MSI: msiexec /i (Filename.MSI) /l*v (filename.TXT)

CheGueVerra
+3  A: 

This error message is thrown by msiexec if it detects that the msi file is corrupted. It can do that because all msi files have a checksum, and some even are digitally signed.

Such corruption of msi files unfortunately happens a lot. Not just because of flaky network connections when downloading, but most often by virus scanners which interfere with the download itself - if they try to 'sanitize' the data stream, you'll end up with a corrupt msi.

The only way to fix this is to re-download the msi file, and maybe disable the virus scanner/firewall for that download. You can check for viruses after the msi file is saved on disk before you try to install it.

Stefan
+1  A: 

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

Julien Couvreur
Good point about the relative path. Looks like it msiexec.exe doesn't like relative paths.
Michael Kelley