I have an *.msi installation that uses Wix Extensions :
WixFirewallExtension (To create firewall exceptions)
WixNetFxExtention (To create Native Images at install time)
This msi fails with the error "Installation ended prematurely..." when attempting to install on Windows Server 2003 (both 32 and 64 bit). It installs on Server 2008/Windows 7 etc with no issue.
Removing the firewall and native image parts before building the msi allow it to install normally but obviously without the extra options in place.
Does anyone know what the issue could be?
Here is the part of the log file that shows the failure but it doesn't say why it failed.
Other Notes:
Removing the firewall part but leaving the native image part still causes failure which is causing me to believe that any operation that uses an Extension will be affected.
The firewall configuration is set to ignore failures.
I have confirmed the firewall is enabled and running.
I have tried installing from an Administrator command prompt but this makes no difference
It sounds like a bug in the WiX v3.8 toolset. There were issues in earlier builds where the new VS2012 compilers did not support Windows XP. That was fixed in WiX v3.8.422.0 or newer. If you are not running the latest build of WiX v3.8, I recommend upgrading and seeing if the issue is fixed. If you are running the latest build of WiX v3.8 then you might open a bug: http://wixtoolset.org/bugs.
Related
I have created an installation bundle using Wix3.5. Within a Bundle I created a Chain element to install prerequisites (VC Runtime and another inhouse application's installer) before installing the main application. The other inhouse application's installer was created with Installaware. Now the main installation fails after the Installaware installer finishes with this error message in the installer window:
0x80070064 - Cannot create another system semaphore
Excerpt from the installer log:
[2750:1D60][2019-02-28T16:08:58]e000: Error 0x80070064: Process returned error: 0x64
[2750:1D60][2019-02-28T16:08:58]e000: Error 0x80070064: Failed to configure per-user EXE package.
[2750:1D60][2019-02-28T16:08:58]i319: Applied execute package: CEInstaller, result: 0x80070064, restart: None
[2750:1D60][2019-02-28T16:08:58]e000: Error 0x80070064: Failed to execute EXE package.
However, it seems that the bundled application is installed correctly and can be run as well.
After trying to bundle some other installers instead for testing, it seems that this error only occurs with our Installaware inhouse applications but not with other third party installers. I went through the corresponding Installaware logs but did not find anything suspicious (As these are huge I refrained from posting them here for now).
I am pretty much stuck with this issue (also I am quite new working with Windows installer frameworks). Searching online did not deliver any helpful results so far, so I am grateful for any hints how to solve or further investigate this issue.
I currently use WIX (latest version) to package and bootstrap my Windows Form application.
I'm having an issue where my clients (using SOE workstations in a secure, enterprise environment) don't seem to have access to the MSI package cache directory when using the installer to perform a major upgrade. The installer completes successfully, but when they double click the desktop shortcut to launch the software, it displays the following two wix-generated dialogs:
I then get a 'Fatal error during installation.' message and the software won't open until it is completely uninstalled and reinstalled.
There are no issues at all with a fresh install. The current workaround is to manually uninstall old versions before installing the latest version.
I'm having trouble replicating this problem in my dev/test environments, and requesting my client to change their SOE configuration is out of the question.
Any advice would be most appreciated. I'm hoping there is a way to redirect the cache location to a UserData folder, or an entirely different approach to handling upgrades.
Thanks in advance for any guidance.
I'm using Visual Studio 2010 to build a MSI consisting of several DLL files set to register using vsdrpCOMSelfReg. There are also several Windows services that are installed using custom actions. My target machine is running Windows 32bit embedded standard.
My previous development box ran Windows 7 64 bit and I could build and install this MSI with no problem. I recently changed over to Windows 8 Pro, and when I build the MSI using the exact same code base I get "failed to register" errors on my DLLs, which then causes the services to fail installing.
I have a "Privileged" launch condition in the MSI that passes for both versions, so it looks like the required permissions are there.
If I set the DLL files to "vsdrpCOM" I can successfully register after the fact using regsvr32, but my services can't install because they rely on those DLLs being registered to complete their own installation.
What am I missing? What changed with DLL registry beween Windows 7 and Windows 8?
The usual cause for this is missing dependencies. ComSelfReg requires your Dlls to load and run during the install. If you have included the VC++ runtime support as merge modules and they install in WinSxS then they are not available until after your selfreg code needs to run. The symptoms are exactly those you'd get when the VC++ runtime is being installed from merge modules and do not already exist on the system - failure during the install and success with regsvr32 after the install.
In general you should look at using a tool that doesn't require code to install services. All the major install tools populate the ServiceInstall and ServiceControl tables in the MSI file because MSI will install services just fine, but VS setups don't use them for some reason.
The problem was in the dependencies automatically pulled in when I added the DLL Project Outputs. One of the detected dependencies was IPHLPAPI.DLL, pulled from C:\Windows\System32. This DLL was then copied into the application directory. In my install of Windows 8 Pro, IPHLPAPI.DLL is version 6.2.9200.16420. In Windows 7, this file is version 6.1.7600.16385.
I'm guessing my assemblies were referencing the Windows 8 version since that was in the local directory, and this caused registration and/or runtime errors. I excluded IPHLPAPI.DLL from the installer and everything is now running correctly, referencing the file in System32.
My Wix installer worked installing my program, but it's broken for uninstallation. A file is removed too early, and it's needed further down the line. The uninstaller fails and reverts its changes.
This means I can't remove the package from my machine, and hence can't install any further builds of my installer (a considerable inconvenience). How can I force removal of the package?
Update, Stein Åsmul: Injecting this newer list of cleanup approaches.
Find your package in C:\Windows\Installer, where Windows keeps copies of installed MSI packages. The names are generated randomly, so you'll have to look at the creation dates of the files.
Open the MSI file with Orca. (Unfortunately there is no simple download for the orca installer. You can get it by installing the "MSI Tools" of the Windows 10 SDK, and then searching for orca.msi in C:\Program Files (x86)\Windows Kits.)
Delete the offending custom action from the CustomAction table
Now you should be able to uninstall the package.
UPDATE: You can find the actual cache MSI file using Powershell. That was for one package, you can also get for all packages (scroll down to first screenshot).
This command usually works for me:
msiexec /fv installer.msi
It somewhat recaches the installer, so you can try again with a corrected one.
One time this command didn't work and I had to use Microsoft FixIt. It solved the problem (quite a shock for me).
Depending on the exact reason of the behavior you described, you might have at least a couple of options.
If the reason of the failure is a custom action which runs on uninstall, and this custom action is conditioned with some properties you can influence upon, you can try to pass the desired value via the command line:
msiexec /x {YOUR-PRODUCTCODE-HERE} RUNMYACTION=false
In this sample RUNMYACTION is a Windows Installer property which participates in a custom action condition, and if you pass false as its value, the action won't run.
Otherwise, you can fix the logic (or just disable the custom action explicitly) and build the new MSI package. Then upload it to that target machine, and run like this:
msiexec /i YourPackage.msi REINSTALL=ALL REINSTALLMODE=vomus
Here YourPackage.msi is a new fixed package, REINSTALL=ALL instructs the msiexec to re-install the product using this new package, and REINSTALLMODE=vomus (the v part of it) will re-cache the MSI package and you'll be able to remove it the normal way afterwards.
A side note: you should test your installation on a virtual machine in order not to risk your real one.
FYI: In Windows 8.1 the installers have been moved here: C:\ProgramData\Package Cache\
If you are really desperate and all solutions above don't work try
msizap.exe
This will erase all that your installer put on a machine
LITTLE WARNING
Don't run msizap without knowing what options you want to run it with (for a list of options run msizap /? first).
I used this little tool also from Microsoft
https://support.microsoft.com/en-us/help/17588/fix-problems-that-block-programs-from-being-installed-or-removed
Basically this tool can be used to "repair issues including corrupted registry keys that block you from installing or removing programs"
What it fixes:
Corrupted registry keys on 64-bit operating systems
Corrupted registry keys that control the update data
Problems that prevent new programs from being installed
Problems that prevent existing programs from being completely uninstalled or updated
Problems that block you from uninstalling a program through Add or Remove Programs (or Programs and Features) in Control Panel
It can be used for:
Windows 7
Windows 8
Windows 8.1
Windows 10
I usually just look for <Your Installer's Name>.msi or <Your Installer's Company Name> in the registry and delete some of the uninstall keys from some of the Products under the Windows installer trees and everything usually works fine and dandy afterwards, although this WOULD leave some stuff lying around like cached installers and possibly tons of other registry keys for each file installed, etc. but its ALWAYS worked for me when developing installers because honestly, who cares if one MSI is left over and cached somewhere? You're using the machine for development anyways, right?
Currently we have a scenario where there is a CD release (A), a middle patch (B) and a patch about to go out (C).
Installing (A) and patching directly to (C) works fine, but when the user patches up to (B) and then up to (C), they get error 2920 during the "Copying new files" action (first file in the sequence).
What's interesting is this issue doesn't occur on Windows 7, but occurs on Win2K3 and XP, which suggests to me that the different versions of Windows Installer are handling this scenario differently.
The current patch implementation creates admin installs, Prepares WiX source files for the MSP, creates the PCP file, then creates/signs the MSP file.
I've looked all over there hasn't been a determined cause/solution.
Thanks for your time.
I have never created a patch with using Wix, but I did with other authoring tools, and from what I know Windows Installer requires for a set of basic rules that must be followed in order for the path to be correctly created. One of them says this: "Do not change the order of files in a cabinet.". Have you checked that in your packages?
More details about the rules required for a patch can be found here:
http://msdn.microsoft.com/en-us/library/aa367850.aspx
After getting off the phone with Microsoft tech, it turns out that the issue happens regardless if you go from the baseline or middle patch. The issue itself manifested itself in the form of a Windows Installer version incompatibility.
Basically back when we released the CD release, we used VS2008. We migrated to VS2010 since then and the latest patch was made with files done in VS2010. VS2010 (from what the tech told me) has a dependency on Windows Installer 4.5.
Earlier OS's (such as 2K3 and XP) come with earlier versions of the Windows Installer, and therefore gave the error.
I ended up just bootstrapping the Windows Installer 4.5 packages and tweaking the lua scripts to personalize the user experience a bit more.