Kill my application during uninstall - wix

I have run into challenging problem trying to accomplish the following:
my application installs a service (watchdog.exe) and an exe file (app.exe).
After the installation is done the service starts and creates process "app.exe".
during uninstall I want to kill the process "app.exe" (which is running under local system account, so I must be running as admin).
problem 1:
The installs says that it requires a reboot since it sees that file "app.exe" is being held (running) during the CostFinalize phase (please correct me if I'm wrong about the phase that checks if a reboot will be required). It would be much better to kill the process when the uninstallation begins. I have verified that if the process is not running during the uninstall then the install does not complain about a reboot required.
problem 2:
using a custom action to kill the process is problematic. the action must run elevated, but on the other hand it must run before the costFinalize (otherwise - it's back to problem 1).
I would appreciate any suggestion. Also, any alternative solutions (is there another way to close the process maybe during install that will not require a reboot?)
The custom action code I have now (not good since it both unnecessarily asks for a reboot and fails to kill the process due to lack of permissions):
<InstallExecuteSequence>
<!--<ScheduleReboot After="InstallFinalize" />-->
<Custom Action="MyProcess.TaskKill" Before="InstallValidate"></Custom>
</InstallExecuteSequence>
<!--<Property Id="Net">Net.exe</Property>-->
<Property Id="QtExecCmdLine" Value='"[%SYSTEMROOT]\System32\taskkill.exe" /F /IM App.exe' />
<CustomAction Id="MyProcess.TaskKill"
BinaryKey="WixCA"
DllEntry="CAQuietExec"
Execute="immediate"
Return="ignore" />
Here is the log for the failure:
CAQuietExec: Error 0x80070001: Command line returned an error.
CAQuietExec: Error 0x80070001: CAQuietExec Failed
CustomAction MyProcess.TaskKill returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 18:15:54: MyProcess.TaskKill. Return value 1603.

There are few ideas that I have, namely:
Use EventWaitHandles, which allow processes to communicate between each other, and delegate your wish to app.exe. Your app.exe can then terminate, as needed. This is clean solution and should be prefered.
If for whatever reason you decide to kill the application like you don't care about anything at all in the world, then you can:
I saw today a project that can run MSI completely elevated, in all stages. It was Visual Stdio template, however I can't find it right now, but know that it exists there.
You can also use this, maybe it works: How do I get WiX installer to request administrative privileges?
Basically there are so many hackery tricks you can do, to kill the application. Such as using WiX Burn and requiring administration rights, then doing your thing. I would go with solution#1(create your own mechanisms)
By the way, if you use ServiceControl element in WiX, it will STOP the service before REINSTALLING/UNISTALLING. You can hook to OnStop() method in Service and kill your App.exe there. If you have set Service as App.exe parent, then there should be flag that any child processes die with parent.

Related

WiX waits for the launched process to complete installation

I am using the below lines to execute a process from an exe that is in the installed directory.
<SetProperty Id="LaunchMosquitto" Value=""[#fil7D28AEF774656849395A2FA20A5C963D]" -c [#filA995207A6EF3FF0B4A1912B4627C6A9E]" Before="LaunchMosquitto" Sequence="execute"/>
<CustomAction Id="LaunchMosquitto"
BinaryKey="WixCA"
DllEntry="WixQuietExec64"
Return="ignore"
Impersonate="no" />
I am using this approach to run the exe silently with arguments after the installation. But the installer is waiting for the spawned process to terminate for the installation to complete. Though the process is spawned, installer hangs there. It completes only when I close the spawned process. This is because of the Return=ignore property I believe. Perhaps async-no-wait would help. But that requires ExecCommand instead of the SetProperty. The problem in using that is it launches the command prompt after installation to spawn the process. Kind of caught in a dead lock here. Any help would be much appreciated.

Wix: Executing installed exe as a first action on Uninstall

In my msi, I have to call the installed exe file with some parameters, as a very first action of uninstall. Here is the code:
<CustomAction Id="UnRegisterOnUninstallApplication"
Execute="immediate"
FileKey="MyProgram.exe" ExeCommand="/unregister" Return="asyncNoWait" />
<InstallExecuteSequence>
<RemoveExistingProducts After="InstallInitialize"/>
<Custom Action="UnRegisterOnUninstallApplication" Before="UnpublishComponents" >Installed AND NOT UPGRADINGPRODUCTCODE</Custom>
</InstallExecuteSequence>
Although, it is scheduled Before UnpublishComponents, but issue is, at some computers, custom action is called during or after dependency dlls are uninstalled and so MyProgram.exe crashes here.
This is something seems unpredictable...
Can anyone please guide, if I'm missing something or doing something wrong???
Thanks a bunch.
There are several things incorrect here:
The design issue is that you shouldn't be running code to register or unregister. The recommended way is to capture the registry entries and add them as registry entries in the same component as that binary. Then it all just works.
Your custom action is asyncNoWait, and that means the uninstall continues while the program runs. If it takes a long time for some reason, or simply doesn't get enough of the processor, then yes, files may have been removed by the time it runs.
It's an immediate custom action, so it can run and start unregistering as the uninstall proceeds. However if the uninstall fails and rolls back the deleted registration will not be restored, so you'll end up with a broken product still installed, those registration entries will stay removed. It should be a deferred custom action and return = ignore or check, depending on whether you care if the program fails.
I might schedule the action before 'RemoveFiles' so that no dependent dlls have been removed before your custom action gets to run.

Wix stop service on uninstall/upgrade: prevent "restart popup" (file-in-use situation)

I've got the issue, that when uninstalling (or upgrading) the Restart Manager is complaining about a file in use situation, and so is forcing a reboot:
RESTART MANAGER: Detected that application with id 7000, friendly name 'javaw.exe', of type RmCritical and status 1 holds file[s] in use.
RESTART MANAGER: Did detect that a critical application holds file[s] in use, so a reboot will be necessary.
The service that RESTART MANAGER is complainig about, is a java-based service. The service (here called myservice.exe) is recursively starting java child processes:
myservice.exe --run
↳ javaw.exe --someArguments
↳ someother.exe --someArguments
↳ javaw.exe --someMoreArguments
The wix snippet for the service definition:
<DirectoryRef Id="BINDIR">
<Component Id="myservice.exe" Guid="PUT-GUID-HERE">
<File Id="myservice.exe" KeyPath="yes" Vital="yes"
Source="SourceDir\bin\myservice.exe"/>
<ServiceInstall Id="MyService" Type="ownProcess"
Vital="yes" Name="MyService" DisplayName="My Service"
Description="My Service" Start="auto" Account=".\LocalSystem"
ErrorControl="normal" Interactive="no" Arguments="--run"/>
<ServiceControl Id="MyService" Name="MyService" Wait="yes" Remove="uninstall" Stop="uninstall" Start="install"/>
</Component>
</DirectoryRef>
Now, the interesting part:
The service could be started when installing
on uninstall:
if not running, it will be removed
if running, and just agreeing to make a restart
it is indeed stopped within about 2-3 seconds (i guess by the StopServices action)
and successfully removed (by RemoveServices action)
The entries in the Service* Tables seems good for me so far.
ServiceControl-Table:
ServiceControl Name Event Arguments Wait Component_
MyService MyService 161 1 myservice.exe
ServiceInstall-Table:
ServiceInstall Name DisplayName ServiceType StartType ErrorControl LoadOrderGroup Dependencies StartName Password Arguments Component_ Description
MyService MyService My Service 16 2 32769 .\LocalSystem --run myservice.exe My Service
So, to break down everything:
It seems that the Restart Manager is not recognizing, that the java processes are child processes and will be stopped by the StopServices action.
I found some kind of similar problems here:
https://www.mail-archive.com/wix-users#lists.sourceforge.net/msg57924.html
Wix Installer Problem: Why does RestartManager mark Service as RMCritical and not RMService
Thanks in advance for any help to solve this issue!
You have a couple of options to resolve this issue:
-Disable "Restart Manager" by making use of MSIRESTARTMANAGERCONTROL= "Disable" in the property table. This would kick in the legacy "FilesInUse" dialog box.
In your case, The FilesinUse dialog might also not be displayed (since services do not have a window associated with them)
The "FilesinUse" dialog box does not list processes which do not have a window associated with them. So, in your case, disabling the Restart Manager, might not display any dialogs(neither FilesInUse nor RestartManager).
However, this would also mean that a reboot might be required, not necessarily because of your services but due to some other process which might be holding your files in use. If you think that there could be no other process other than your own services holding files, then go ahead and follow this approach . If you think that there could be other processes, other than your services holding files, then having "Restart Manager" enabled is ideal. Not having "Restart Manager" will either result in one of the things:
-Display the Legacy FilesInUse dialog asking you to shut down the processes listed in the dialog. This might result in you having to shut down these processes via a custom action.
Both the "RestartManager" and "FilesInUse" dialogs are displayed by the "InstallValidate" standard action. If you want to suppress both of these dialogs, then ensure that your custom action is scheduled before "InstallValidate" standard action. There is a catch here. Scheduling such a custom action before InstallValidate would have to be an immediate mode custom action(You cannot have deferred mode custom actions before "IntsallFinalize"). So , in cases where you are not running as an administrator(such as in UAC enabled scenarios), you might not have the necessary privileges to shut down applications. So , a restart might be required.
-You can also shut down applications using the using the WiX util extensions CloseApplication() function.
Evaluate your scenario and do what is right for you.
I think I might be late to the party, but here's the solution. The Installer team blog post explains how the Restart Manager decides whether to pop up the files in use dialog. Specifically (Windows Installer-Restart Manager Interaction in Detail section, item 3.b.):
If the package is authored such that the services detected by RM would be shutdown because of the authoring of the Service* tables then those services will not be displayed in the files-in-use dialogs.
(italics are mine). Helpful but not immediately helpful, because such that is not really elaborated. But since my service caused the same problem as described by the OP with
<ServiceControl Stop="uninstall" ... />
I just changed the value to both
<ServiceControl Stop="both" ... />
which was probably the only remaining thing that could make it “such that,” and boom, fireworks, magic:
MSI (s) (50:A0) [21:50:30:352]: RESTART MANAGER: Detected that application with id 6408, friendly name 'XXXX', service short name 'xxxx', of type RmService and status 1 holds file[s] in use.
MSI (s) (50:A0) [21:50:30:352]: RESTART MANAGER: Detected that the service xxxx will be stopped due to a service control action authored in the package before the files are updated. So, we will not attempt to stop this service using Restart Manager
It appears that both flags msidbServiceControlEventStop (0x002) and msidbServiceControlEventUninstallStop (0x020) need to be set in the ServiceControl table to make the RM happily conclude that the service is going to stop before files are updated.
In retrospect this makes sense. Since the uninstallation part during the upgrade is carried out using the old cached MSI database, RM does not look into it to see what is going to happen when the related product is uninstalled. Strictly speaking, there may be multiple products to uninstall, and the Installer does not require anywhere that these related products (those found by the FindRelatedProducts action, including the old version of the same upgrade code) be in fact related to the service that one is controlling in the current package. So it does not care about the service action on uninstall as scripted in the current package (it does not apply to the install action anyway!). For the sake of consistency, it requires a simple and straightforward evidence that the service is going to be stopped before the files in use are overwritten, gathering such evidence from the current package alone.
So it is quite likely that the RM cares about the msidbServiceControlEventStop (0x002) flag only during the installation.

PerUser install with Custom Action - UAC disabled

I'm using WiX to generate an MSI that installs a browser plugin on a perUser basis. I have a custom action to install a driver using DPInst (which needs elevated privileges).
The install works fine when UAC is enabled; Windows shows the prompt to elevate. However, if I have UAC disabled and try to install on a regular user account, dpinst.exe will get spawned until the computer freezes. (About a thousand times at last count).
In the <InstallExecuteSequence> I have:
<Custom Action="Install_Drivers" After="InstallFiles">NOT Installed</Custom>
My custom action is:
<CustomAction Id='Install_Drivers' Execute='deferred' Directory='DRIVERS' ExeCommand='"[DRIVERS]DPinst.exe" /SW /SA' Return='ignore' Impersonate='no'/>
I have Return='ignore' because, from what I understand so far, dpinst.exe always returns a non-0 code.
How can I ensure that the custom action fails correctly when UAC is disabled? On a related note, can I show a custom message to the user when the driver installation fails?
Further Information: I'm developing on Windows 7 currently, but targeting WinXP and up.
Edit Taking a look at the log for the installation these seem to be the relevant lines:
Executing op: CacheSizeFlush(,)
Executing op: ActionStart(Name=Install_Drivers,,)
Executing op: CustomActionSchedule(Action=Install_Drivers,ActionType=3170,Source=C:\long_redacted\Drivers\,Target="C:\long_redacted_path\Drivers\DPinst.exe" /SW /SA,)
Disallowing shutdown. Shutdown counter: 0
CustomAction Install_Drivers returned actual error code 1073807364 but will be translated to success due to continue marking
The bit about the shutdown is, I believe, when I logged off stop the installation. (Canceling doesn't seem to have any effect).
Try setting the 'Impersonate=no' attribute on the 'CustomAction' element, like this:
<CustomAction Id='Install_Drivers' Execute='deferred' Directory='DRIVERS' ExeCommand='[DRIVERS]DPinst.exe" /SW /SA' Return='ignore' Impersonate="no" />
Also note: you have a stray double-quote in your ExeCommand
Installing a driver is an inherently per-machine operation. A limited user can't do it. So with UAC disabled, it's not going to work. DPInst apparently doesn't get the hint that it doesn't have permissions and can't get them. Sounds like a bug in DPInst. You should change your installer to be per-machine and add a launch condition on the Privileged property to prevent the installer from starting for limited users without UAC.

Force user to reboot machine with Burn

I have a bootloader that I created with WiX 3.6/Burn and was wondering if there was a command similar to <ExitCode Behavior="forceReboot"/> that would execute only on uninstall after everything was executed in the <chain> tag.
You can put the ScheduleReboot action in one of your MSIs and condition the action to run on unistall. Burn will respect the restart request and inform the user a restart is required at the end.