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:

The version of Windows Installer on the client's machine is out of date.
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?

eleven81 · Answer 1 · 2009-02-11T20:43:01.340

13

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

edited Feb 11 '09 at 20:43

answered Feb 11 '09 at 18:57

eleven81

6,301
11
37
48

Good idea about the md5 check. – Michael Kelley Feb 11 '09 at 19:05
1

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 Feb 11 '09 at 19:06
That is a nice tool, Jon T. Thanks! – eleven81 Feb 11 '09 at 19:19
MD5 isn't reliable these days. If the MSI is digitally signed you can just do a properties | digatal signatures and it'll tell you if it's valid. – Christopher Painter Aug 26 '23 at 02:24

score 8 · Answer 2 · answered Mar 12 '10 at 00:01

8

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

answered Mar 12 '10 at 00:01

Julien Couvreur

4,473
1
30
40

1

Good point about the relative path. Looks like it msiexec.exe doesn't like relative paths. – Michael Kelley Jul 26 '10 at 23:24
1

Thanks. This is a very counter-intuitive behavior. This saved me a lot of frustration. – Keith Pinson Aug 16 '16 at 14:00
MSIEXEC has never hand a problem with relative paths. Now it's possible something else such as BitLocker or AppLocker is not liking it. Abolute paths are always safest from a security perspective. – Christopher Painter Aug 26 '23 at 02:23

score 5 · Answer 3 · edited Nov 24 '15 at 12:18

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.

score 4 · Answer 4 · answered Feb 11 '09 at 19:13

4

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)

answered Feb 11 '09 at 19:13

CheGueVerra

7,849
4
37
49

score 3 · Answer 5 · answered May 17 '19 at 09:17

3

it work when i use the absolute path ms file

example:

msiexec.exe /i .\a.msi

msiexec.exe /i c:\a.msi

answered May 17 '19 at 09:17

黄佳骏

31
2

score 1 · Answer 6 · edited Nov 24 '15 at 12:19

If anyone is developing a new installer and comes across this same error, check your Bootstrapper project output type. I added a new Bootstrapper project, and copied in a bunch of known-good code. The project output type defaults to MSI, and when attempting to test it I got an identical "MainEngineThread is returning 2" and the same preceding line.

Set the output type to its appropriate EXE and it's working great.

score 1 · Answer 7 · answered Sep 17 '16 at 18:41

1

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

answered Sep 17 '16 at 18:41

Sanjeev Kumar

193
1
7

score 0 · Answer 8 · answered Sep 25 '19 at 12:46

0

I've found out the problem!

Our scenario was similar:

we downloaded the msi (we tried several times all of them: the trial, the latest 2019, the beta 2019 and the beta 2020)
we started the MSI interactively and everything goes fine
when we tried with the quiet mode (as well documented) the outcome was always the same, it finished after a few lines with no useful documentation.

We discovered it's due to the way MSIEXEC access the MSI file and the ISSUE is related to the new Windows Blocking system done on the downloaded files (damn it!)

It's enough to run the powershell command "Unblock-File" and then everything start working properly!

I hope this can be useful, I'll always write to safe.com team to add this disclaimer into their documentation.

answered Sep 25 '19 at 12:46

MonDeveloper

186
9

You can also right click the file, go properties and uncheck the box there. [Illustration](https://blogs.msdn.microsoft.com/delay/p/unblockingdownloadedfile/) (or equivalent for your OS - might be a check box in Windows 10). – Stein Åsmul Sep 25 '19 at 13:14
1

U right, but in case you scripted everything (like we are doing during a docker build) the command line equivalent is there to save you! – MonDeveloper Sep 26 '19 at 16:24
Yes, definitely. Just thought I'd mention the quick and manual way. In fact, let me add [a link to a longer description of this flag set via an alternate data stream](https://stackoverflow.com/a/48835413/129130) (when downloaded from the internet a file will have an alternate data stream ``Zone.Identifier`` with a value of ``3`` indicating that the file was downloaded from the Internet). – Stein Åsmul Sep 26 '19 at 16:28

score 0 · Answer 9 · answered Aug 26 '23 at 02:11

I've been having this problem recently with all .msi files. I searched the net, tried every solution I could find, and none of them worked.

Then I remembered that I had solved this problem once before.

All the .MSI files that I was trying to install were in a folder that was mounted as a junction point. I could install anything else from that folder - just not .msi files. And this is a fairly new problem; I used to be able to install .msi files from this folder as well.

Anyway, I went into the original folder from which the junction point was created, and installing .msi files from here worked fine.

This definitely seems like a Microsoft bug to me; different executable types shouldn't act differently after a junction point. In fact, they should all just plain work - just like they used to.

Problems with Windows Installer package

9 Answers9