Updater returns 0 when there are no updates

[mentalmushroom]

Hello. In my application I need to wait for the updater to finish checking, downloading and installing updates. I am following this guide. Instead of WaitForSingleObject(mutex, INFINITE) I am using MsgWaitForMultipleObjectsEx(1, hMutexes, INFINITE, QS_POSTMESSAGE, 0) as I have to handle WM_CLOSE event before the application window is shown. I've noticed when installer finishes and I press 'Run the application' MsgWaitForMultipleObjectsEx returns WAIT_OBJECT_0+1 as the updater sends some strange message 799 (0x31F) to my application. Could somebody here explain me what does that message mean? It seems like there is no windows message with that code. Can I reply on that message to stop waiting for the updater?

[mentalmushroom]

Digging deeper into the issue I've found the following:

1) When the updated application is launched from the update installer it checks for updates. At that moment the updater is still in the memory and the updater process called from the application wrongfully returns 0 (which means updates are available). So the application starts waiting for the mutex, but it doesn't get signaled. The application receives the undocumented message 799, though.

2) The problem happens with WaitForSingleObject function also. It is even worse, as in that case you can't handle any messages. So I am pointing to the issues with the official guide:
http://www.advancedinstaller.com/user-g ... dater.html

3) It looks like the behavior is different on Windows XP and Windows 8. On XP the updater does NOT seem to return zero when the updated application is launched, so the program doesn't wait for the mutex and starts fine. On Windows 8 the updater for unknown reason returns zero, however, if I don't launch the application, so the update installer finishes and manually run the application after that it will check for updates correctly.

[Daniel]

Hello,

1) When the updated application is launched from the update installer it checks for updates. At that moment the updater is still in the memory and the updater process called from the application wrongfully returns 0 (which means updates are available). So the application starts waiting for the mutex, but it doesn't get signaled. The application receives the undocumented message 799, though.

I'm afraid this behavior is caused by an Advanced Installer issue. We apologize for the inconvenience.

If a second instance of the Updater is launched (while a first instance of the Updater is still running), then the second instance it will always return 0. We are aware of this issue and a fix will be available in a future version of Advanced Installer. We'll update this thread as soon as the fix will be out. Until then, I'm afraid there is no workaround.

All the best,
Daniel

[mentalmushroom]

Maybe it's not a bad idea to check whether the updater process is already in memory before running it? Or do you think it's a faulty approach?

The problem would not be that painful if MsgWaitForMultipleObjectsEx/WaitForSingleObject returned in that case, but it doesn't (updater and the installer hang up in the end). Or, more precisely, it depends on the system version or the system state. On my working machine (Win 8.1 x64) the first updater exists, so MsgWaitForMultipleObjectsEx returns 128 (mutex abandoned) and GetLastError() returns 183 (cannot create a file when that file already exists). On the virtual machine I was testing on Windows 8 and there updater hangs, so MsgWaitForMultipleObjectsEx doesn't return unless I enter or leave the fullscreen mode . In that case it also returns 128, but GetLastError() is zero. On XP (also tested on VMware) updater doesn't return 0, so there seems to be no problem at all.

[Daniel]

Hello,

Maybe it's not a bad idea to check whether the updater process is already in memory before running it? Or do you think it's a faulty approach?

Yes, we already have implemented this check and the improvement will be available starting with AI 12.0 (two versions from now on).

The problem would not be that painful if MsgWaitForMultipleObjectsEx/WaitForSingleObject returned in that case, but it doesn't (updater and the installer hang up in the end). Or, more precisely, it depends on the system version or the system state. On my working machine (Win 8.1 x64) the first updater exists, so MsgWaitForMultipleObjectsEx returns 128 (mutex abandoned) and GetLastError() returns 183 (cannot create a file when that file already exists). On the virtual machine I was testing on Windows 8 and there updater hangs, so MsgWaitForMultipleObjectsEx doesn't return unless I enter or leave the fullscreen mode . In that case it also returns 128, but GetLastError() is zero. On XP (also tested on VMware) updater doesn't return 0, so there seems to be no problem at all.

Can you please send us an email to support at advancedinstaller dot com regarding this issue so we can send you a modified version of our Updater tool which should avoid this behavior. Just mention this thread in your email.

All the best,
Daniel

[Dan]

Hello,

This was fixed in version 12.0 of Advanced Installer released on April 2nd, 2015 .

Best regards,
Dan