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

Question

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/[email protected]/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!

Aegean

Answer 1

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.

Spinose

Setting MSIRESTARTMANAGERCONTROL="Disable" did perfectly well. Anyway, i ran now into another issue: The InstallValidate action now claims in the log, that msvcr100.dll is held by some other processes. The thing is, these processes do have a handle to a msvcr100.dll, but not the one, whis is provided by this installation. They have their own (checked with ProcessExplorer). As result, a "FileInUse"-Dialog is displayed, that Outlook needs to be closed to continue (in my case, the only application that has a window). Is it possible, that the Installer is buggy in some way here? – Aegean

Very unlikely that there is a bug in your installation. Trust what the FilesInUse and the RestartManager do. I have seen installations where even having the command window open complains asking me to shut down the command window. I dont think there is any bug, its just the way these things work. Just a wild guess. If the msvcr100.dll used by your processes is being used from C:\windows\winsxs ... directory, then its possible that even outlook.exe is using the same ones. FileInUse sees that Outlook.exe has a window associated with it, and hence flags it for shutdown. – Spinose

where do you install your runtime dll's? In the global winsxs directory or into your application folder. – Spinose

into the application folder. Log-File says: InstallFiles: File: msvcr100.dll, Directory: D:\myapplication\jre\bin\, Size: 773968 1: {C5A8FA5F-A1FF-4506-8673-855F34E94824} 2: {E769B299-36EE-58F1-961F-2EC7CA556566} 3: D:\myapplication\jre\bin\msvcr100.dll – Aegean

posted a new question, since this seems to be now a different issue: #31809823 – Aegean

Answer 2

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.

Dolley