I have WiX 4.0 project. I'm using Util to create Windows EventLog event source. The problem is, the Registry entry to the EventMessageFile gets the path prepended with "#%". Therefore, the EventLog will display errors for events created by this event source.
Code to create the EventSource:
<Include xmlns="http://wixtoolset.org/schemas/v4/wxs" xmlns:util="http://wixtoolset.org/schemas/v4/wxs/util">
<PropertyRef Id="NETFRAMEWORK40FULLINSTALLROOTDIR64"/>
<PropertyRef Id="NETFRAMEWORK40CLIENTINSTALLROOTDIR64"/>
<PropertyRef Id="NETFRAMEWORK40CLIENT"/>
<PropertyRef Id="NETFRAMEWORK40FULL"/>
.
.
.
<ComponentGroup Id="EventLog" Directory="INSTALLFOLDER">
<!-- 64 bit -->
<Component Id="CreateEventSource64BitFullNet4" DiskId="1" Guid="{9978592B-3E96-4AAA-B7A6-34B0421FDD02}" Condition="NETFRAMEWORK40FULLINSTALLROOTDIR64 AND VersionNT64">
<CreateFolder/>
<util:EventSource Log="Application" Name="ScholarshipSapQueue" EventMessageFile="[NETFRAMEWORK40FULLINSTALLROOTDIR64]EventLogMessages.dll" />
</Component>
<Component Id="CreateEventSource64BitClientNet4" DiskId="1" Guid="{B42622A1-B7C0-48CB-B306-65F3558C6678}" Condition="NETFRAMEWORK40CLIENTINSTALLROOTDIR64 AND NOT NETFRAMEWORK40FULL AND VersionNT64">
<CreateFolder/>
<util:EventSource Log="Application" Name="ScholarshipSapQueue" EventMessageFile="[NETFRAMEWORK40CLIENTINSTALLROOTDIR64]EventLogMessages.dll" />
</Component>
</ComponentGroup>
</Include>
Looking at the log file from installing the MSI, the value of the properties does look correct:
MSI (c) (B4:68) [10:05:27:331]: PROPERTY CHANGE: Adding NETFRAMEWORK40FULLINSTALLROOTDIR64 property. Its value is 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\'.
But the Registry entry is wrong:
MSI (s) (3C:28) [10:05:33:008]: Executing op: ActionStart(Name=WriteRegistryValues,Description=Writing system registry values,Template=Key: [1], Name: [2], Value: [3])
Action 10:05:33: WriteRegistryValues. Writing system registry values
MSI (s) (3C:28) [10:05:33:014]: Executing op: ProgressTotal(Total=1,Type=1,ByteEquivalent=13200)
MSI (s) (3C:28) [10:05:33:014]: Executing op: RegOpenKey(Root=-2147483646,Key=SYSTEM\CurrentControlSet\Services\EventLog\Application\ScholarshipSapQueue,,BinaryType=0,,)
MSI (s) (3C:28) [10:05:33:014]: Executing op: RegAddValue(Name=EventMessageFile,Value=##%C:\Windows\Microsoft.NET\Framework64\v4.0.30319\EventLogMessages.dll,)
WriteRegistryValues: Key: \SYSTEM\CurrentControlSet\Services\EventLog\Application\ScholarshipSapQueue, Name: EventMessageFile, Value: ##%C:\Windows\Microsoft.NET\Framework64\v4.0.30319\EventLogMessages.dll
That smells like a WiX v4 bug. Please open an issue at https://github.com/wixtoolset/issues/issues/new/choose.
MajorUpgrade element is scheduled after install finalize in our product's MSI:
<MajorUpgrade Schedule="afterInstallFinalize" AllowSameVersionUpgrades="yes" DowngradeErrorMessage="!(loc.NewerVersionInstalled)" IgnoreRemoveFailure="no"/>
There are some folders written by app at runtime that we want to keep on upgrade and only remove on uninstall initiated from Add/Remove programs. So we use this condition: (NOT UPGRADINGPRODUCTCODE) AND (REMOVE="ALL").
<DirectoryRef Id="TARGETDIR">
...
<Directory Id="LocalAppDataFolder"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
<Component Id="CreatePrivateMyAppFolder" Guid="FA1F4375-71DA-4E61-9A02-BE7FD2D4C87D">
<RegistryValue Root="HKCU" Key="Software\Company\Product" Name="PrivateFolderMyApp" Type="string" Value="[PrivateDataMyApp]" KeyPath="yes"/>
</Component>
<Component Id="RemoveLocalAppDataMyAppUninstall" Guid="*" Transitive="yes">
<Condition><![CDATA[(NOT UPGRADINGPRODUCTCODE) AND (REMOVE="ALL")]]></Condition>
<RegistryValue Root="HKCU" Key="Software\Company\Product" Name="PrivateFolderMyApp" Type="string" Value="[PrivateDataMyApp]" KeyPath="yes"/>
<util:RemoveFolderEx On="uninstall" Property="PRIVATEMYAPPFOLDER"/>
</Component>
<Directory></Directory>
...
</Directory>
</DirectoryRef>
I need to change the MajorUpgrade schedule from afterInstallFinalize to afterInstallInitialize for some new requirements. I install version 1 with new schedule. Then install versions 2. However during uninstall sequence of version 2, folders written by runtime are being removed.
From logs, both UPGRADINGPRODUCTCODE and REMOVE properties are set for the uninstall part. Based on that the condition (NOT UPGRADINGPRODUCTCODE) AND (REMOVE="ALL") should evaluate to false for the component RemoveLocalAppDataMyAppUninstall.
MSI (s) (C4:58) [22:58:11:060]: Doing action: RemoveExistingProducts
Action 22:58:11: RemoveExistingProducts. Removing applications
Action start 22:58:11: RemoveExistingProducts.
RemoveExistingProducts: Application: {8F890AE0-BE0A-5ED9-B406-F7459B3390F9}, Command line: UPGRADINGPRODUCTCODE={70705091-36C8-5619-9E35-73E455CA17F7} CLIENTPROCESSID=4756 CLIENTUILEVEL=0 REMOVE=ALL
....
MSI (s) (C4:4C) [22:58:11:076]: Command Line: UPGRADINGPRODUCTCODE={70705091-36C8-5619-9E35-73E455CA17F7} CLIENTPROCESSID=4756 CLIENTUILEVEL=0 REMOVE=ALL
MSI (s) (C4:4C) [22:58:11:279]: Dir (target): Key: _PRIVATEMYAPPFOLDER_4 , Object: C:\Users\Windows_10\AppData\Local\MyApp\
MSI (s) (C4:4C) [22:58:11:279]: Dir (target): Key: _PRIVATEMYAPPFOLDER_3 , Object: C:\Users\Windows_10\AppData\Local\MyApp\1753de9b-15a7-49b1-8715-f93a967d12e5\
...
MSI (s) (C4:4C) [22:58:11:826]: Doing action: InstallValidate
MSI (s) (C4:4C) [22:58:11:826]: Component: RemoveLocalAppDataMyAppUninstall; Installed: Local; Request: Absent; Action: Absent
...
MSI (s) (C4:4C) [22:58:12:732]: Doing action: RemoveFiles
MSI (s) (C4:4C) [22:58:12:919]: Counted 6 foreign folders to be removed.
MSI (s) (C4:4C) [22:58:12:919]: Removing foreign folder: C:\Users\Windows_10\AppData\Local\MyApp\1753de9b-15a7-49b1-8715-f93a967d12e5\
MSI (s) (C4:4C) [22:58:12:919]: Removing foreign folder: C:\Users\Windows_10\AppData\Local\MyApp\
Any help in understanding why the condition is being applied during uninstall will be appreciated.
Component conditions only affect install and, with the transitive bit set, reinstall. Uninstall isn't affected. RemoveFolderEx in WiX v4 has a Condition that lets you do what you want to do.
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.
Having a major problem. I read that Rob M said to use Guid="*" whenever possible so I changed all of my Guid's to this. Uninstalling my product is messing up now though. The files are successfully removed but the shortcuts, services and registry are not. Please Help
This is my service:
<Component Id="service" Guid="*">
<File Id="service.exe" Name="service.exe" KeyPath="yes" Source="$(var.Bin)\service.exe"/>
<ServiceInstall Id="service.exe" Name="[PRODUCTNAME]" Description="[ProductName]" Account="[SERVICEACCOUNT]" Password="[SERVICEPASSWORD]" Arguments=" /start [ProductName]" Start="auto" Interactive="yes" Type="ownProcess" Vital="yes" ErrorControl="critical" />
<ServiceControl Id="service.exe" Name="[PRODUCTNAME]" Stop="both" Start="install" Remove="uninstall" Wait="no"/>
</Component>
This is the uninstall log:
Service '' () could not be stopped. Verify that you have sufficient privileges to stop system services.
MSI (s) (DC:D0) [14:25:02:018]: Executing op: ActionStart(Name=DeleteServices,Description=
Deleting services
,Template=
Service: [1]
)
MSI (s) (DC:D0) [14:25:02:018]: Executing op: ProgressTotal(Total=2,Type=1,ByteEquivalent=1300000)
MSI (s) (DC:D0) [14:25:02:018]: Executing op: ServiceControl(,,Action=8,Wait=0,)
MSI (s) (DC:D0) [14:25:32:064]: Executing op: ServiceControl(,Name=OPC,Action=8,Wait=0,)
Info 1922.
Service '' () could not be deleted. Verify that you have sufficient privileges to remove system services.
Its not picking up the name, anyone know why it would do this?
First questions first:
Have you already released a version of this product? If so, changing component GUIDs is likely a huge violation of component rules, so you should not change these once released. If it's only been on your test machine, that's not important.
Are you resetting your test machine such that the violation of component rules is not affecting the uninstall, or are you attempting to perform some sort of upgrade before this failing uninstallation?
What does the verbose MSI log from uninstallation indicate?
How is your property "PRODUCTNAME" defined? If it's not a constant, please verify that it's initialization is performed during uninstall sequence
MSIZAP, will be the ultimate way to eliminate everything installed on the machine by the installer. I do recommend that you test it on a Proof of concept of what you are trying to do, and use a VM for all installing tests.