WM_QUERYENDSESSION and WM_ENDSESSION not received if main process has subprocesses

[fabian-paul]

Hi all

I'm new to MSI and to the WiX toolchain. If I am wrong in this forum I would appreciate if you direct me to the right place.

I am having a problem packaging my self-developed application as an MSI package. The application is written in Python/Qt and uses the Win32 API (no dotNET). For packaging I use the WiX toolchain in version 3.11. I was able to create a MSI package by following the tutorial from Firegiant. The initial installation of the package on Windows 10 Enterprise 22H2 works perfectly. Unfortunately, uninstall and software updates do not work with the packages I created, exactly when my application runs subprocesses.

I have tested the MSI/WiX standard function to stop applications as well as an additional CloseApplication action. Both variants show the same error pattern, which is as follows:

As described in the WiX/MSI documentation my application handles the two signals WM_QUERYENDSESSION and WM_ENDSESSION to terminate itself in a controlled way. This works perfectly as long as my application consists of only one process. But as soon as my application executes a background process, which has no main window with a message loop, the signals WM_QUERYENDSESSION and WM_ENDSESSION are not triggered in the main process anymore. Only a hard termination with the CloseApplication action (when the TerminateProcess option is set) works, but without the WM_*ENDSESSION signals arriving before.

This behavior seems a bit mysterious to me. I can only assume that the function implemented in MSI goes through all processes, sends the WM_*ENDSESSION signals and gives up the whole shutdown process at the first process that does not respond correctly to the signals. This also seems to be fundamentally different from the use of the WM_*ENDSESSION signals during a real shutdown of the computer. There the signals seem to be broadcasted to all applications without the order or non-cooperating processes preventing the reception of the signals.

My question is: is this a bug or a feature? Or am I using WiX/MSI incorrectly or is there another error elsewhere?

Unfortunately, I cannot completely control one of the subprocesses of my application because it belongs to a Chromium browser embedded as a Qt widget (QtWebEngineProcess.exe). It does not have it own main window, but uses the window of the main process. Normally the main process of my application is responsible for the termination of the subprocesses. I have already tried adding an additional CloseApplication action with Target=QtWebEngineProcess.exe. Unfortunately this did not help.

For the subprocesses of my application that I can control, I was able to solve the problem by adding a GetMessage+DispatchMessage loop in an extra thread.

Unfortunately, I can't add this for the Chromium process because I don't want to change the Chromium code.

What can I do to address this issue? If it helps, I can provide a minimal example in a follow-up.

Thanks
Fabian

[robmen]

WM_QUERYENDSESSION and WM_ENDSESSION are Windows messages. You've left the land of WiX and MSI and are now 100% in the land of HWNDs and message pumps. Maybe some people here have experience with these messages, but to be clear, you'll see the same messages at Windows shutdown. So, do not consider this a "setup problem" as you search.

PS: IIRC, the documentation for those WM_ messages indicates they are sent to all top-level visible windows. But it's been a while since I dug into the mysteries of the shutdown messages.

[fabian-paul]

Thank you for the quick reply!

I will follow your hint about the distinction between visible and invisible windows and investigate this.

Is there any way to check how exactly the CloseApplication action is implemented? Is this part of the WiX dll WixUtilExtension.dll?

My hypothesis is that there is after all a difference in the implementation of computer shutdown and application termination in the context of setups, especially in error handling of processes that do not handle signals correctly. In my (test) application I can clearly see that signals are received during shutdown but not during uninstall.  This seems to me to be a case of the infamous "leaky abstractions".

Ideally, I would then change the CloseApplication action to be a bit more robust against non-cooperating processes. Is it possible to see the source code for the CloseApplication action?

[robmen]

CloseApplication is a WiX CustomAction so the source code is available as WiX is an open source project.