My "admin-image" style WiX test patches are failing to update the existing installation correctly. When using msiexec /lx, I get the following information related to patching "fi_executable.exe":
MSI (s) (88:E0) [12:32:41:716]: Baseline: Patch {E244BAC8-7E62-4406-889B-4B67A4EA7369} modified fi_executable.exe with full-file update.
MSI (s) (88:E0) [12:32:41:716]: Baseline: First patch for fi_executable.exe, saving native info.
MSI (s) (88:E0) [12:32:41:716]: Baseline: fi_executable.exe version for baseline at patch Native: 6.0.5803.11, 1033, 53840.
...
MSI (s) (88:E0) [12:32:41:716]: Baseline: fi_executable.exe version for baseline at patch {E244BAC8-7E62-4406-889B-4B67A4EA7369}: 6.0.5830.99, 1033, 47104.
...
MSI (s) (88:E0) [12:32:41:763]: {E244BAC8-7E62-4406-889B-4B67A4EA7369} File: fi_executable.exe ValData: 6.0.5830.99 1033 47104
...
MSI (s) (88:E0) [12:32:41:763]: Native File: fi_executable.exe ValData: 6.0.5803.11 1033 53840
...
MSI (s) (88:E0) [12:32:42:543]: The file represented by File table key 'fi_executable.exe' has no eligible binary patches
So even though the version number is changing, and Windows Installer notes that the patch modifies the file, Windows Installer is not recognizing that there should be an update to the executable.
Why?
Have you tested the upgrade with complete MSI files first before trying with the patch? Patching is just a delivery mechanism for upgrades packaged in a more compressed fashion, if the full MSI upgrade doesn't work, neither will the patch.
Try to install your patch with this command line:
msiexec /p patch.msp /qb REINSTALL=ALL REINSTALLMODE=omusa
Without these additional parameters, my patch failed to install correctly: it didn't update any files.
Related
I have used wix installer to create an installer for my c# application.
Installation happened fine, but I am not able to uninstall the application. I see below the logs
MSI (s) (78:AC) [15:32:06:199]: Machine policy value 'Debug' is 0
MSI (s) (78:AC) [15:32:06:199]: ******* RunEngine:
******* Product: C:\wix\Installer\\bin\Debug\MyService-Debug-x86.msi
******* Action:
******* CommandLine: **********
MSI (s) (78:AC) [15:32:06:207]: Machine policy value 'DisableUserInstalls' is 0
MSI (s) (78:AC) [15:32:06:326]: Note: 1: 2203 2:
C:\Windows\Installer\inprogressinstallinfo.ipi 3: -2147287038
MSI (s) (78:AC) [15:32:06:327]: Machine policy value
'LimitSystemRestoreCheckpointing' is 0
MSI (s) (78:AC) [15:32:06:327]: Note: 1: 1717 2: My Service (32bit)
MSI (s) (78:AC) [15:32:06:327]: Note: 1: 2205 2: 3: Error
MSI (s) (78:AC) [15:32:06:327]: Note: 1: 2228 2: 3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1717
MSI (s) (78:AC) [15:32:06:327]: Calling SRSetRestorePoint API.
dwRestorePtType: 1, dwEventType: 102, llSequenceNumber: 0, szDescription:
"Removed My Service (32bit)".
MSI (s) (78:AC) [15:32:06:330]: The System Restore service is disabled.
Returned status: 1058. GetLastError() returned: 1058
MSI (s) (78:AC) [15:32:06:332]: File will have security applied from OpCode.
MSI (s) (78:AC) [15:32:06:362]: SOFTWARE RESTRICTION POLICY: Verifying
package --> 'C:\wix\Installer\\bin\Debug\MyService-Debug-x86.msi' against
software restriction policy
MSI (s) (78:AC) [15:32:06:363]: Note: 1: 2262 2: DigitalSignature 3:
-2147287038
MSI (s) (78:AC) [15:32:06:363]: SOFTWARE RESTRICTION POLICY:
C:\wix\Installer\\bin\Debug\MyService-Debug-x86.msi is not digitally signed
MSI (s) (78:AC) [15:32:06:365]: SOFTWARE RESTRICTION POLICY:
C:\wix\Installer\\bin\Debug\MyService-Debug-x86.msi is permitted to run at
the 'unrestricted' authorization level.
MSI (s) (78:AC) [15:32:06:366]: MSCOREE not loaded loading copy from
system32
MSI (s) (78:AC) [15:32:06:374]: End dialog not enabled
MSI (s) (78:AC) [15:32:06:374]: Original package ==>
C:\wix\Installer\\bin\Debug\MyService-Debug-x86.msi
MSI (s) (78:AC) [15:32:06:374]: Package we're running from ==>
C:\Windows\Installer\152e2e.msi
While creating an installer, I never thought of digitally signing and all. Is it anything to do with signing? Totaly lost and need help
I have even tried with running uninstallation using the command line (admin mode) but no luck
msiexec.exe /x "C:\wix\Installer\\bin\Debug\MyService-Debug-x86.msi" /L*V "C:\work\wix.log"
it says
Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel.
I might have to rebuild the installer code before uninstalling. Is it possible that some "guid" has changed related to the installer? anything I have to check inside registry?
Updated the question with Wix Code
The issue started appearing after I added custom actions. The responsibility of custom action is to get parameters from the installer and update the appsettings.json. but this uninstallation issue not allowing me to continue implementation.
<Property Id="APPLICATIONLOG.PATHFORMAT" Secure="yes"/>
<Binary Id="CustomActionDLL"
SourceFile="..\..\Installer\CustomActions\bin\$(var.Configuration)\CustomAction.CA.dll" />
<CustomAction Id="SetPropertyAppLogPathId"
Property="SetPropertyAppLogPathProperty"
Value="APPLICATIONLOG.PATHFORMAT=[APPLICATIONLOG.PATHFORMAT]"/>
<CustomAction Id="SetPropertyAppLogPathProperty"
BinaryKey="CustomActionDLL"
DllEntry="UpdateConfigurationsAction"
Execute="deferred"
Return="check"
Impersonate="no" />
<InstallExecuteSequence>
<Custom Action="SetPropertyAppLogPathId" Before="SetPropertyAppLogPathProperty"><![CDATA[NOT Installed]]></Custom>
<Custom Action="SetPropertyAppLogPathProperty" After="InstallFiles"></Custom>
</InstallExecuteSequence>
My Custom Action c# code
public class CustomActions
{
public static string ApplicationPath { get; private set; }
[CustomAction]
public static ActionResult UpdateConfigurationsAction(Session session)
{
try
{
session.Log("Begin UpdateConfigurationsAction");
ApplicationPath = session.CustomActionData["APPLICATIONLOG.PATHFORMAT"];
session.Log("Application Log Path is: " + ApplicationPath);
return ActionResult.Success;
}
catch (Exception e)
{
session.Log("Error in UpdateConfigurationsAction " + e.Message);
return ActionResult.Failure;
}
}
}
Issue Resolved
The issue was with the custom action. After making proper InstallExecuteSequence it worked!
Will update in solution section
Cross-Link: How to clean out broken uninstalls.
Microsoft FixIt: Before trying anything else, perhaps try the Microsoft FixIt tool to see if you can get rid of any
dangling installations. If unsuccessful check further down for other
approaches.
Debugging & Logging: Next fix your custom action in the package based on custom action debugging (I recommend the Advanced Installer MSI CA debugging video, it is quick and a good "hello debugger" session) and gathering logging information.
Countermeasure: Finally, maybe add a property to suppress the custom action from running as described here ("Adding Condition" section).
This is the simplest
idea I know of to suppress custom actions from running on uninstall - you just set the property involved when needed to suppress the custom action if it crashes. >
I would use it for all my custom actions - in fact - so I can suppress them all (or
maybe one by one) - especially for uninstall scenarios where you run into "catch 22" situations (unable to install, upgrade or uninstall due to custom action bugs).
Dangling Installations: In order to detect all related, dangling installations (if any), you can use this approach: Unable to uninstall program from WiX created MSI (enumerate all products with the same upgrade code).
I will add these links for now in case you find that dangling version:
wix - custom action dialogbox on silent uninstall of application
I screwed up, how can I uninstall my program?
When trying to remove an MSI which crashes on uninstall, the central question is how many computers are involved? If it is just one, then hacking the cached MSI database may be acceptable, otherwise you should create a patch package to fix the uninstall sequence and then trigger uninstall the normal way.
Links:
Throwing in one more link: WIX does not uninstall older version. It is possible to have installations per-user or per-machine.
I am running Wix 3.11.1 and when trying to do an upgrade the upgrade goes into maintenance mode and leaves two entries in Add/Remove programs list.
A short version of Product.wxs has the following:
<Product Id="*" Name="Boo" Language="1033" Version="1.1.0.0" Manufacturer="Foo"
UpgradeCode="PUT-GUID-HERE">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine"/>
<MajorUpgrade AllowDowngrades="no" AllowSameVersionUpgrades="yes"
DowngradeErrorMessage="!(loc.NewerVersionInstalled)" />
Upgrade Code:
3F55CE54-8409-4918-9906-D8AD18794BFC
And the product and package code are:
1.0
Product Code FC49F622-02E6-40D9-ACD9-92BDD4AF5979
Package Code 6C49FAA1-5B11-4173-80A7-A7B3FA4313AE
1.1
Product Code 4871555F-F369-4159-9EF0-4BBDF07B6842
Package Code 3594D7C2-D5AC-4A41-A8C6-6E3D63C6ACA0
When I run the installer with logging I get the log information shown below.
When the upgrade code is the same and product and package codes are different, and the version is incremented in the first three digits I thought an upgrade should occur but is isn't. Also both versions are per-machine so that should not stop the removal of previous version. The log shows maintenance mode and never performs removal of previous version. I have an upgrade table in the msi and it shows the max value of 1.1 and WIX_UPGRADE_DETECTED as the action. Does anyone know what would cause this to enter maintenance mode rather do a major upgrade?
Log File
MSI (s) (68:9C) [15:04:38:423]: Doing action: RemoveExistingProducts
Action 15:04:38: RemoveExistingProducts. Removing applications
Action start 15:04:38: RemoveExistingProducts.
RemoveExistingProducts: Application: {FC49F622-02E6-40D9-ACD9-92BDD4AF5979}, Command line: UPGRADINGPRODUCTCODE={4871555F-F369-4159-9EF0-4BBDF07B6842} CLIENTPROCESSID=8344 CLIENTUILEVEL=0 MSICLIENTUSESEXTERNALUI=1 REMOVE=ALL
MSI (s) (68:BC) [15:04:38:423]: Resetting cached policy values
MSI (s) (68:BC) [15:04:38:423]: Machine policy value 'Debug' is 0
MSI (s) (68:BC) [15:04:38:423]: ******* RunEngine:
******* Product: {FC49F622-02E6-40D9-ACD9-92BDD4AF5979}
******* Action:
******* CommandLine: **********
MSI (s) (68:BC) [15:04:38:423]: Note: 1: 2203 2: C:\WINDOWS\Installer\inprogressinstallinfo.ipi 3: -2147287038
MSI (s) (68:BC) [15:04:38:423]: Machine policy value 'LimitSystemRestoreCheckpointing' is 0
MSI (s) (68:BC) [15:04:38:423]: Note: 1: 1717 2: Boo
MSI (s) (68:BC) [15:04:38:423]: Calling SRSetRestorePoint API. dwRestorePtType: 1, dwEventType: 102, llSequenceNumber: 0, szDescription: "Removed Boo".
MSI (s) (68:BC) [15:04:38:439]: The call to SRSetRestorePoint API succeeded. Returned status: 0, llSequenceNumber: 45.
MSI (s) (68:BC) [15:04:38:439]: End dialog not enabled
MSI (s) (68:BC) [15:04:38:439]: Original package ==> C:\WINDOWS\Installer\1179bb4.msi
MSI (s) (68:BC) [15:04:38:439]: Package we're running from ==> C:\WINDOWS\Installer\1179bb4.msi
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: Uninstall Flags override found.
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: Uninstall VersionNT override found.
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: Uninstall ServicePackLevel override found.
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: looking for appcompat database entry with ProductCode '{FC49F622-02E6-40D9-ACD9-92BDD4AF5979}'.
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: no matching ProductCode found in database.
MSI (s) (68:BC) [15:04:38:439]: Machine policy value 'DisablePatch' is 0
MSI (s) (68:BC) [15:04:38:439]: Machine policy value 'AllowLockdownPatch' is 0
MSI (s) (68:BC) [15:04:38:439]: Machine policy value 'DisableLUAPatching' is 0
MSI (s) (68:BC) [15:04:38:439]: Machine policy value 'DisableFlyWeightPatching' is 0
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: looking for appcompat database entry with ProductCode '{FC49F622-02E6-40D9-ACD9-92BDD4AF5979}'.
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: no matching ProductCode found in database.
MSI (s) (68:BC) [15:04:38:439]: Transforms are not secure.
MSI (s) (68:BC) [15:04:38:439]: Command Line: UPGRADINGPRODUCTCODE={4871555F-F369-4159-9EF0-4BBDF07B6842} CLIENTPROCESSID=8344 CLIENTUILEVEL=0 MSICLIENTUSESEXTERNALUI=1 REMOVE=ALL
MSI (s) (68:BC) [15:04:38:439]: PROPERTY CHANGE: Adding PackageCode property. Its value is '{6C49FAA1-5B11-4173-80A7-A7B3FA4313AE}'.
MSI (s) (68:BC) [15:04:38:439]: Product Code passed to Engine.Initialize: '{FC49F622-02E6-40D9-ACD9-92BDD4AF5979}'
MSI (s) (68:BC) [15:04:38:439]: Product Code from property table before transforms: '{FC49F622-02E6-40D9-ACD9-92BDD4AF5979}'
MSI (s) (68:BC) [15:04:38:439]: Product Code from property table after transforms: '{FC49F622-02E6-40D9-ACD9-92BDD4AF5979}'
MSI (s) (68:BC) [15:04:38:439]: Product registered: entering maintenance mode
Update:
This is indeed a bundle install. I looked at the msi being the culprit because I thought that Wix bundle would use msiexec to perform the uninstall.
In our build we use the search term "0.0.0.0" for the version in the bundle and msi then we do a replace with the correct version, and at the end of the build we revert the Bundle.wxs and Product.wxs.
When the installer is being worked on the developer must comment out the revert, in the build file, in order to work on the files. When the developer is done they need to set the version back to "0.0.0.0". In one of the installer checkins someone had to forgotten to change back to "0.0.0.0".
I tried the msi for the two versions by themselves, and upgrade did indeed remove the entry for the original install. However the bundle upgrade still leaves second entry, even though the version is correct.
The log shows the upgrade was successful, installing the new product and removing the old one. The most likely explanation for the two entries in Programs&Features is that there is one for the actual MSI product and another from the WiX bootstrapper. You probably need to suppress the MSI one with ARPSYSTEMCOMPONENT=1 or with WiX bootstrapper support for suppressing the MSI's entry.
Short Version
Many Instances: I think there are many versions of your package installed in many instances "on top of each other" - some of which are hidden from Add / Remove Programs because of the ARPSYSTEMCOMPONENT=1 setting being specified in (some of) the package(s). One of the installed instances has the same product code as the package you are trying to install - this triggers maintenance mode - since the product code is already registered as installed.
Package Code Confusion?: It is also possible that you have installed two or more versions of the same MSI with identical package codes (as opposed to product codes). This always causes mysterious problems - for example the problem you are seeing with maintenance mode (identical package GUIDs mean two different MSI files will be treated as the same file by definition - since the GUIDs are the same - X-Files ensues as msiexec.exe goes behind your back and runs from the old, cached MSI and not your new MSI).
Bundle?: As Phil writes, it could be a WiX bundle problem as well. Maybe try the script towards the bottom first to get a full list of what is installed - hidden from view or not.
Detailed Version
Possible Cause: It seems you are setting ARPSYSTEMCOMPONENT = 1 which will hide the setup from Add / Remove Programs (ARP). As far as I can see there are numerous package and product codes in the log that do not match the ones you specify in your question. It seems you may have several older, test versions installed on the system that could also be hidden from ARP, but are still installed on the box. Not sure why you say the current version shows up in ARP though? With ARPSYSTEMCOMPONENT set it should not do so.
Virtuals: As the motto always goes: test on virtuals when you see weird problems - in order to determine if you have an unclean test environment. Virtuals testing is crucial for me, but I often do it too late.
MSDN: ARPSYSTEMCOMPONENT.
UPDATE:
Culprit Mechanism: When you set the product code to auto-generate, every build will be able to install without maintenance mode showing up - even without authoring the upgrade table at all. When you combine this with hiding from Add / Remove Programs you suddenly can't tell what prior versions were installed. Duplicates installed on top of each other could pile up as you do test installs.
Since you do seem to auto-generate the product code, you should never experience the current problem: maintenance mode. This leads me to suspect a package code duplication problem. Or a bundle problem, as suggested by Phil. I have too little experience with bundles. Could it be a bundle bug? Or even a WiX bug?
Manual Uninstall: Maybe try to use the VBScript you can find here to export a list of MSI product codes currently installed on the system (whether they are hidden or not): How can I find the product GUID of an installed MSI setup? (towards bottom, under "Alternate Tools, section 3".
UPDATE: please see the inlined and modified script version below instead.
Once you have the list, try to uninstall the undesired test packages using:
msiexec.exe /x [ProductCode]
keep going with uninstalls until you have a "clean box".
Major Upgrade with full version spread: Alternatively, you can set a wide version range (min / max version) for your upgrade table to see if you can uninstall all existing versions with a regular major upgrade. Frankly I have never taken the time to test uninstall of multiple prior versions using major upgrades, but as far as I know it should work. N.B!: I don't think this will work if you have package code duplication.
Uninstall Related Products: Another answer showing how to uninstall all products sharing the same upgrade code. Note the disclaimer that a reboot could be triggered automatically when run in silent mode: Powershell: Uninstall application by UpgradeCode.
Uninstall By Product Name: And less sensible, but I will just add a link for safekeeping. Here is how you can uninstall an MSI package by product name: Is there an alternative to GUID when using msiexec to uninstall an application?
List All Installed MSI Products
UPDATE: Come to think of it, let me inline the linked script above with a couple of additions - this adds headers and publisher and package code to the export. This script should show all installed packages, including those hidden from Add / Remove Programs (if you also need Upgrade Code, then this is a little more complicated for technical reasons, here is a description of how it can be done in a clunky way - that link in turn has further links for how to retrieve upgrade codes with Powershell):
' Retrieve all ProductCodes (with ProductName and ProductVersion)
Set fso = CreateObject("Scripting.FileSystemObject")
Set output = fso.CreateTextFile("msiinfo.csv", True, True)
Set installer = CreateObject("WindowsInstaller.Installer")
output.writeline ("Product Code,Product Name,Product Version,Package Code, Publisher")
On Error Resume Next ' we ignore all errors
For Each product In installer.ProductsEx("", "", 7)
productcode = product.ProductCode
name = product.InstallProperty("ProductName")
version=product.InstallProperty("VersionString")
packagecode=product.InstallProperty("PackageCode")
publisher=product.InstallProperty("Publisher")
output.writeline (productcode & ", " & name & ", " & version & ", " & packagecode & ", " & publisher)
Next
output.Close
Usage:
Copy the script and paste into a *.vbs file on your desktop, and try to run it by double clicking. Your desktop must be writable for you, or you can use any other writable location.
The output file is created in the folder where you run the script from (folder must be writable). The output file is called msiinfo.csv.
Double click the file to open in a spreadsheet application, select comma as delimiter on import - OR - just open the file in Notepad or any text viewer.
The content in the spreadsheet should be formatted in columns, if not do a manual file open and import the file selecting comma as the delimiter for the CSV file (comma separated values). Doing so will yield full spreadsheet capabilities, such as sorting by column - for example Publisher - so you see all your setups next to each other.
I am adding to build to your WiX installer to include a multi-website deployment based on custom dialog selection.
I am running into this issue when i run in debug mode and not sure how to tackle the problem to find what the issue is, I am getting a Failed to load XML Error:
MSI (s) (D0:60) [10:25:14:945]: Executing op:
ActionStart(Name=ExecXmlFile,,) Action 10:25:14: ExecXmlFile.
MSI (s) (D0:60) [10:25:14:960]: Executing op:
CustomActionSchedule(Action=ExecXmlFile,ActionType=3073,Source=BinaryData,Target=ExecXmlFile,CustomActionData=20C:\Program
Files\Company Name,
Inc\18.4.007\Navigator\bin\hibernate.cfg.xml30//property[#name='connection.connection_string_name']Workbench_PROD2130/
+ MORE SIMILAR STUFF
MSI (s) (D0:30) [10:25:14:976]: Invoking remote custom action. DLL:
C:\Windows\Installer\MSI5E32.tmp, Entrypoint: ExecXmlFile
MSI (s) (D0:B0) [10:25:14:976]: Generating random cookie.
MSI (s) (D0:B0) [10:25:14:976]: Created Custom Action Server with PID
3980 (0xF8C).
MSI (s) (D0:8C) [10:25:15:163]: Running as a service.
MSI (s) (D0:8C) [10:25:15:163]: Hello, I'm your 32bit Elevated custom
action server.
ExecXmlFile: Error 0x8007006e: failed to load XML file:
Since your error occurs when running a custom action, I would add a Debugger.Launch(); for C# or s.t. equivalent for other languages at the very start of your custom action method. This would allow you to debug in Visual Studio as usual.
The only advice I can give you is to use Orca, which is a low-level tool for creating and editing MSI file. At least it will validate your msi and show you any errors or warnings it finds.
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.
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.
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
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.
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!
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.
Other possibilities, not mutually exclusive:
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.
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.
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.
I'm having a problem with installer which happens only if previous version exist on the computer. Installer created using WiX-toolset.
If previous version exists, my installer uninstalls it successfully but then ends prematurely. If started again installs with no problems. If no previous version installs successfully.
Log file ends with following lines
Product: xxxxx -- Installation failed.
MSI (c) (AC:3C) [22:53:59:388]: Windows Installer installed the product. Product Name: xxxxx. Product Version: 1.2.0.0. Product Language: 1033. Manufacturer: xxxxx xxx. Installation success or error status: 1603.
MSI (c) (AC:3C) [22:53:59:389]: Grabbed execution mutex.
MSI (c) (AC:3C) [22:53:59:389]: Cleaning up uninstalled install packages, if any exist
MSI (c) (AC:3C) [22:53:59:393]: MainEngineThread is returning 1603
MSI (c) (AC:80) [22:53:59:400]: RESTART MANAGER: Previously shut down applications have been restarted.
MSI (c) (AC:80) [22:53:59:401]: RESTART MANAGER: Session closed.
The log files is huge. There are some suspicious lines like
DEBUG: Error 2911: Could not remove the folder C:\Config.Msi\.
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2911. The arguments are: C:\Config.Msi\, ,
There are no such directory.
Looking into log file I have a feeling that installer doesn't start after uninstallation instead it is trying to start application, which is set for automatic run after installation. This returns error 1603
MSI (s) (2C:08) [22:53:51:928]: PROPERTY CHANGE: Deleting UpdateStarted property. Its current value is '1'.
Action ended 22:53:51: InstallFinalize. Return value 1.
MSI (s) (2C:08) [22:53:51:929]: Doing action: LaunchApplication
MSI (s) (2C:08) [22:53:51:929]: Note: 1: 2205 2: 3: ActionText
Action 22:53:51: LaunchApplication.
Action start 22:53:51: LaunchApplication.
MSI (s) (2C:F8) [22:53:51:931]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI87DC.tmp, Entrypoint: WixShellExec
MSI (s) (2C:DC) [22:53:51:931]: Generating random cookie.
MSI (s) (2C:DC) [22:53:51:932]: Created Custom Action Server with PID 8100 (0x1FA4).
MSI (s) (2C:00) [22:53:51:947]: Running as a service.
MSI (s) (2C:00) [22:53:51:948]: Hello, I'm your 32bit Impersonated custom action server.
WixShellExec: Error 0x80070002: ShellExec failed with return code 2
WixShellExec: Error 0x80070002: failed to launch target
CustomAction LaunchApplication returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 22:53:51: LaunchApplication. Return value 3.
Action ended 22:53:51: INSTALL. Return value 3.
Any help is appreciated. Any ideas what to look for in log file in my case.
I think I found what is happening. In my previous installer I used a custom action to run program after installation like this
<CustomAction Id="LaunchApplication" BinaryKey="WixCA" DllEntry="WixShellExec" Impersonate="yes"/>
<InstallExecuteSequence>
<Custom Action="LaunchApplication" After="InstallFinalize"/>
</InstallExecuteSequence>
!!! I should use condition NOT Installed to run this action only on installation, but not during uninstallation. Like this
<CustomAction Id="LaunchApplication" BinaryKey="WixCA" DllEntry="WixShellExec" Impersonate="yes"/>
<InstallExecuteSequence>
<Custom Action="LaunchApplication" After="InstallFinalize">NOT Installed</Custom>
</InstallExecuteSequence>
If I used it in my previous version I would not have this problem now.