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.
Using WiX, I'm replacing a application with a new version.
In the old version, there was a directory which is no longer needed in the new version.
So on install, this should do it:
<Component Id="killDir_" Guid="..." KeyPath="yes">
<RemoveFolder Id="killDir" On="both" />
</Component>
So far so good, this works fine.
But if the folder is already removed, the setup creates it again!
This happens also when using
<util:RemoveFolderEx .../>
I have tried a condition within the <Component> tag:
<Condition>OLD_STUFF_EXISTS</Condition>
along with a DirectorySearch in the Product:
<Property Id="OLD_STUFF_EXISTS">
<DirectorySearch Id='DirSearch' Path="OldDir" Depth='0'>
</DirectorySearch>
</Property>
But that doesn't seem to work.
In the MSI log file, the RemoveFolder seems to be executed:
MSI (s) (A0:4C) [13:44:45:742]: Doing action: RemoveFolders
MSI (s) (A0:4C) [13:44:45:742]: Note: 1: 2205 2: 3: ActionText
Action 13:44:45: RemoveFolders. Removing folders
Action start 13:44:45: RemoveFolders.
Action ended 13:44:45: RemoveFolders. Return value 1.
Some lines down, the istalled creates it again:
MSI (s) (A0:4C) [13:44:45:807]: Executing op: FolderCreate(Folder=C:\...\,Foreign=0,,)
Is there any way to tell the installer NOT to create it again?
Even though I hide the WiX property that contains a password and the ExecXmlFile property...
<Property Id="MyApp_MyServer_constr" Hidden="yes" />
<Property Id="ExecXmlFile" Hidden="yes" />
<DirectoryRef Id='MYAPPDIR'>
<Component Id='UpdateMyAppMyServerConnectionString' Guid='MY-GUID' Win64="yes">
<CreateFolder />
<util:XmlFile Id='UpdateMyAppMyServerConnectionString'
Action="setValue"
ElementPath="[MyServer_elementpath]"
File="[MYAPPDIR]MyApp.exe.config"
Value="[MyApp_MyServer_constr]" />
</Component>
</DirectoryRef>
...password details are exposed in the MSI install log file.
MSI (s) (F0:7C) [20:27:56:613]: Executing op: ActionStart(Name=ExecXmlFile,,)
Action 20:27:56: ExecXmlFile.
MSI (s) (F0:7C) [20:27:56:613]: Executing op: CustomActionSchedule(Action=ExecXmlFile,ActionType=3073,Source=BinaryData,Target=ExecXmlFile,CustomActionData=20C:\Program Files\MyCompany\MyInstallerName\MyApp\MyApp.exe.config30//configuration/connectionStrings/add[#name='MyServer']/#connectionStringUser ID=sa;Password=wysiwyg;Initial Catalog=MyDatabase;Data Source=MACHINE-NAME;Application Name=MyShortAppName)
I've done a considerable amount of checking online, but there does seem to be a WiX way of hiding this information from an MSI log without doctoring things using Orca after creating an MSI.
I found this WiX bug http://wixtoolset.org/issues/3859/, but it seems that not allowing hiding of ExecXmlFile CustomAction calls was by design.
Alternately, is there another WiX way to accomplish what I need that doesn't expose password details in the log file?
Thanks
I'm using wix IniFile element to edit ini file on install. When I try to uninstall i get error 2343:
Начало действия 12:37:47: RemoveIniValues.
MSI (s) (7C:BC) [12:37:47:264]: Note: 1: 2343
DEBUG: Error 2343: Specified path is empty.
My wxs with ini editing is as follows:
<?xml version="1.0"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<Property Id="miktex_config_path" Hidden="yes"/>
<SetProperty Id="miktex_config_path" Value="[INSTALLLOCATION]miktex\miktex\config" After="InstallFiles" Sequence="execute">Not Installed</SetProperty>
<DirectoryRef Id="dirC060208F28327102C690BFF33C18B6C4">
<Component Id="miktex_config_file" Guid="4B9400C2-7EEF-4233-881D-5DFE6F80BB5B">
<CreateFolder />
<IniFile Directory="miktex_config_path" Id="common_install_path" Name="miktexstartup.ini" Action="addLine" Key="CommonInstall" Value="[INSTALLLOCATION]miktex" Section="Paths"/>
<IniFile Directory="miktex_config_path" Id="common_data_path" Name="miktexstartup.ini" Action="addLine" Key="CommonData" Value="[CommonAppDataFolder]miktex_data" Section="Paths"/>
<Condition><![CDATA[Not Installed]]></Condition>
</Component>
</DirectoryRef>
</Fragment>
</Wix>
Why doesn't uninstaller take into account my condition element?
How can I force installer to ignore ini file editing during uninstall?
The condition is against the component, however the action that is running is RemoveIniValue. You can surpress this action by overriding InstallExecuteSequence as follows:
<InstallExecuteSequence>
<RemoveIniValues Suppress="yes" />
</InstallExecuteSequence>
It depends on the task you pursue. If you need to prevent INI value removal at all then suppressing the RemoveIniValues in the InstallExecuteSequence is the way to go as suggested by David Martin. However, that suppression (NO MATTER what you put as a condition for that), prevents the INI entry removals and for install and for uninstall (again, condition doesn't work, don't even try to put condition to suppress on uninstall only). But if you need to allow INI entry/tag removals during the install (IniFile declaration with remove action) but at the same time you need to prevent the rest of your INI settings from removal during the uninstall, then simply mark the Component where you keep your IniFile declarations as Permanent="yes". In that case your INI settings will not be removed on uninstall and your declarations to remove particular INI settings on install will work, And forget about the RemoveIniValues suppression at all.
Is it possible to include a Msi package into the bootstrapper but not any of it's external files?
So my msi installer has a file:
<Component Directory="INSTALLDIR">
<File Id="DatabaseBackup"
Name="Database.bak"
Source="Database.bak"
Compressed="no" />
</Component>
which outputs:
Installer.msi
Database.bak
Now if I set the burn chain to include the msi package:
<MsiPackage SourceFile="$(var.Installer.TargetPath)" />
the "Database.bak" file is also compressed into the resultant exe. Is it possible to compress the msi but not the .bak file?
If not can someone answer this question better than I can then I won't need to do this at all! :)
I've used the Payload element for this purpose... in your example I would change the MsiPackage element to:
<MsiPackage SourceFile="$(var.Installer.TargetPath)" >
<Payload Compressed="no" SourceFile="{path_to_bak_file}\Database.bak" />
</MsiPackage>
The MSI then picks up the file and uses it as expected.
I haven't found a way to make this conditional or flexible.. in my case it's a config file that is not critical, but my setup now fails (first opens up a file open dialog looking for that file) if the file is missing - of course this depends on the details of the MSI I've created.
Hope this helps