Concurrency Considered Harmful: You should not run embedded installers from within an MSI setup by means of custom actions. For MSI files there are technical impossibilities that exist (1, 2, 3, 4) - in essence only one MSI installation sequence can run at a time (unless you kick them off from the user interface, which is not advisable since your setup then fails silent install). For EXE files it is a legendary source of difficult-to-debug problems.
Burn: A better approach is to use a WiX Burn bundle (setup.exe
) to kick off installs in sequence - one after the other. Here is a quick sample of such a burn bundle running one EXE setup and one MSI setup. Burn features its own logging mechanism.
Stuck Custom Action: Technically the custom action(s) running the executable(s) in question got stuck, I guess. How have you sequenced the custom actions? Are they in the user interface sequence? What are they installing? Setups? Zip extractions? Something home-grown?
msiexec.exe: The msiexec.exe
processes will stay behind in the process list for some time even after installations have completed successfully (about 10 minutes I think). They will certainly stay there - indefinitely - if the setup hung. There can be numerous msiexec.exe
processes in the task list - even when everything is working correctly - because of the MSI file featuring GUI run in user context and custom actions run in various contexts. Several users can also be logged on.
Logging: Do you have logging enabled so you can check what happened? Please try to log the installation to see what it
says in there (see previous link for how to enable logging for all MSI installations - Section: "Globally for all setups on a machine"). Here is how to log a single installation:
msiexec.exe /i "Setup.msi" /L*V "C:\Setup.log"
The above command line already implements logging, but here are more details on logging and interpreting the log file: