Wix installer problem: why RestartManager marks Service as RMCritical and not RMService

Question

I am trying to prevent our wix installers from asking the user to reboot upon removal. Our services must be deleted and removed upon deletion. Unfortunately, for us, RestartManager asks the user that a reboot will be required during the InstallValidate action. This action occurs long before the StopServices and DeleteServices actions.

Checking the logs, it seems that RestartManager considers our service to be a critical process:

"An application with an identifier of 1234 was found, the friendly name is" abc ", the short name of the service is" xyz "of type RmCritical, and status 1 contains the files [s]."

Services are installed and launched under the local system account. I'm not sure, but I think if RestartManager returned an RmService instead of an RmCritical, then it would not request a reboot.

Any help is greatly appreciated.

EDIT: MSDN states that for RMCritical: A system restart is required to complete the installation because the process cannot be disabled. The process cannot be disabled for the following reasons. A process can be a critical process. The current user may not have permission to terminate the process. This process may belong to the primary installer that launched the reboot manager.

The user has permission to close the services, and the services have nothing to do with msiexec, so I can only assume that our service is considered a critical process ... but why?

Answer 1

You can disable the RestartManager window by setting the MSI property MSIRESTARTMANAGERCONTROL = "Disable" (see the documentation here - http://msdn.microsoft.com/en-us/library/windows/desktop/aa370377(v=vs.85).aspx ) The only problem with this approach in itself is that instead of asking users for a dialog that requires a reboot, they will see a File In Use dialog box (and will ask them to close all applications that can use these files / services). This dialog is displayed during the standard InstallValidate action of the InstallExecute sequence.

If you want to sneak through any of these dialogs, you can schedule a custom action before InstallValidate, which manually disables any running services before RestartManager can check the system. This is not consistent with standard MSI methods, since you usually mark a custom action that changes the system as a pending action, but MSI does not allow pending actions until InstallValidate. Thus, you will need to mark the action as "immediate", but in the code you would go and change the system by disabling services. The disadvantage here is that there is no such thing as an immediate rollback action, so if your uninstall / update fails and a rollback occurs, the services you stopped will be left in a stopped state. The surface is that users will never have to see any additional dialogs during their removal / update.

Answer 2

Also turn it on.

The problem is that the restart manager does NOT think that the user has permission to stop the service, even though he is doing this, because at the time he checks (InstallValidate), the installation is not yet upgraded.

My solution is to give a group of users the right to start and stop the service. I used the sc sdset to change the permissions of the service.

Or you can use the bootloader to start MSI after the upgrade.

Answer 3

Restart Manager usually does not request any files in usage situations for services that are marked to stop in the current operation. In other words, it goes through the ServiceControl table to make sure that the service will be stopped anyway and will not automatically request the files to be used.

Unfortunately, this behavior was once compromised by an error - only the first record in the ServiceControl table was checked. I do not know if this error has ever been documented, so I can not quote anything. The original question was published in 2011, so I would suggest that this particular question has been fixed. The only problems of this kind that are currently occurring, as a rule, are situations when a service is a multiprocess in a sense or a wrapper (some java services are similar to this) or when a service really ceases to be a service, but the process containing immediately or ServiceControl does not make full expectations, and it still works.