Wix Installer Problem: Why does RestartManager mark Service as RMCritical and not RMService_问答_开发者

I'm trying to prevent our wix installers from prompting the user for a reboot when uninstalling. Our services are set to be uninstalled and deleted on an uninstall. Unfortunately for us the RestartManager is prompting the user that a reboot will be required during the InstallValidate action. This action occurs well before the StopServices and DeleteServices actions.

Checking the logs, it seems that the RestartManager thinks that our service is a critical process:

"Detected the application with id 1234, friendly name 'abc', service short name 'xyz', of type RmCritical and status 1 holds files[s] in use."

The services are installed and running under the local system account. I'm not sure but I think if RestartManager was returning RmService instead of RmCritical then it wouldnt be prompting for a reboot.

Any help much appreciated.

EDIT: MSDN states that for RMCritical: A system restart is required to complete the installation because a process cannot be shut down. The process cannot be shut down because of the following reasons. The开发者_开发技巧 process may be a critical process. The current user may not have permission to shut down the process. The process may belong to the primary installer that started the Restart Manager.

The user does have permission to shut down the services, and the services are not anything to do with msiexec so I can only assume that our service is thought to be a critical process.... but why?

You can suppress window's RestartManager by setting the MSI property MSIRESTARTMANAGERCONTROL= "Disable" (see documentation here - http://msdn.microsoft.com/en-us/library/windows/desktop/aa370377(v=vs.85).aspx). The only problem with this approach by itself is that instead of prompting users with a reboot-required dialog, they will see the file-in-use dialog (and be asked to shut down any applications that might be using those files/services). This dialog is displayed during the InstallValidate standard action of the InstallExecute Sequence.

If you want a sneaky way around either of these dialogs you can schedule a custom action before InstallValidate that manually shuts down any running services before the RestartManager has a chance to inspect the system. This does not follow standard MSI practices because normally you would mark a custom action that modifies the system as a 'deferred' action, but MSI doesn't allow any deferred actions to run before InstallValidate. So, you would have to mark the action as 'immediate', but in the code you would go ahead and modify the system by shutting down the services. The drawback here is that there's no such thing as an immediate rollback action, so if your uninstall/upgrade fails and does a rollback the services you stopped will be left in a stopped state. The upside is that users never have to see any additional dialogs during their uninstall/upgrade.

Ran into this also.

The problem is that the restart manager does NOT think the user has permission to stop the service even though it does because at the time that it checks (InstallValidate), the install has not elevated yet.

My solution is to give the Users group permission to start and stop the service. I used the sc sdset command to change the service permissions.

Or you can use a bootstrapper to start the MSI after elevating.

Restart Manager will not normally prompt for any files-in-use situations for services that are marked to be stopped in the current operation. In other words it goes through the ServiceControl table to see if the service will be stopped anyway, and will not automatically prompt for in-use files.

Unfortunately this behavior was compromised at one time by a bug - only the first entry in the ServiceControl table was checked. I don't know if this bug was ever documented so I can't cite anything. The original question was posted in 2011, so I would assume that this particular issue has been corrected. The only issues of this kind that occur now tend to be situations where the service is multi-process in some sense, or jacketed (some java services are like this) or when the service does indeed stop being a service but the containing process does not complete promptly, or the ServiceControl doesn't do a full wait and it is still in fact running.