2

I've encountered a strange issue running a WiX installer on a windows 8 machine. When I click the msi I get the message "This action is only valid for products that are currently installed". Running the msi with logging shows the following:

=== Verbose logging started: 3/11/2014  9:46:49  Build type: SHIP UNICODE 5.00.9600.00  Calling process: C:\WINDOWS\system32\msiexec.exe ===
MSI (c) (20:C4) [09:46:49:933]: Font created.  Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg

MSI (c) (20:C4) [09:46:49:934]: Font created.  Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg

MSI (c) (20:40) [09:46:49:956]: Resetting cached policy values
MSI (c) (20:40) [09:46:49:956]: Machine policy value 'Debug' is 0
MSI (c) (20:40) [09:46:49:956]: ******* RunEngine:
           ******* Product: myinstaller.msi
           ******* Action: 
           ******* CommandLine: **********
MSI (c) (20:40) [09:46:49:976]: Machine policy value 'DisableUserInstalls' is 0
MSI (c) (20:40) [09:46:50:014]: Note: 1: 1402 2: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer 3: 2 
MSI (c) (20:40) [09:46:50:766]: SOFTWARE RESTRICTION POLICY: Verifying package --> 'E:\myinstaller.msi' against software restriction policy
MSI (c) (20:40) [09:46:50:766]: Note: 1: 2262 2: DigitalSignature 3: -2147287038 
MSI (c) (20:40) [09:46:50:766]: SOFTWARE RESTRICTION POLICY: E:\myinstaller.msi is not digitally signed
MSI (c) (20:40) [09:46:50:778]: SOFTWARE RESTRICTION POLICY: E:\myinstaller.msi is permitted to run at the 'unrestricted' authorization level.
MSI (c) (20:40) [09:46:50:793]: Cloaking enabled.
MSI (c) (20:40) [09:46:50:793]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (20:40) [09:46:50:799]: End dialog not enabled
MSI (c) (20:40) [09:46:50:799]: Original package ==> E:\myinstaller.msi
MSI (c) (20:40) [09:46:50:799]: Package we're running from ==> C:\Users\PATRI_~1\AppData\Local\Temp\50d229a.msi
MSI (c) (20:40) [09:46:50:804]: MSI_DBG: Provided descriptor less than minimum size
MSI (c) (20:40) [09:46:50:807]: APPCOMPAT: Compatibility mode property overrides found.
MSI (c) (20:40) [09:46:50:808]: APPCOMPAT: looking for appcompat database entry with ProductCode ''.
MSI (c) (20:40) [09:46:50:808]: APPCOMPAT: no matching ProductCode found in database.
MSI (c) (20:40) [09:46:50:849]: MSCOREE not loaded loading copy from system32
MSI (c) (20:40) [09:46:50:859]: Machine policy value 'TransformsSecure' is 0
MSI (c) (20:40) [09:46:50:859]: User policy value 'TransformsAtSource' is 0
MSI (c) (20:40) [09:46:50:860]: APPCOMPAT: looking for appcompat database entry with ProductCode ''.
MSI (c) (20:40) [09:46:50:860]: APPCOMPAT: no matching ProductCode found in database.
MSI (c) (20:40) [09:46:50:860]: Transforms are not secure.
MSI (c) (20:40) [09:46:50:860]: PROPERTY CHANGE: Adding MsiLogFileLocation property. Its value is 'E:\installlog.txt'.
MSI (c) (20:40) [09:46:50:860]: Command Line: CURRENTDIRECTORY=E:\ CLIENTUILEVEL=0 CLIENTPROCESSID=800 CURRENTMEDIAVOLUMELABEL=? 
MSI (c) (20:40) [09:46:50:860]: PROPERTY CHANGE: Adding PackageCode property. Its value is '{9C098FBE-3C8F-452D-A0C4-B543717B6E3D}'.
MSI (c) (20:40) [09:46:50:861]: Product Code passed to Engine.Initialize:           ''
MSI (c) (20:40) [09:46:50:861]: Product Code from property table before transforms: ''
MSI (c) (20:40) [09:46:50:861]: Product Code from property table after transforms:  ''
MSI (c) (20:40) [09:46:50:861]: Failing install, missing product code
This action is only valid for products that are currently installed.
E:\myinstaller.msi
MSI (c) (20:40) [09:46:50:862]: Note: 1: 1708 
MSI (c) (20:40) [09:46:50:863]: Product:  -- Installation failed.

MSI (c) (20:40) [09:46:50:865]: Windows Installer installed the product. Product Name: . Product Version: . Product Language: . Manufacturer: . Installation success or error status: 1605.

MSI (c) (20:40) [09:46:50:871]: MainEngineThread is returning 1605
=== Verbose logging stopped: 3/11/2014  9:46:50 ===`

The odd thing is the same installer works fine on a win7 machine and a slightly older version of the installer works on the win8 machine. I am not sure why the product code is empty since it has a valid guid on win7.

Does anyone have any insight as to why I'm getting this error?

EDIT: Using Orca I can see that the ProductCode Property of the MSI is set to a valid GUID

EDIT2: By swapping out the GUID in the Product code using Orca with a Guid from another version of the installer, I can get it to work, but when building from WiX with ProductCode='*', it's not working even though the guid that gets put in the product code seems valid.

patrickbadley
  • 2,510
  • 2
  • 29
  • 30
  • Just one thing to rule out first: can you check the MSI and any previous version for the package guid? If it is ever identical in several files MSI will handle different files as the same file by definition - all kinds of weird problems can result. – Stein Åsmul Mar 11 '14 at 21:16
  • And does the Win8 system have Visual C++ 2010 Redistributable installed? x86 and / or x64? – Stein Åsmul Mar 11 '14 at 21:40
  • It has both VC++ x86 and x64 installed. – patrickbadley Mar 12 '14 at 12:53
  • Just to rule it out, can you try uninstalling both these runtimes (x86 and x64) and then try to install your non-working package? If this solves the problem, we may be on to a bigger problem with Wix / VC2010 runtime / Windows 8. Quite important to determine this (the problem is then with the runtimes, but manifest as an OS / Wix problem). – Stein Åsmul Mar 12 '14 at 15:38

7 Answers7

2

Just a couple of suggestions: 1. Valid guid includes it being all uppercase, so in case Windows 8 has tightened the rules, check that. 2. The appcompat overrides imply that there is some app compatibility thing going on, such as pretending that the system is (for example) Windows 7 or XP to have it install because otherwise it won't install on 8. Or Windows is faking that internally. See if the MSI file has some compatibility settings in Properties->Compatibility. That may be honking things up somewhere.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • The productcode is a valid guid (checked with Orca). I checked the compatibility properties and it did not have any set. I tried setting it use compatibility with previous version of windows and I get the same error. – patrickbadley Mar 10 '14 at 19:26
1

Did you log in with different users and work on or install the package on the Windows 8 machine? If so, the first thing I would do is to try the setup on a fresh Windows 8 machine. If it works, uninstall immediately, and let us know the result.

You should also check the existing Windows 8 machine and look in Add/Remove Programs to determine if your package is listed there. There could be numerous copies or nothing at all - your package does not contain ALLUSERS=1, which means it could be installed per-user by default. Try to uninstall any entries there.

See here for a per-user issue occuring in SCCM: http://social.technet.microsoft.com/Forums/en-US/b0ff996e-9235-4682-8b28-71011e84fe7e/uninstall-program-using-msi-error-exit-code-is-1605-the-execution-status-is-failurenonretry?forum=configmgrswdist

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • There is another user set up on the machine, but they never ran this installer. Besides that it is a fresh win8 machine. Note that it is occurring on 2 different win8 machines, but works fine on a win7 machine. The package is not currently installed in Add/Remove programs. I looked at your link and I think this is different because of the log file saying Product Code = ''. All of the examples in your link have actual product codes. – patrickbadley Mar 11 '14 at 17:04
1

When searching the internet for "Failing install, missing product code" there are several other entries for this, all have return code 1605.

Unfortunately, I could not read a definite solution or reason out of this. The only thing in common, is that all deal with .msm files. We remember: .msm files (merge modules) have no own ProductCode and are not alone installable. Only .msi files are installable.

My guess: Either in the process something tries to install a merge module directly, or there are build errors while merging the merge moduls, which lead to ths problem.

Philm
  • 3,448
  • 1
  • 29
  • 28
1

I have finally figured out that this was caused in the process of transferring the installer from my win7 machine to the win8 machine via flash drive. I transferred the same file via a network drive and of course it worked fine. Apparently the guid in the product code, or perhaps the entire installer, got corrupted on the flash drive some how causing the error.

Thank you to all that looked into this for me, I appreciate your time and apologize for the strange error!

patrickbadley
  • 2,510
  • 2
  • 29
  • 30
  • Do you still have that corrupted MSI? I am not so sure there isn't a bug in Wix behind all this. Is it possible to send the MSI for debugging? I have never seen an MSI that launches if it is corrupted. What file format was on the flash drive? – Stein Åsmul Mar 27 '14 at 18:36
0

I will try my answer kind of inverse:

First, I can give you a simple example when you get the first part of the error ("This action is only valid for.."). Try on command line the dummy uninstall of an not existing MSI:

msiexec /x {12345678-F0B2-36AF-8DF4-1DF6B63FC7B4}

(Acknowledge the question with yes, and see.)

So:

More information would be necessary, what (you think :-) your setup is doing.

The logfile excerpt is not enough. At least I am not sure, what the setup is doing here: Uninstalling, updating, repairing, patching ?

MSI is definitely called with an outdated MSI file or productcode in one of these scenarios. With a simple first install you don't get this message.

Philm
  • 3,448
  • 1
  • 29
  • 28
  • This happens when I just double click the installer, so it should do an install. But when I add logging I use this command line call msiexec /i "myinstaller.msi" /L*V installlog.txt. I've edited the question with full log – patrickbadley Mar 11 '14 at 13:48
  • Pls. see my new answer concerning .msm files in special. And: 1. Try to use a msiexec command line (alread with admin rights) and tell us the full line incl. file name you used, please. 2. Validate your MSI, please, e.g. with Orca – – Philm Mar 11 '14 at 16:57
  • The 1605 error in this case is ERROR_UNKNOWN_PRODUCT "This action is only valid for products that are currently installed." not the disk space one. – PhilDW Mar 11 '14 at 17:01
  • I'm not sure what your source on 1605 being no disk space available. From MSDN: ERROR_UNKNOWN_PRODUCT 1605 This action is only valid for products that are currently installed. I copied msi to c drive that has over 10 gigs of free space and run from there and still fails. I noted the full msiexec command used in my comment above. – patrickbadley Mar 11 '14 at 17:24
  • Just to clear this: There are two different kinds of 'Error codes' in MSI. While quickly searching, I just got the wrong one. If you look for example in the Error table, you see the 1605, what I meant. But I deleted the comment some minutes after writing it, what was not quickly enough to catch your two comments :-) In our case we are talking about ERROR_UNKNOWN_PRODUCT, that's right. – Philm Mar 12 '14 at 12:56
0

Other possibilities, not mutually exclusive:

  1. Your MSI is bizarre in some way that is not obvious. For example, you get bizarre errors if you install an MSI file that has no Component table. If there are no files or other components in the MSI it won't work right and the error will be strange. If it works on W7 this seems unlikely.

  2. The system is broken in some way. The registry entries about the product may be honked up. Windows might be looking on the system for other versions of the package code or product code and discovering erroneous data. This is more likely to happen if you've already installed a setup with the same package or product code. If that's the case, changing both product and package guids to new values may fix it. If you are doing repeated tests of the same MSI and it's failing badly, that may also cause a problem. Use VMs for MSI testing so you don't damage a hardware machine.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • if I change the product code in Orca to a guid from a previous installer (that works) then it works, but I don't know why this should matter, I'm using WiX and setting the product code to '*' so it should generate a random guid. – patrickbadley Mar 11 '14 at 18:57
  • What about the PackageCode? They get tracked on the system too, and if you don't change that for each build Windows will think something is still installed. – PhilDW Mar 12 '14 at 17:46
0

Just happened to me. Turns out our build script generates a unique Product UID on every build (to enforce major upgrades), and a recent change to the build script caused the UID to be empty.

yossiz74
  • 889
  • 1
  • 9
  • 16