Changed GUID - Now uninstall not working - wix

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.

Related

Wix installer: installed service unable to read HKLM registry entries on start

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?

How to use RemoveFolderEx to recursively remove folder in LocalAppData on install AND uninstall

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).

WiX Toolset - Is there a way to hide Util:XmlFile calls from the log?

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

Wix installer always install my service under Local System Account

I am creating wix installer for windows service.
But my windows service is not getting installed under the service account which I pass instead it always installed under Local System Account. Please help.
<Component Id="MySImporterService" Guid="{3EA5076C-C3FA-4A5F-95A5-365C6919DEB4}" KeyPath="yes">
<ServiceInstall Id="MyInstall"
Type="ownProcess"
Name="MyService"
DisplayName="MyService"
Start="auto"
Account="[SERVICE.USERNAME]"
Password="[SERVICE.PASSWORD]"
ErrorControl="normal" />
<ServiceControl Id="MyControl"
Stop="both"
Remove="uninstall"
Name="MyService"
Wait="no"/>
</Component>
It seems clear that (as Cole suggests) the values for SERVICE.USERNAME and SERVICE.PASSWORD are not correct. Those identifiers are Windows Installer properties that need to resolve to valid accounts at install time. A verbose log will show if they are getting set correctly.
Another issue may be that the install might get a repair, and that will result in re-install of the service so those properties would need to be available at that time as well as at install time.
Edit: Make sure that the property names are marked Secure=Yes in your WiX, otherwise they won't get preserved properly into the Execute sequence.

Wix Installer ignores elevated privileges when updating

Although the first installation works fine, when I try to update the application to a newer version, the installer presents the following message:
Service X could not be installed. Verify that you
have sufficient privileges to install system services.
When cancelling the update installation, the software is removed and if I install again, the process finishes successfully.
I'ts important to say that both install and update are requiring elevation of privilege.
Any ideas?
Elevation of Privilege
<Package InstallerVersion="300"
Compressed="yes"
InstallScope="perMachine"
InstallPrivileges="elevated"
AdminImage="yes" />
Service configuration:
<ServiceInstall Id="ServiceInstaller"
Type="ownProcess"
Name="X"
DisplayName="X"
Description="X"
Start="auto"
ErrorControl="normal" />
<ServiceControl Id="StartService"
Start="install"
Stop="both"
Remove="uninstall"
Name="X" Wait="yes" />
I can be many thing. I suggest to try couple of things.
-set account
<ServiceInstall Account="NT AUTHORITY\LocalService" />
-Install the MSI package. When the error dialog comes up do not dismiss the dialog. Start services.msc or use sc.exe from the command-line to attempt to start your service. If necessary debug into your service executable directly to see why it cannot be started.
Summery from Failed to install and start Windows services in WiX installer
-Ensure that it does not depend on files being placed in the GAC.
-Use event viewer to check the error.
-What is the name of the service? there is limitation on naming the service.
-if the service is already exist it can give you that insufficient privileges error, check that the service is uninstalled before installing again. Should be part of the upgrade procedure.
Hope it will get you started.