Finally, when one puts this information together, the chances are high that another process, such as SMS or Group Policy, is triggering a silent install of a MSI based product thus the mutex is preventing the simultaneous install of the second product.

Solutions 1

To solve for this scenario, one needs to understand the mechanics of determining if Windows Installer is busy and then one needs to consider the appropriate behavior for their application for the "busy" case.

Generally if Windows Installer is busy , Windows Installer will set the Mutex. For a sample demonstrating the mechanics of checking the mutex, see the Windows Installer Platform SDK bootstrapper code example:

For Windows Installer 3.0 or greater, we recommend switching from the mutex to attempting to stop the msi service. If you are unable to stop the service, the service is busy installing another product. In pseudocode, these mechanics would look like

if (MSIServer is not running)
bInstallRunning = true; // because if the service isn't running there can't be an install running
else if (MSIServer accepts SERVICE_ACCEPT_STOP)
bInstallRunning = false; // because if it can stop it can't be installing something
else
bInstallRunning = false; // because it won't accept the stop, so it's doing an install.

With either of these solutions, a non-privileged context will be unable to detect the state of the engine.

Now that you know the mechanics, you need to consider what to do when the Windows Installer is "busy". There are a number of options and which one you choose depends on your judgment. Some solutions choose surface the fact that the Windows Installer is busy and suggest the user try again later. Other solutions choose to put the "busy" check in a polling loop and attempt an auto recover from the mutex.

Question 2

I have a Windows Installer package that InstallInitialize shows all the features and components are installing Action:Local but after the install the feature is advertised. Can you help explain this? (msi packages and verbose logs sent too)

Answer 2

Generally to find these issues I look at the components with conditions. In this case we have the following Component Table Fragments

If it were true that this property was set, it would cause the component to be absent and its absence would cause the feature to appear advertised.

Design Suggestion for Question 2

If the advertised state on the feature is the problem, I suspect what’s called for here is another feature. One could have a child feature that just contains the components that will be toggled and is marked to follow parent. Depending on whether that works for all scenarios, there is also the option to have the new feature sit at the root and then write code to toggle the state of the feature.