Issue with CloseApplications using WiX 5.0.2

[radu-solomon]

We have an installer for our app that consists of a service and a TrayIcon. During Upgrades, we always get the error that the TrayIcon has files in use and needs to be killed, which fails.

I read that CloseApplications is intended for this kind of usage, closing TrayIcons and other apps, and tried to implement it.

The problem I am facing is I need this to run before RestarManger fires and prompts for it but no matter what I try it always errors out with

Error 2762: Unable to schedule operation. The action must be scheduled between InstallInitialize and InstallFinalize.

I read that setting RebootPrompt=no should fix this but no luck. No matter what values I set its always the same error.
If I move it after InstallInitialize it will be too late as the RM had already prompted for the kill so it defeats the point.

The code that I tried

<util:CloseApplication Id="CloseTrayIcon" Target="$(var.TrayIconFileId)" TerminateProcess="1" RebootPrompt="no" />

<Custom Action="override Wix4CloseApplications_$(sys.BUILDARCHSHORT)" After="InstallValidate"/>

What is see in the logs and confuses me is that it starts as Wix4CloseApplications_X64 and than part way through it switches to Wix4CloseApplicationsDeferred_X64 and that is when it fails

MSI (s) (38:50) [19:30:28:032]: Doing action: Wix4CloseApplications_X64
MSI (s) (38:50) [19:30:28:032]: Note: 1: 2205 2: 3: ActionText
Action 19:30:28: Wix4CloseApplications_X64.
Action start 19:30:28: Wix4CloseApplications_X64.
MSI (s) (38:50) [19:30:28:041]: Creating MSIHANDLE (14) of type 790542 for thread 27216
MSI (s) (38:80) [19:30:28:043]: Invoking remote custom action. DLL: C:\windows\Installer\MSI1716.tmp, Entrypoint: WixCloseApplications
MSI (s) (38!54) [19:30:28:053]: Creating MSIHANDLE (15) of type 790541 for thread 28756
MSI (s) (38!54) [19:30:28:055]: Creating MSIHANDLE (16) of type 790531 for thread 28756
WixCloseApplications: Entering WixCloseApplications in C:\windows\Installer\MSI1716.tmp, version 5.0.2.0
MSI (s) (38!54) [19:30:28:057]: Closing MSIHANDLE (16) of type 790531 for thread 28756
MSI (s) (38!54) [19:30:28:058]: Creating MSIHANDLE (17) of type 790540 for thread 28756
MSI (s) (38!54) [19:30:28:059]: Creating MSIHANDLE (18) of type 790531 for thread 28756
MSI (s) (38!54) [19:30:28:061]: Creating MSIHANDLE (19) of type 790531 for thread 28756
MSI (s) (38!54) [19:30:28:062]: Closing MSIHANDLE (19) of type 790531 for thread 28756
MSI (s) (38!54) [19:30:28:064]: Closing MSIHANDLE (18) of type 790531 for thread 28756
MSI (s) (38!54) [19:30:28:065]: PROPERTY CHANGE: Adding Wix4CloseApplicationsDeferred_X64 property. Its value is 'TrayIcon.exe�32�5000�1'.
MSI (s) (38!54) [19:30:28:066]: Creating MSIHANDLE (20) of type 790531 for thread 28756
MSI (s) (38!54) [19:30:28:068]: Closing MSIHANDLE (20) of type 790531 for thread 28756
MSI (s) (38!54) [19:30:28:069]: Doing action: Wix4CloseApplicationsDeferred_X64
MSI (s) (38!54) [19:30:28:070]: Note: 1: 2205 2: 3: ActionText
Action 19:30:28: Wix4CloseApplicationsDeferred_X64.
Action start 19:30:28: Wix4CloseApplicationsDeferred_X64.
MSI (s) (38!54) [19:30:28:077]: Note: 1: 2762
MSI (s) (38!54) [19:30:28:077]: Note: 1: 2205 2: 3: Error
MSI (s) (38!54) [19:30:28:078]: Note: 1: 2228 2: 3: Error 4: SELECT Message FROM Error WHERE Error = 2762
DEBUG: Error 2762: Unable to schedule operation. The action must be scheduled between InstallInitialize and InstallFinalize.
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2762. The arguments are: , ,
MSI (s) (38!54) [19:30:41:491]: Note: 1: 2205 2: 3: Error
MSI (s) (38!54) [19:30:41:492]: Note: 1: 2228 2: 3: Error 4: SELECT Message FROM Error WHERE Error = 1709

Is there any way to achieve this without getting the file in use prompt, and if yes, how? Or am I out of luck? And why does it switch to Wix4CloseApplicationsDeferred_X64 ?

[wmanning]

And why does it switch to Wix4CloseApplicationsDeferred_X64 ?

I can at least answer this part. MSI installation is divided up into two parts:

• immediate --> the UI or data collection phase that is done with the permissions of the user
• deferred --> this is where things are actually installed. this runs with system privileges

Due to the above a lot of custom actions will come in pairs: one to collect data, etc, and one to actually execute the desired actions.

[wmanning]

Error 2762: Unable to schedule operation. The action must be scheduled between InstallInitialize and InstallFinalize.

Between those two is considered the deferred phase so that's why you have to schedule between them.

[wmanning]

Was curious and did some digging. Appears not possible unless you disable restart manager: https://stackoverflow.com/questions/3112121/wix-uninstall-close-application-before-restart-manager.

[radu-solomon]

Thank you and yes I am aware of the phases. I may have misunderstood the role of the CloseApplications CA. If it doesn't run until after RM did its thing and flagged things that hold files what exactly is its use? If I can only run it after RM already attempted to close things and flagged the reboot required I don't see much value for it. And if that is true what is the correct way to shut down the TrayIcon when the upgrade starts before InstallValidate?

I have been experimenting with things for a week now and I can't find a reliable way to not have the installer prompt the user that the app has files in use which I am trying to do.

[wmanning]

From the code,

• the WixCloseApplications custom action will only send the WM_CLOSE or WM_QUERYENDSESSION in the immediate (aka UI) stage
• It will also schedule a deferred custom action WixCloseApplicationsDeferred to do so again. If the app is still running it'll either terminate the app's process or schedule a reboot as a last resort if the app is still open. All depending on the CloseApplication configuration.

So appear no way to get around what you are seeing. It probably doesn't force close in the immediate stage as technically that is changing machine state (killing app) and the user could abort the install.

[radu-solomon]

Thank you for confirming that what I was seeing in the code and the way I was interpreting it was accurate. It looks like this for now is a dead end and I need to look into other options to accomplish my goal.