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.
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.
I made a patch package with WIX, and the configuration is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Patch
AllowRemoval="yes"
Classification="Update"
Comments="Patch forv.3.5.0.0"
Description="Updates to v.3.5.1.0"
DisplayName="Patch v.3.5.0.0-v.3.5.1.0"
MoreInfoURL=""
Manufacturer=""
TargetProductName="DDD">
<Media Id="5000" Cabinet="MyPatch.cab">
<PatchBaseline Id="MyPatch" />
</Media>
<PatchFamily
Id="MyPatchFamily"
Version="0.0.1.0"
Supersede="yes" >
</PatchFamily>
<TargetProductCodes Replace="yes">
<TargetProductCode Id="{0498A327-4DB6-47FD-91EB-F6B6496F2547}"/>
<TargetProductCode Id="{6318BD0F-1B46-4AA2-B490-EC33785998B6}"/>
<TargetProductCode Id="{2FF1A3B7-B781-42EA-9AE7-4A3816621B46}"/>
</TargetProductCodes>
</Patch>
</Wix>
After my first installation, the version information was updated, but the files were not.
Then I uninstalled the patch and reinstalled the patch pack, and it worked.
By comparing the two installation records, I captured the following different places.
This is the log for the first installation
MSI (s) (A8:28) [09:05:01:778]: Executing op: FileCopy(SourceName=ihji0quu.con|DVStudio.exe.config,SourceCabKey=fileEE54A590D2CC2AE8647D5A5EB2C37313,DestName=DVStudio.exe.config,Attributes=4608,FileSize=5001,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=58982400,HashOptions=0,HashPart1=2020519154,HashPart2=1152590171,HashPart3=-1283096050,HashPart4=229789553,,)
MSI (s) (A8:28) [09:05:01:779]: File: C:\Program Files (x86)\DIAView\DVStudio.exe.config; Won't Overwrite; Won't patch; Existing file is unversioned but modified
This is the log for the second installation
MSI (s) (A8:D4) [09:06:04:078]: Executing op: FileCopy(SourceName=ihji0quu.con|DVStudio.exe.config,SourceCabKey=fileEE54A590D2CC2AE8647D5A5EB2C37313,DestName=DVStudio.exe.config,Attributes=4608,FileSize=5001,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=58982400,HashOptions=0,HashPart1=2020519154,HashPart2=1152590171,HashPart3=-1283096050,HashPart4=229789553,,)
MSI (s) (A8:D4) [09:06:04:079]: File: C:\Program Files (x86)\DIAView\DVStudio.exe.config; Overwrite; Won't patch; Existing file is unversioned and unmodified - hash doesn't match source file
MSI (s) (A8:D4) [09:06:04:079]: Source for file 'fileEE54A590D2CC2AE8647D5A5EB2C37313' is compressed
InstallFiles: File: DVStudio.exe.config, Directory: C:\Program Files (x86)\DIAView\, Size: 5001
MSI (s) (A8:D4) [09:06:04:081]: Re-applying security from existing file.
MSI (s) (A8:D4) [09:06:04:083]: Verifying accessibility of file: DVStudio.exe.config
MSI (s) (A8:D4) [09:06:04:084]: Using source file security for destination.
MSI (s) (A8:D4) [09:06:04:085]: Note: 1: 2318 2: C:\Config.Msi\8ba0779.rbf
Why is that?
I come upon the warning message during uninstalls a product or major updates in the uninstall phase (when a product service is running):
"The setup must update files or service that cannot be updated while the system is running. If you choose continue, a reboot will be required to complete the setup."
Story starts here
I have developed the windows service and created the installer [msi] using Wix, then distributed to users. it is working as expected.
Now, it's time to deliver a new build with service enhancements. Hence, I have created a new msi. I was hoping that the execution of new msi shall upgrade the existing application.
But I get below error
The setup must update files or services that cannot be updated while the system is running
To support MSI upgrade, I have made below changes
Existing code for Product section
<?define UpgradeCode = "{3D197FE4-86DF-31FD-A0CD-21B5D3B97ABC}" ?>
<Product Id="$(var.ProductCode)"
Name="!(loc.ProductName_$(var.Platform)) $(var.ProductVersion)"
Language="!(loc.Language)"
Version="$(var.BuildVersion)"
Manufacturer="!(loc.Company)"
UpgradeCode="$(var.UpgradeCode)">
Changed code, Here Product ID changed to *
<?define UpgradeCode = "{3D197FE4-86DF-31FD-A0CD-21B5D3B97ABC}" ?>
<Product Id="*"
Name="!(loc.ProductName_$(var.Platform)) $(var.ProductVersion)"
Language="!(loc.Language)"
Version="$(var.ProductVersion)"
Manufacturer="!(loc.Company)"
UpgradeCode="$(var.UpgradeCode)">
Observe that upgrade code is not changed from old version to new version.
Existing code for upgrade
<MajorUpgrade DowngradeErrorMessage="!(loc.DowngradeErrorMessage)" />
Updated code for upgrade
<MajorUpgrade DowngradeErrorMessage="!(loc.DowngradeErrorMessage)"
AllowDowngrades="no"
AllowSameVersionUpgrades="yes"
RemoveFeatures="ALL"
Schedule="afterInstallInitialize"/>
Is it anything to do with service?
<ServiceControl Id="myservice"
Name="GatewayService"
Start="install"
Stop="both"
Remove="uninstall" Wait="yes" />
Install Sequence
How to get rid of this prompt? Also why it's coming if service is stopped.
Some part of logs
MSI (s) (78:5C) [19:54:21:691]: WIN64DUALFOLDERS: Substitution in 'C:\Program Files (x86)\Service\Service.dll' folder had been blocked by the 1 mask argument (the folder pair's iSwapAttrib member = 0).
The setup must update files or services that cannot be updated while
the system is running. If you choose to continue, a reboot will be
required to complete the setup.
MSI (s) (78:5C) [19:54:53:705]: Note: 1: 2727 2:
MSI (s) (78:5C) [19:54:53:706]: Doing action: RemoveExistingProducts
MSI (s) (78:5C) [19:54:53:706]: Note: 1: 2205 2: 3: ActionText
Action ended 19:54:53: InstallValidate. Return value 1.
MSI (s) (78:5C) [19:54:53:706]: Skipping RemoveExistingProducts action:
current configuration is maintenance mode or an uninstall
Action start 19:54:53: RemoveExistingProducts.
MSI (s) (78:5C) [19:54:53:706]: Doing action: InstallInitialize
MSI (s) (78:5C) [19:54:53:706]: Note: 1: 2205 2: 3: ActionText
Action ended 19:54:53: RemoveExistingProducts. Return value 0.
MSI (s) (78:5C) [19:54:53:708]: Machine policy value 'AlwaysInstallElevated' is 0
MSI (s) (78:5C) [19:54:53:708]: User policy value 'AlwaysInstallElevated' is 0
I have below code to restart service on failure. do u think it causes issue?
<util:ServiceConfig xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"
FirstFailureActionType="restart"
SecondFailureActionType="restart"
ThirdFailureActionType="restart" />
Issue root cause
I see that old version is not getting deleted during upgrade. Hence created a new question here Wix installer upgrade with same "upgrade code" ID shows privilege error prompt
Issue resolved. Culprit was below code
<util:ServiceConfig xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"
FirstFailureActionType="restart"
SecondFailureActionType="restart"
ThirdFailureActionType="restart" />
I have added delay as follow, and everything working like charm now.
RestartServiceDelayInSeconds="60"
Thanks to someone who thought the need for RestartServiceDelayInSeconds. Great thinking during ServiceConfig utility development
So I was installing MongoDB and this message kept popping up. I tried clicking on OK thinking that it would reboot the system but nothing happened. Then I turned off my internet and retried. It worked. This was weird but that's how my problem got resolved.
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?
Here's what I have (based on what I've gleaned from several other Stack Overflow posts and elsewhere:
<Property Id="CACHEFOLDER">
<RegistrySearch Key="SOFTWARE\SIL\Transcelerator" Root="HKCU" Type="raw"
Id="CacheFolderRegSearch" Name="CachePath" />
</Property>
<Directory Id="TARGETDIR" Name="SourceDir
<!-- Transcelerator's cache folder in LocalAppData: -->
<!-- C:\Users\<current user>\AppData\Local\SIL\Transcelerator -->
<!-- This needs to be saved to a registry key so it can be cleaned up on uninstall and also purged when there is a new install in order to ensure that reparsing occurs. -->
<?define AppCacheFolder = "SIL\Transcelerator" ?>
<Component Id="CacheCleanup" Guid="{6A45D61D-EA73-4A8C-8941-B49A881ABB49}">
<RegistryValue Root="HKCU" Key="Software\SIL\Transcelerator" Name="CachePath"
Type="string" Value="[LocalAppData]$(var.AppCacheFolder)"
KeyPath="yes" />
<util:RemoveFolderEx On="both" Property="CACHEFOLDER"/>
</Component>
</Directory>
<Feature Id="MainApplication" Title="App Name" Level="1" Absent="disallow" Display="expand" AllowAdvertise="no" InstallDefault="local">
<ComponentRef Id="CacheCleanup" />
</Feature>
Note: Eventually, I'll want to make the MainApplication feature hidden, but for now it's comforting to see it.
Here are what I think are the relevant excerpts from the WIX log file:
AppSearch: Property: CACHEFOLDER, Signature: CacheFolderRegSearch
MSI (c) (38:F0) [18:25:39:116]: PROPERTY CHANGE: Adding CACHEFOLDER property. Its value is 'SIL\Transcelerator'.
Action ended 18:25:39: AppSearch. Return value 1.
...
MSI (c) (38:F0) [18:25:45:594]: Switching to server: PARATEXT7="C:\Program Files (x86)\Paratext 7\" PARATEXT7TEST="C:\Program Files (x86)\ParatextDir7Test\" PARATEXT8="C:\Program Files (x86)\Paratext 8\" PARATEXT8TEST="C:\Program Files (x86)\ParatextDir8Test\" PARATEXT75100ORGREATER="C:\Program Files (x86)\Paratext 7\Paratext.exe" CACHEFOLDER="SIL\Transcelerator" TARGETDIR="C:\" INSTALLDIR7="C:\Program Files (x86)\Paratext 7\plugins\Transcelerator\" INSTALLDIR7TEST="C:\Program Files (x86)\ParatextDir7Test\plugins\Transcelerator\" INSTALLDIR8="C:\Program Files (x86)\Paratext 8\plugins\Transcelerator\" INSTALLDIR8TEST="C:\Program Files (x86)\ParatextDir8Test\plugins\Transcelerator\" PLUGINDIR7="C:\Program Files (x86)\Paratext 7\plugins\" PLUGINDIR7TEST="C:\Program Files (x86)\ParatextDir7Test\plugins\" PLUGINDIR8="C:\Program Files (x86)\Paratext 8\plugins\" PLUGINDIR8TEST="C:\Program Files (x86)\ParatextDir8Test\plugins\" CURRENTDIRECTORY="C:\Projects\Transcelerator" CLIENTUILEVEL="0" CLIENTPROCESSID="17976" SOURCEDIR="C:\Projects\Transcelerator\output\installer\" ACTION="INSTALL" EXE
...
MSI (s) (E4:44) [18:25:46:006]: PROPERTY CHANGE: Adding CACHEFOLDER property. Its value is 'SIL\Transcelerator'.
...
Action 18:25:46: WixRemoveFoldersEx.
Action start 18:25:46: WixRemoveFoldersEx.
MSI (s) (E4:00) [18:25:46:041]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI6019.tmp, Entrypoint: WixRemoveFoldersEx
MSI (s) (E4:78) [18:25:46:042]: Generating random cookie.
MSI (s) (E4:78) [18:25:46:044]: Created Custom Action Server with PID 18712 (0x4918).
MSI (s) (E4:54) [18:25:46:067]: Running as a service.
MSI (s) (E4:54) [18:25:46:069]: Hello, I'm your 32bit Impersonated custom action server.
WixRemoveFoldersEx: Recursing path: SIL\Transcelerator\ for row: wrfA9D8B049E87ACFF02034C5FFCFB64E42.
WixRemoveFoldersEx: Search path not found: SIL\Transcelerator*
Action ended 18:25:46: WixRemoveFoldersEx. Return value 1.
...
MSI (s) (E4:44) [18:25:46:267]: Executing op: ComponentRegister(ComponentId={6A45D61D-EA73-4A8C-8941-B49A881ABB49},KeyPath=01:\Software\SIL\Transcelerator\CachePath,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0)
1: {97A212AC-E01E-486A-A220-AF9BBBC79E87} 2: {6A45D61D-EA73-4A8C-8941-B49A881ABB49} 3: 01:\Software\SIL\Transcelerator\CachePath
...
MSI (s) (E4:44) [18:25:46:597]: Executing op: RegOpenKey(Root=-2147483647,Key=Software\SIL\Transcelerator,,BinaryType=0,,)
MSI (s) (E4:44) [18:25:46:597]: Executing op: RegAddValue(Name=CachePath,Value=SIL\Transcelerator,)
WriteRegistryValues: Key: \Software\SIL\Transcelerator, Name: CachePath, Value: SIL\Transcelerator
...
Property(S): CACHEFOLDER = SIL\Transcelerator
Nothing relevant seems to be getting added to the registry. (At one point, it seems it was adding something withe correct GUID to tell it to do an uninstall action, but now I can't figure out what I changed to make that go away.) And none of files or subfolders in C:\Users\bogle\AppData\Local\SIL\Transcelerator are getting removed either on install or uninstall. I also tried changing from On="both" to On="Uninstall" to see if I could get that to work, but no dice.
I ended up using a custom action because it turns out that what I really needed to do was clear the cached files for any/all users, not just the current user. This was especially true because the installer always runs under elevated privileges, so the current user quite typically would not be the one I actually care about. I will point out that the original problem remains unsolved, so if anyone can figure out the problem and post an alternate answer that might help someone else, that could be useful.
The name of the directory property is LocalAppDataFolder, not LocalAppData. That's not defined so it's an empty string and the path RemoveFolderEx is given isn't valid (hence the Search path not found: SIL\Transcelerator error).