Waiting to Install

re: Waiting to Install

Heath Stewart — Fri, 01 Jun 2012 10:25:11 GMT

@kashif, sorry, but that is not supported or even possible that I know of. There are WMI classes that may work, but these are not documented and do not seem to represent running instances.

Why do you need to know what is installing instead of just waiting?

re: Waiting to Install

kashif — Mon, 09 Jan 2012 08:05:47 GMT

I need to know the product code of the product that windows installer is installing before launching my installer. I can check the mutex but it only tells me that Windows installer server is busy or not. Is there a recommended way to find the product code that is currently being installed?

The Windows Installer Service

Heath Stewart's Blog — Fri, 08 Dec 2006 21:11:22 GMT

Some have noticed that the msiexec.exe process seems to run for quite some time after a known installation

re: Waiting to Install

Heath Stewart — Mon, 10 Jul 2006 22:33:15 GMT

Matt, WaitForSingleObject will wait to own the mutex, waiting either till the mutex is signaled or till any expiration interval expires. It then may own the mutex, thus changing the state from signaled to nonsignaled and other threads calling WaitForSingleObject on the mutex will wait. Any other thread trying to own the mutex will fail unless it waits for the mutex in a similar manner. Windows Installer by default will fail with ERROR_INSTALL_ALREADY_RUNNING (1618). This is why a bootstrap application must implement waiting on the mutex.

re: Waiting to Install

Matt Gerrans — Mon, 10 Jul 2006 19:47:42 GMT

Hmm... Maybe I'm missing something. Where do you take ownership of the mutex? And as I said before, if you did, wouldn't that prevent the install from working?

re: Waiting to Install

Heath Stewart — Fri, 07 Jul 2006 19:04:23 GMT

Matt, you can choose to wait indefinitely or finitely - it's your choice based on your requirements. This is only an example of how to wait for Windows Installer to finish the current server action.

If you don't install the package on the thread that opened the mutex, the server action will fail because the thread won't own the mutex. That's the whole point of using a mutex - to block other threads and processes until another thread can own the mutex.

Making the thread real-time priority is another design consideration you should make based on requirements. This example certainly doesn't need to assert that it should be the next in line, and giving the thread a higher priority won't necessarily guarantee that it would be anyway.

re: Waiting to Install

Matt Gerrans — Fri, 07 Jul 2006 04:49:08 GMT

An enhancement might be to have a time out and failure rather than an INFINITE wait.

Even fancier would be popping up a dialog with a cancel button that says we're waiting on another install.

Is the "// Install the package on the current thread owning the execution mutex." comment in your code correct? I don't see where the mutex is opened in this code (and anyway, it would hose msiexec if it were).

And finally, it might be helpful to up the thread priority to realtime as soon as we get the mutex, so our install is a little more likely to be the first one to get to the point where msiexec grabs the mutex.

Common Controls in Windows Installer UI

Heath Stewart's Blog — Wed, 08 Feb 2006 04:50:49 GMT

How to display new controls with Common Controls 6 in your Windows Installer dialogs with a different bootstrap or external UI handler application.

http://blogs.msdn.com/windows_installer_team/archive/2005/11/09/487559.aspx

TrackBack — Wed, 01 Feb 2006 02:40:40 GMT

re: Waiting to Install

Heath Stewart — Tue, 24 Jan 2006 07:19:09 GMT

Phil, that's exactly the problem - even if you're waiting for the service to stop (say, polling for acceptance of the stop request or even if the service is running) there exists a race condition. Using the _MSIExecute mutex will guard against such a race condition.

Also, the second line of the same pseudo-code to which you refer should also be "bInstallRunning = false". If the service isn't running, no install is processing. mikeb's comment is correct there.