Wix Stop service when uninstalling / updating: prevent "pop-up restart" (file usage situation)

Question

I had a problem: when deleting (or updating), Restart Manager complains about the situation with the file, as well as the 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 running RESTART MANAGER is a Java based service. The service (here called myservice.exe) recursively starts Java child processes:

myservice.exe --run
↳ javaw.exe --someArguments
↳ someother.exe --someArguments
↳ javaw.exe --someMoreArguments

A wix snippet to define a service:

 <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 for the interesting part:

• Service can be started during installation

when deleting:

• If it is not running, it will be deleted
• at startup and just agreeing to reboot
  • it really stopped for about 2-3 seconds (I think the StopServices action)
  • and successfully removed (using the RemoveServices action)

The entries in the Service * tables are still good for me.

 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 everything: It seems that Restart Manager does not recognize that java processes are child processes and will be stopped by the StopServices action.

I found similar problems here: https://www.mail-archive.com/ [e-mail] /msg57924.html
Wix installer problem: why RestartManager marks Service as RMCritical and not RMService

Thank you in advance for your help in solving this problem!

Answer 1

You have several options for solving this problem:

-Disable "Restart Manager" using MSIRESTARTMANAGERCONTROL = "Disable" in the property table. This may cause the FilesInUse dialog box to become obsolete. In your case, the FilesinUse dialog box may also not be displayed (because services do not have a window associated with them) The FilesinUse dialog box does not display processes that do not have a window associated with them . Thus, in your case, disabling the restart manager may not display any dialogs (neither FilesInUse nor RestartManager).

However, it also means that a reboot may be required, not necessarily because of your services, but because of another process that may contain your files. If you think that there can be no other process besides your own services containing files, then go ahead and follow this approach. If you think that there may be other processes other than your services containing files, then with the support of "Restart Manager" . The absence of a "Restart Manager" will result in either of the following things:

-Open the Legacy FilesInUse dialog box, in which you are asked to close the processes listed in the dialog box. This may result in you having to shut down these processes with a custom action.

Both the RestartManager and FilesInUse dialogs are displayed by the standard InstallValidate action. If you want to disable both of these dialogs, make sure your custom action is scheduled before the standard "InstallValidate" action. There is a catch here. Planning such a user action before InstallValidate should be an immediate user action (you cannot have deferred user actions until "IntsallFinalize"). Thus, in cases when you are not working as an administrator (for example, in scenarios with UAC enabled), you may not have the necessary privileges to close applications. Therefore, a reboot may be required.

-You can also disable applications using the WiX extension function to use the CloseApplication () function. Evaluate your script and do what suits you.

Answer 2

I think I can be late for the party, but here is the solution. The installer team blog post explains how Restart Manager decides whether a file dialog should pop up. In particular (section "Interaction with the Windows Installer Manager", section 3.b.):

If the package is created so that the services discovered by RM are disabled due to the creation of Service * tables, then these services will not be displayed in the Files In Use dialog box.

(italics mine). Useful, but not immediately useful, because it is not so detailed. But since my service caused the same problem as the OP with

 <ServiceControl Stop="uninstall" ... /> 

I just changed the value to both

 <ServiceControl Stop="both" ... /> 

which was probably the only thing left 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 seems that in ServiceControl , to make RM happy ending, that the service will stop before updating the files.

---

In retrospect, this makes sense. Since the deletion part of the upgrade is performed using the old cached MSI database, RM does not look into it to see what happens when the corresponding product is deleted. Strictly speaking, there can be several products for removal, and the installer does not require anywhere that these related products (the found FindRelatedProducts action , including the old version of the same update code) are actually associated with the service that manages in the current package. Therefore, he does not care about the action of the service during uninstallation, as it is written in the current package (in any case, this does not apply to the installation action!). Consistency requires simple and direct evidence that the service will be stopped before the files that will be used are overwritten, collecting such data only from the current package.

Thus, it is likely that RM only cares about the msidbServiceControlEventStop (0x002) flag during installation.