Using WiX 3.11 I've developed a simple installation file which installs one DLL in the global assembly cache:
<Directory Id="TARGETDIR" Name="SourceDir">
<Component Id="CMP_ABC"
Guid="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
Permanent="no"
Shared="yes" >
<File Id="File_ABC"
Assembly=".net"
Source="ABC.dll"
KeyPath="yes"
Vital="yes"/>
</Component>
</Directory>
Installation works and the file is placed in the GAC_32 folder. When trying to uninstall the package and the file is currently in use by a different process (loaded in Visual Studio for example), the file does not get uninstalled and the WiX installation package does not return any error:
MSI (s) (68:EC) [09:24:58:210]: MsiProvideAssembly is returning: 1607
MSI (s) (68:EC) [09:24:58:429]: Assembly Error:The process cannot access the file because it is being used by another process.
MSI (s) (68:EC) [09:24:58:429]: Note: 1: 1935 2: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} 3: 0x80070020 4: IAssemblyCache 5: UninstallAssembly 6: ABC,version="X.YY.ZZ.0",culture="neutral",publicKeyToken="XXXXXXXXXXXXXXXX",processorArchitecture="x86"
MSI (s) (68:EC) [09:24:58:429]: Note: 1: 2205 2: 3: Error
MSI (s) (68:EC) [09:24:58:429]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1935
The last line however always shows
MSI (c) (30:88) [09:24:59:505]: Product: ABC -- Configuration completed successfully.
Is it possible to fail the uninstallation if the file is currently in use or for some other reason cannot be removed?
Related
Found a similar question, but the the accepted "answer" is not actually an answer at all: MSIEXEC: "Executing op: ShortcutRemove" step is very slow
Is there a know issue with Wix / Windows Installer being very slow when uninstalling shortcuts?
I have a msi project that creates a lot (85+) of shortcuts in my installation folder. When I install, all goes very quickly and completes successfully in under a minute. However, when I uninstall, it takes in excess of 6-8 minutes. Computer is physical machine with a fast SSD. tested on Windows 10 Pro and Windows Server 2019.
All shortcuts are created on the local C: drive and target files on that same drive.
I am not very experienced with Wix and the Windows Installer, but the uninstall log looks clean to me. Only the ShortcutRemove operations taking longer then expected and every one has "Note: 1: 2318 2: C:\Config.Msi\??????.rbf" (File does not exist). Each ShortcutRemove operation takes 4 to 5 seconds, which obviously adds up because of the (admittedly high) number of shortcuts that I need to create.
From the log, there is about 3 seconds delay between every line showing error "Note: 1: 2318" and the following "Executing op: SetTargetFolder" line.
The project has had this many shortcuts for many years, but I only started noticing the slow down for uninstalls in mid 2019.
Build Environment / Tools
Visual Studio Pro 2017
Wix version 3.11.2.4516
Windows Installer. V 5.0.19041.1
UPDATE 1 - 28-Aug-2020
I suspect that this may be an issue with a Windows o/s patch or new security policy, because I have been using the same .msi and Wix project for a few years and did not see the slow down on Windows 10 prior to mid 2019 - the related post I referenced at the top is from that period as well. I also suspect that this may be happening to many other .msi projects, but the developers are not noticing because they only have a very small (normal) number of shortcuts.
Additionally, I just tested on Windows Server 2016 and found that uninstall is NOT slow on that o/s at all!
FAST: Microsoft Windows Server 2016 Datacenter, Version 1607 (OS Build 14393.3564)
Slow: Microsoft Windows Server 2019 Datacenter, Version 1809 (OS Build 17763.1397)
Slow: Microsoft Windows 10 Pro, Version 2004 (OS Build 19041.450)
This is an extract of the uninstall log:
MSI (s) (98:54) [13:09:59:071]: Using source file security for destination.
MSI (s) (98:54) [13:09:59:073]: Note: 1: 2318 2: C:\Config.Msi\13a736b0.rbf
MSI (s) (98:54) [13:10:01:503]: Executing op: SetTargetFolder(Folder=23\My Tiny Utilities\)
MSI (s) (98:54) [13:10:01:508]: SHELL32::SHGetFolderPath returned: C:\ProgramData\Microsoft\Windows\Start Menu\Programs
MSI (s) (98:54) [13:10:01:509]: Executing op: ShortcutRemove(Name=lddyopzj|Touch)
MSI (s) (98:54) [13:10:01:513]: Verifying accessibility of file: Touch.lnk
MSI (s) (98:54) [13:10:01:515]: Using source file security for destination.
MSI (s) (98:54) [13:10:01:516]: Note: 1: 2318 2: C:\Config.Msi\13a736b1.rbf
MSI (s) (98:54) [13:10:03:964]: Executing op: SetTargetFolder(Folder=C:\MyTinyUtilities\Shortcuts\)
MSI (s) (98:54) [13:10:03:966]: Executing op: ShortcutRemove(Name=n5w0rmgl|Touch)
MSI (s) (98:54) [13:10:03:970]: Verifying accessibility of file: Touch.lnk
MSI (s) (98:54) [13:10:03:974]: Using source file security for destination.
MSI (s) (98:54) [13:10:03:977]: Note: 1: 2318 2: C:\Config.Msi\13a736b2.rbf
This is an extract of my shortcut creation script/code:
<!--Start Menu Shortcuts-->
<Fragment>
<DirectoryRef Id="DirShortcutsStartMenu">
<Component Win64="no" Id="CMP_Shortcuts_StartMenu" Guid="86F485AE-B257-4E8A-8D06-59EE9161B8F9">
<RegistryValue Root="HKCU" Key="Software\MyTinyUtil" Name="Start Menu Created" Type="string" Value="Yes" KeyPath="yes" />
<Shortcut Id="SM_Touch" Name="Touch" Description="Update file modified date" Target="[MTUINSTALLROOT]Touch.exe" />
...
I create about 10 shortcuts on the Start menu path
...
<RemoveFolder Id="Remove01" On="uninstall" />
</Component>
</DirectoryRef>
</Fragment>
<!-- Shortcut in installation Folder-->
<Fragment>
<DirectoryRef Id="DirShortcutsInstallFolder">
<Component Win64="no" Id="CMP_Shortcuts_InstallFolder" Guid="102EC0F4-03BD-48E9-8086-6D5DA4624FA3">
<RegistryValue Root="HKCU" Key="Software\MyTinyUtil" Name="Duplicate Shortcuts" Type="string" Value="yes" KeyPath="yes" />
<Shortcut Id="IF_Touch" Name="Touch" Description="Update file modified date" Target="[MTUINSTALLROOT]Touch.exe" Directory="Dir_C_Shortcuts_File_Utils" />
...
I create in excess of 85 shortcuts in a sub-folder of my installation folder.
...
<RemoveFolder Id="Remove02" On="uninstall" />
</Component>
</DirectoryRef>
</Fragment>
I also experienced the same issue. And solved.
Try to have no more than 5 pinned items on taskbar.
I think the uninstallation will complete faster if you reduce the number of pins.
Symptoms
Users sometimes get one of the following error messages during uninstall through add/remove programs (or "Apps & Features" settings app):
Error 1316. The specified account already exists.
Error 1316. A network error occurred while attempting to read from the
file: C:\WINDOWS\Installer\NameOfOriginalSetup.msi
Actually these two are the exact same error, the first message only shows up when KB2918614 (aka "Secure Repair" patch) is installed and the product is not white-listed. It's just that the error code gets misinterpreted as a general system error instead of the actual MSI error in this case. Otherwise, KB2918614 doesn't matter.
Error 1406. Could not write value to key . Verify that you have sufficient access to that key, or contact your support personnel.
Seems to be less common. As the message box contains an "Ignore" button, which allows the uninstall to continue anyway, users are propably less inclined to report this error.
Log File
Obtained uninstall log file through msiexec -x {ProductCode} -l*vx LogFile.txt. Searching for "value 3" yields the part around the error location:
MSI (s) (B0:9C) [15:18:10:427]: Executing op: FeatureUnpublish(Feature=ProductFeature,,Absent=2,Component=iJm4+0tc4#uTvD')YKUXZ{NA8`o569(2MdBLg[rJ)
MSI (s) (B0:9C) [15:18:10:428]: Note: 1: 1402 2: UNKNOWN\Installer\Features\AFCEC7274CC7C0441A85705C47554DD5 3: 2
MSI (s) (B0:9C) [15:18:10:428]: Executing op: ActionStart(Name=InstallFiles,Description=Copying new files,Template=File: [1], Directory: [9], Size: [6])
MSI (s) (B0:9C) [15:18:10:428]: Executing op: ProgressTotal(Total=5,Type=0,ByteEquivalent=1)
MSI (s) (B0:9C) [15:18:10:428]: Executing op: SetTargetFolder(Folder=C:\Program Files\zett42\SpuriousFeatureAdvTest1\)
MSI (s) (B0:9C) [15:18:10:428]: Executing op: SetSourceFolder(Folder=1\zett42\xipmcfby\|zett42\SpuriousFeatureAdvTest1\)
MSI (s) (B0:9C) [15:18:10:428]: Executing op: ChangeMedia(,MediaPrompt=Please insert the disk: ,MediaCabinet=1\cab1.cab,BytesPerTick=65536,CopierType=1,,,SignatureRequired=0,,,IsFirstPhysicalMedia=1)
MSI (s) (B0:9C) [15:18:10:428]: Executing op: RegisterSharedComponentProvider(,,File=File2.txt,Component={3F28EEDB-866D-4201-8173-12532C657B6C},,ProductCode={727CECFA-7CC4-440C-A158-07C57455D45D},ProductVersion=1.0.0,PatchSize=0,PatchAttributes=0,PatchSequence=0,SharedComponent=0,IsFullFile=0)
MSI (s) (B0:9C) [15:18:10:428]: Executing op: FileCopy(SourceName=File2.txt,SourceCabKey=File2.txt,DestName=File2.txt,Attributes=512,FileSize=5,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=58982400,HashOptions=0,HashPart1=1397189395,HashPart2=108432067,HashPart3=-1009892414,HashPart4=374579663,,)
MSI (s) (B0:9C) [15:18:10:428]: File: C:\Program Files\zett42\SpuriousFeatureAdvTest1\File2.txt; To be installed; Won't patch; No existing file
MSI (s) (B0:9C) [15:18:10:428]: Resolving source.
MSI (s) (B0:9C) [15:18:10:428]: Using cached product context: machine assigned for product: AFCEC7274CC7C0441A85705C47554DD5
MSI (s) (B0:9C) [15:18:10:428]: Using cached product context: machine assigned for product: AFCEC7274CC7C0441A85705C47554DD5
MSI (s) (B0:9C) [15:18:10:429]: Resolving source to launched-from source.
MSI (s) (B0:9C) [15:18:10:429]: Setting launched-from source as last-used.
MSI (s) (B0:9C) [15:18:10:429]: PROPERTY CHANGE: Adding SourceDir property. Its value is 'C:\WINDOWS\Installer\'.
MSI (s) (B0:9C) [15:18:10:429]: PROPERTY CHANGE: Adding SOURCEDIR property. Its value is 'C:\WINDOWS\Installer\'.
MSI (s) (B0:9C) [15:18:10:429]: PROPERTY CHANGE: Adding SourcedirProduct property. Its value is '{727CECFA-7CC4-440C-A158-07C57455D45D}'.
MSI (s) (B0:9C) [15:18:10:429]: SOURCEDIR ==> C:\WINDOWS\Installer\
MSI (s) (B0:9C) [15:18:10:429]: SOURCEDIR product ==> {727CECFA-7CC4-440C-A158-07C57455D45D}
MSI (s) (B0:9C) [15:18:10:429]: Using cached product context: machine assigned for product: AFCEC7274CC7C0441A85705C47554DD5
MSI (s) (B0:9C) [15:18:10:429]: Determining source type
MSI (s) (B0:9C) [15:18:10:429]: Note: 1: 2203 2: C:\WINDOWS\Installer\SpuriousFeatureAdvTest1.msi 3: -2147287038
MSI (s) (B0:9C) [15:18:10:429]: Note: 1: 1316 2: C:\WINDOWS\Installer\SpuriousFeatureAdvTest1.msi
MSI (s) (B0:9C) [15:18:10:429]: SECREPAIR: Error determining package source type
MSI (s) (B0:9C) [15:18:10:429]: SECUREREPAIR: SecureRepair Failed. Error code: 524FD15800
MSI (s) (B0:9C) [15:18:11:146]: Note: 1: 2205 2: 3: Error
MSI (s) (B0:9C) [15:18:11:146]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709
MSI (s) (B0:9C) [15:18:11:146]: Product: zett42 SpuriousFeatureAdvTest1 -- Error 1316. Das angegebene Konto ist bereits vorhanden.
MSI (c) (C4:38) [15:18:10:436]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
Error 1316. Das angegebene Konto ist bereits vorhanden.
(The last log line is "The specified account already exists." in German.)
As can be seen from the log, the uninstallation tries to actually copy the file "File2.txt" to the hard drive (look for the FileCopy entry). This doesn't seem to make sense and of course it fails when the source is not available.
Also interesting are the feature and component states which are revealed further up in the log:
MSI (s) (B0:9C) [15:18:10:387]: Feature: ProductFeature; Installed: Advertise; Request: Absent; Action: Absent
MSI (s) (B0:9C) [15:18:10:387]: Component: File1; Installed: Absent; Request: Null; Action: Null; Client State: Unknown
MSI (s) (B0:9C) [15:18:10:387]: Component: File2; Installed: Local; Request: Null; Action: Local; Client State: Absent
Note that feature "ProductFeature" has "Installed: Advertise" state, though the feature was installed locally. The "Action: Local" for component "File2" matches what we saw in the log, that is Windows Installer wants the file installed locally during uninstall! Again, this doesn't make any sense to me.
Registry Defects
I've found out that on problem machines, random component registry keys of the product that could not be uninstalled, are missing:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\<ComponentKey>
After manually adding the missing registry key, including all values from a clean installation state, the product could be successfully uninstalled.
It turns out that when any of the component registry keys are missing, Windows Installer determines the state of the feature that contains these components, as being "advertised". This is still not sufficient to cause error 1316 on uninstall. In fact, only when component files are physically missing on disk, an attempt for local copy is triggered by Windows Installer.
Minimal Example and Repro Steps
I have not yet been able to reproduce the problem "naturally", i. e. in the same way as it happens on customers machines. Only by manually deleting one of the above mentioned component registry keys, I can artificially reproduce the problem.
Build a minimal WiX setup that installs two files, "File1.txt" and "File2.txt":
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<?define ProductName = "SpuriousFeatureAdvTest1"?>
<?define Manufacturer = "zett42"?>
<?if $(var.Platform) = x64 ?>
<?define PlatformProgramFilesFolder = "ProgramFiles64Folder" ?>
<?else ?>
<?define PlatformProgramFilesFolder = "ProgramFilesFolder" ?>
<?endif ?>
<Product Id="*" Name="$(var.Manufacturer) $(var.ProductName)" Language="1033" Version="1.0.0.0" Manufacturer="$(var.Manufacturer)" UpgradeCode="{65CEA630-EFC0-4199-86EE-88867AABEDEF}">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MajorUpgrade DowngradeErrorMessage="A newer version of $(var.ProductName) is already installed." />
<MediaTemplate />
<Feature Id="ProductFeature" Title="$(var.ProductName)" Level="1" AllowAdvertise="no" >
<ComponentGroupRef Id="ProductComponents" />
</Feature>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="$(var.PlatformProgramFilesFolder)">
<Directory Id="MANUFACTURERFOLDER" Name="$(var.Manufacturer)">
<Directory Id="INSTALLFOLDER" Name="$(var.ProductName)" />
</Directory>
</Directory>
</Directory>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<Component Id="File1" Guid="{19819F06-DD45-4B48-BD00-810DEF7C0297}">
<File Source="File1.txt"/>
</Component>
<Component Id="File2" Guid="{3F28EEDB-866D-4201-8173-12532C657B6C}">
<File Source="File2.txt"/>
</Component>
</ComponentGroup>
</Product>
</Wix>
Install the MSI file.
Delete the following registry key that belongs to component "File1":
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\60F9189154DD84B4DB0018D0FEC72079
Delete a key file that belongs to any of the other components of the same feature, in this case "File2":
c:\Program Files\zett42\SpuriousFeatureAdvTest1\File2.txt
Try to uninstall the product via "Add/Remove Programs" or "Apps & Features".
Uninstallation fails with "Error 1316" message.
Attempted solutions / workarounds
For support: The Microsoft Program Install and Uninstall troubleshooter successfully removes the problematic product.
I have tried to disable advertising of the feature (<Feature AllowAdvertise="no"/>), but it doesn't change anything.
Question
What could be possible causes of the problem and how to actually solve it?
Violation of component rules in the setup. Although I cannot exclude this cause, it seems unlikely as the missing component registry key(s) are random and only a small percentage of users is affected.
Interference of 3rd party software, like AV or registry cleanup utilities.
Disk or memory failures.
Bug in Windows Installer.
Anything else?
Searching for the error message shows that the problem is quite common. In some cases the error is caused by changing the file name of the MSI during a minor upgrade. This is definitely not the case here, because we don't do minor upgrades and the MSI files of the problematic setups were not renamed. As explained above it is very clear that there is a registry defect. A possibly similar case is described here, but the answer doesn't explain anything, it just points to the MS troubleshooting tool.
I have been able to reproduce the problem using a registry cleaner.
Repro Steps:
Install a program using Windows Installer.
Delete one or more files that are keyfiles of their components from the program folder.
Run the registry cleaner. The cleaner mistakenly determined that the Windows Installer component registry keys, who's keyfiles don't exist, are no longer needed. The cleaner deletes the registry keys.
Delete more files that are keyfiles of their components from the program folder.
Try to uninstall the program. It fails with error 1316.
Even without step 4, this uninstall will be broken, because any other resources installed by components of the same feature that contains the deleted components, won't be uninstalled. Delete one component registry key and the whole feature won't be uninstalled anymore!
With step 4, the issue turns into a problem, as the whole uninstall will rollback. It may also turn into an install problem, when the uninstall runs as part of a major upgrade that requires the older version to be removed first.
While the steps appear somewhat artificial, it is certainly not unlikely that users manually delete files from a programs installation folder. This could also happen accidentally when programs are installed on removable disks and the cleaner runs after the disk has been removed. Other reasons could be thought of.
Solution:
Don't use registry cleaners. While some may actually work, there is always the risk that they break something.
If error 1316 or 1406 occur during uninstall of any program (possibly also during major upgrade, when the older version gets removed), use Microsoft Program Install and Uninstall troubleshooter in "uninstall" mode. In some cases you may also succeed by rerunning the original setup package used to install the program.
I'm using wix tool 3.11 to create a msi which install a service. The installer runs a Custom Action and returns vars to wix to write to registry (HKLM). The service starts and try to read the registry but it can't be done and it fails. If I wrote the registry manually the installer works perfectly.
Error message from msi logs:
Product: Installer-- Error 1920. Service 'XPTO Server' (xpto_server) failed to start. Verify that you have sufficient privileges to start system services.
My Wix XML:
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" InstallPrivileges="elevated" />
...
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<Component Id="CMP_RegistryEntries" Guid="xxxxxxxxx" >
<RegistryKey Root="HKLM" Key="SOFTWARE\XPTOInc\XPTO\XPTOServer\BetaVersion">
<RegistryValue Name="token" Action="write" Value="[TOKEN]" Type="string" KeyPath="yes" />
<RegistryValue Name="[IDENTIFIER_TYPE]" Action="write" Value="[INSTALLEDID]" Type="string" />
<RegistryValue Name="installDir" Action="write" Value="[INSTALLFOLDER]" Type="string" />
</RegistryKey>
</Component>
<Component Id="CMP_XPTOServerEXE" Guid="xxxxxx">
<File Id="FILE_XPTOServerEXE" Name="xpto-server.exe" Source="Work\xpto-server.exe" KeyPath="yes" />
<ServiceInstall Id="InstallExporterService" Name="xpto_server" DisplayName="XPTO Server" Description="Read data from Registry and do simple stuff" ErrorControl="normal" Start="auto" Type="ownProcess" />
<ServiceControl Id="ServiceStateControl" Name="xpto_server" Remove="uninstall" Start="install" Stop="both" />
</Component>
</ComponentGroup>
EDIT: When I manually wrote the vars to Registry, the service installs with msi pkg or running with sc.exe
EDIT 2: Here follows the log where sets the registry and then star service
MSI (s) (70:74) [15:40:37:560]: Created Custom Action Server with PID 16808 (0x41A8).
MSI (s) (70:E4) [15:40:37:613]: Running as a service.
MSI (s) (70:E4) [15:40:37:615]: Hello, I'm your 32bit Elevated Non-remapped custom action server.
MSI (s) (70:38) [15:40:37:973]: Executing op: ActionStart(Name=WriteRegistryValues,Description=Writing system registry values,Template=Key: [1], Name: [2], Value: [3])
Action 15:40:37: WriteRegistryValues. Writing system registry values
MSI (s) (70:38) [15:40:37:974]: Executing op: ProgressTotal(Total=3,Type=1,ByteEquivalent=13200)
MSI (s) (70:38) [15:40:37:975]: Executing op: RegOpenKey(Root=-2147483646,Key=SOFTWARE\XPTOInc\XPTO\XPTOServer\BetaVersion,,BinaryType=0,,)
MSI (s) (70:38) [15:40:37:975]: Executing op: RegAddValue(Name=token,Value=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx,)
WriteRegistryValues: Key: \SOFTWARE\XPTOInc\XPTO\XPTOServer\BetaVersion, Name: token, Value: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
MSI (s) (70:38) [15:40:37:976]: Executing op: RegAddValue(Name=envId,Value=xxxxxxxxxxxxxxxxxxxxxxxx,)
WriteRegistryValues: Key: \SOFTWARE\XPTOInc\XPTO\XPTOServer\BetaVersion, Name: envId, Value: xxxxxxxxxxxxxxxxxxxxxxxxx
MSI (s) (70:38) [15:40:37:976]: Executing op: RegAddValue(Name=installDir,Value=C:\Program Files (x86)\XPTOInc\XPTO\XPTO Server Beta\,)
WriteRegistryValues: Key: \SOFTWARE\XPTOInc\XPTO\XPTOServer\BetaVersion, Name: installDir, Value: C:\Program Files (x86)\XPTOInc\XPTO\XPTO Server Beta\
MSI (s) (70:38) [15:40:37:977]: Executing op: ActionStart(Name=InstallServices,Description=Installing new services,Template=Service: [2])
Action 15:40:37: InstallServices. Installing new services
MSI (s) (70:38) [15:40:37:977]: Executing op: ProgressTotal(Total=1,Type=1,ByteEquivalent=1300000)
MSI (s) (70:38) [15:40:37:978]: Executing op: ServiceInstall(Name=xpto_server,DisplayName=XPTOServer,ImagePath="C:\Program Files (x86)\XPTOInc\XPTO\XPTO Server Beta\xpto-server.exe",ServiceType=16,StartType=2,ErrorControl=1,,Dependencies=[~],,,Password=**********,Description=Read data from Registry and do simple stuff,,)
InstallServices: Service:
MSI (s) (70:38) [15:40:37:980]: Executing op: ActionStart(Name=StartServices,Description=Starting services,Template=Service: [1])
Action 15:40:37: StartServices. Starting services
MSI (s) (70:38) [15:40:37:981]: Executing op: ProgressTotal(Total=1,Type=1,ByteEquivalent=1300000)
MSI (s) (70:38) [15:40:37:981]: Executing op: ServiceControl(,Name=xpto_server,Action=1,,)
StartServices: Service: XPTO Server
Error 1920. Service 'XPTO Server' (xpto_server) failed to start. Verify that you have sufficient privileges to start system services.
Solution: The problem in this case was that the registry keys were not found in the expected location in the registry due to 32-bit / 64-bit issues.
64-bit section: HKEY_LOCAL_MACHINE\SOFTWARE\Company\App - MyValue
32 bit section: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Company\App - MyValue
End of answer. Leaving debugging efforts in place below though:
Round 1:
Maybe try to read these two recent answers and check if anything rings a bell:
Wix Service Installer sometimes fails to install or start
Wix - ServiceControl start takes four minutes to fail, should be 30 sec
What does it say in the event viewer? (Windows + R eventvwr and OK)
Round 2:
Bitness: Are you sure you are reading from the right location in the registry? Are you installing a 32-bit MSI or a 64-bit MSI? (looks like 32-bit)
64-bit section: HKEY_LOCAL_MACHINE\SOFTWARE\Company\App
32 bit section: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Company\App
Permissions: Did you check the permissions for the registry keys and values your setup writes using regedit.exe to inspect? Right click => Permissions (have to ask).
Privileges: What account do you use to run the service? It sort of looks like standard LocalSystem? The account needs the SeServiceLogonRight privilege. See second line on section above for details.
Logging: Do you use log4net or some other logging feature in your service? Did you try the verbose, debug MSI logging found in the first link in the top section?
I'm trying to explore instance transforms with WiX version 3.7.1224.0. I created a test project (source below) and I can install the default ProductCode propertly, but when I try to install the resulting MSI, I get an error:
msiexec /i SetupProject1.msi /l*vx install.log MSINEWINSTANCE=1 TRANSFORMS=":Alpha"
Error applying transforms. Verify that the specified transform paths are valid
The install.log seems to suggest there's a row in the Property table that the "regular transform" is expecting to find and modify, but I'm not sure what property it might be looking for. I've been reading the MSDN documentation on multiple instance transforms as well as the WiX documentation and blog posts describing how <InstanceTransforms> works, but I'm at a loss for what it's looking for.
Compilation
"%WIX%\bin\candle.exe" -out obj\Debug\ -arch x86 Product.wxs
"%WIX%\bin\Light.exe" -out SetupProject1.msi -cultures:null obj\Debug\Product.wixobj
Product.wxs
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="SetupProject1" Language="1033" Version="1.0.0.0"
Manufacturer="ABC"
UpgradeCode="ce6fdce7-5c23-4379-af59-f70c520ad1b6">
<Package InstallerVersion="500" Compressed="yes" InstallScope="perMachine" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate EmbedCab="yes" />
<Property Id="INSTANCENAME" Secure="yes" />
<InstanceTransforms Property="INSTANCENAME">
<Instance Id="Alpha" ProductCode="{16756BA2-9FAC-4BA4-9FFD-FC2F06B1315E}" ProductName="SetupProject1 Alpha"/>
<Instance Id="Bravo" ProductCode="{D32D3643-5A46-421E-9216-1B1C9037DC37}" ProductName="SetupProject1 Bravo"/>
<Instance Id="Charlie" ProductCode="{ED9BC4F0-8CB8-4813-B677-F0E4A52D1890}" ProductName="SetupProject1 Charlie"/>
</InstanceTransforms>
<Feature Id="ProductFeature" Title="SetupProject1" Level="1">
<ComponentRef Id="FileComponent" />
</Feature>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="SetupProject1">
<Component Id="FileComponent" Guid="*">
<File Source="File1.txt" KeyPath="yes" />
</Component>
</Directory>
</Directory>
</Directory>
</Product>
</Wix>
install.log excerpt
MSI (c) (E4:8C) [13:49:28:343]: TRANSFORM: Applying regular transform to database.
MSI (c) (E4:8C) [13:49:28:343]: Note: 1: 2262 2: _Tables 3: -2147287038
MSI (c) (E4:8C) [13:49:28:343]: Note: 1: 2262 2: _Columns 3: -2147287038
MSI (c) (E4:8C) [13:49:28:343]: Note: 1: 2262 2: _Validation 3: -2147287038
MSI (c) (E4:8C) [13:49:28:343]: Note: 1: 2262 2: AdminExecuteSequence 3: -2147287038
MSI (c) (E4:8C) [13:49:28:343]: Note: 1: 2262 2: AdminUISequence 3: -2147287038
MSI (c) (E4:8C) [13:49:28:343]: Note: 1: 2262 2: AdvtExecuteSequence 3: -2147287038
MSI (c) (E4:8C) [13:49:28:343]: Note: 1: 2262 2: Component 3: -2147287038
MSI (c) (E4:8C) [13:49:28:343]: Note: 1: 2262 2: Directory 3: -2147287038
MSI (c) (E4:8C) [13:49:28:343]: Note: 1: 2262 2: Feature 3: -2147287038
MSI (c) (E4:8C) [13:49:28:343]: Note: 1: 2262 2: FeatureComponents 3: -2147287038
MSI (c) (E4:8C) [13:49:28:343]: Note: 1: 2262 2: File 3: -2147287038
MSI (c) (E4:8C) [13:49:28:343]: Note: 1: 2262 2: InstallExecuteSequence 3: -2147287038
MSI (c) (E4:8C) [13:49:28:343]: Note: 1: 2262 2: InstallUISequence 3: -2147287038
MSI (c) (E4:8C) [13:49:28:343]: Note: 1: 2262 2: LaunchCondition 3: -2147287038
MSI (c) (E4:8C) [13:49:28:343]: Note: 1: 2262 2: Media 3: -2147287038
MSI (c) (E4:8C) [13:49:28:343]: Note: 1: 2254 2: 3: Property
DEBUG: Error 2254: Database: Transform: Cannot update row that doesn't exist. Table: Property
1: 2254 2: 3: Property
Error applying transforms. Verify that the specified transform paths are valid.
Alpha
MSI (c) (E4:8C) [13:49:28:343]: Note: 1: 1708
MSI (c) (E4:8C) [13:49:28:344]: Product: SetupProject1 Alpha -- Installation failed.
MSI (c) (E4:8C) [13:49:28:344]: Windows Installer installed the product. Product Name: SetupProject1 Alpha. Product Version: 1.0.0.0. Product Language: 1033. Manufacturer: ABC. Installation success or error status: 1624.
It turns out the transform is setting the INSTANCENAME property (obvious, in retrospect). The property needs to have a default value so it's listed in the Property table.
<Property Id="INSTANCENAME" Value="Default" />
This is my .wxs file
Particularly I managed to install a service as a LocalSystem user, and started it:
<!-- Directory where [prey]/versions/[version] will be -->
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLLOCATION" Name="Prey">
<Directory Id="VersionsDir" Name="versions">
<Directory Id="VersionDir" Name="$(var.ProductVersion)">
<Directory Id="BinDir" Name="bin">
<Directory Id="BinWindowsDir" Name="windows">
<Component Id="CronServiceExe"
Guid="ECC25B2A-FB2E-425A-92AD-DCF1D34204FF">
<File Id="file_8FF048AD40124B9F9C07126F2C14A765"
Checksum="yes"
KeyPath="yes"
Source="source-msi\versions\0.10.0\bin\windows\cronsvc.exe" />
<ServiceInstall Id="CronServiceInstaller"
Type="ownProcess"
Vital="yes"
Name="CronService"
DisplayName="Cron Service"
Start="auto"
Account="LocalSystem"
ErrorControl="normal"
Interactive="no">
</ServiceInstall>
<ServiceControl Id="StartService"
Start="install"
Stop="both"
Remove="uninstall"
Name="CronService"
Wait="yes" />
</Component>
<Component Id="CronServiceDll"
Guid="75C4129B-C28A-45A8-9F06-CB496259FE7F">
<File Id="file_11D016207EA34826A20A52524A3A82BC"
Checksum="yes"
KeyPath="yes"
Source="source-msi\versions\0.10.0\bin\windows\Cronsvclib.dll" />
</Component>
</Directory>
</Directory>
</Directory>
</Directory>
</Directory>
</Directory>
And it runs fine. Everything is OK, except when I get to uninstall the product. Because despite being asked in an UAC dialog I get (Screenshot), the installer insist that I don't have permissions to stop the service.
Here is the screenshot of the Error, which says:
Service 'Cron Service' (CronService) could not be stopped. Verify that you have sufficient privileges to stop system services.
And, here is the specific logs (I'm uninstalling with /L*v option to get verbose logs). You can get the full file in this gist.
Lines 2220 - 2226
MSI (s) (90:80) [19:11:54:953]: Note: 1: 2205 2: 3: Icon
MSI (s) (90:80) [19:11:54:953]: Note: 1: 2205 2: 3: TypeLib
MSI (s) (90:80) [19:11:54:953]: Note: 1: 2727 2:
MSI (s) (90:80) [19:11:54:973]: RESTART MANAGER: Detected that the service CronService will be stopped due to a service control action authored in the package before the files are updated. So, we will not attempt to stop this service using Restart Manager
MSI (s) (90:80) [19:11:54:973]: Note: 1: 2727 2:
MSI (s) (90:80) [19:11:54:973]: Doing action: InstallInitialize
MSI (s) (90:80) [19:11:54:973]: Note: 1: 2205 2: 3: ActionText
Action ended 19:11:54: InstallValidate. Return value 1.
Lines 4624 - 4635
MSI (s) (90:80) [19:11:57:196]: Executing op: ActionStart(Name=StopServices,Description=Stopping services,Template=Service: [1])
MSI (s) (90:80) [19:11:57:196]: Executing op: ProgressTotal(Total=1,Type=1,ByteEquivalent=1300000)
MSI (s) (90:80) [19:11:57:196]: Executing op: ServiceControl(,Name=CronService,Action=2,Wait=1,)
MSI (s) (90:80) [19:12:27:239]: Note: 1: 2205 2: 3: Error
MSI (s) (90:80) [19:12:27:239]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1921
MSI (s) (90:80) [19:16:38:940]: Note: 1: 2205 2: 3: Error
MSI (s) (90:80) [19:16:38:940]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709
MSI (s) (90:80) [19:16:38:940]: Product: Prey Anti-theft -- Error 1921. Service 'Cron Service' (CronService) could not be stopped. Verify that you have sufficient privileges to stop system services.
MSI (s) (90:80) [19:17:08:983]: Note: 1: 2205 2: 3: Error
MSI (s) (90:80) [19:17:08:983]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1921
MSI (c) (48:84) [19:12:27:239]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
Given all that information. I infere that somewhere I have to manage to start my MSI as an administrator. Or not?
That's my problem:
Is there a way to set up my .msi installer as an "admin only" one? (If that choice does exist).
The weird thing is that all posts and google results I'm getting are about problems INSTALLING and STARTING the service, rather than STOPPING it. So I'm in a dead end.
Please, all help will be very useful and appreciated.
The error message includes the suggestion that it's a permissions problem. That's rarely the case, since installing services requires elevated permissions to begin with. Failure to stop a service is usually as simple as the service not responding to the stop request quickly enough. Does CronService implement the service interface to respond to stop requests? Neither MSI nor Windows will kill a service process to stop it.