msiexec.exe lingers after install (or even after reboot) preventing subsequent msi's from working

providing your running on an NT based system. The Windows Installer runs as an on-demand service. If you open up the taskmanager before the very first execution of an MSI installation, you will see in the process list, nothing, start an installation, and you will eventually see multiple instalnces of the msiexec.exe process running. One usually started by the account that initialized the installation, and an other(s) that have been started by the system service account.

Once the installation has finished, the initial instance that was started by you (named account) will finish and no longer appear in the taskmanager, however, there should remain one instance that hs been started by the system account (service) and this will remain until the machine is rebooted.

Hope this helps,

Cheers
Phil

What we are seeing, though is two instances owned by SYSTEM after the computer has been rebooted.

a user get an error message that the installer is in use is unusual. Do you have any nested msi installations in your main msi? Are you using active setup to call the msi repair?

Have you noted to CPU usage of the msiexec.exe that "lingers" in memory? IF it changes, then obviously you installation IS NOT complete, and this would explain the "lingering".

What OS are you working on?

Cheers
Phil

Thanks for taking the time to help.

I have no nested MSI installations in my main msi.

I am not sure if I am using active setup to call the msi repair (not sure I understand the question - I know I am not conciously using active setup to call the msi repair, but I'll be the first to admit that I don't always know what I'm doing...)

I will have to check the cpu usage, but I don't think it's using anything.

The operating system that we have noticed it on has been strictly XP (Vista and Windows 7 we also tested, but have not observed the problem there.) 

I should also mention that the problem is intermittant.   It's been frustrating us because we get it to happen, then want to try something, but can't get it to repeat and such.

Carl.

but when this problem occurs, i.e. you get an error message that he installer is in use, coiuld you have a look at the event log? Perhpas there is a repair running in the background, that is affected by the initial installation of your app. Check for any msi activity in the event log (missing keypaths / component errors o.a.

Cheers
Phil

Are you installing manually or via a software distribution system such as SMS?
The description of the problem suggests that the MSI install has not completed, and this could be due to a dialog box being opened in system context which the user cannot see, especially if the method of installation is a system installer such as SMS or NS.

One cunning little ploy you could try, is to add a Type 38 custom action (Run VBScript from Embedded), and sequence it in InstallExecute sequence, as the last action in the sequence.
For the actual code use

msgbox "Finished",4096,"Application Install"

When the MSI gets to the last action, it will display a system model message box with "Finished" in it.

Until you see this box and press OK to allow the MSI to terminate, you can assume that MSIEXEC is still active for your installation.

So if your install appears to have completed, but it takes a further 10 minutes to display the message box, that will tell you that something in your install has been keeping MSIEXEC busy up to that point, and you can then look further at the time of the various actions in your verbose installation logfile.
If you give the custom action above a unique name, you can verify the timestamp of this custom action and all preceding actions, and maybe locate the action that is running for those 10 minutes.

One further thought I had, is that perhaps the install of this application is somehow damaging an existing application on the workstation, and a self healing operation is being kicked off which is causing MSIEXEC to remain busy for a while after the install.

So have a look in the event viewer, under the applications tab, just after you think your install has finished, and check what the event log reports.
Then check it again 10-15 minutes later. You should certainly find the timestamps for the completed MSI install, and also any other subsequent activity which may explain the running msiexec instance.

Good idea.  I'll check out the event viewer next time the symptoms occur.

BTW: This is a pretty standard install - double-click on the msi, then click "next" a bunch of times.  The install itself, though, is fairly complex with quite a few custom actions and such.

Thanks!

Carl.

Check your installexecute sequence for any custom actions that run near or at the end of the sequence, and then check if they are set as Synchronous or Asynchronous.  My thinking is that if there happens to be a custom action at the end of the sequence that is performing a cleanup of the hard disk, for example, and the custom action is set to synchronous, then msiexec will not be able to terminate execution of the MSI until the custom action completes. If at the same time, the custom action is not able to complete the clean up and then needs to time out, this could account for the delay in msiexec terminating. Again, this is pure speculation, but as it's not entirely clear from previous postings as to whether this MSI is a vendor MSI or one that you have created, I throw this in for consideration, as I recall similar problems with an Installshield cleanup custom action in an MSI, which only affected group policy installs, but the problem was solved by removing the custom action.

Regarding looking in the Event Viewer:

One thing of interest that I see is:

Event Type: Warning
Event Source: MsiInstaller
Event Category: None
Event ID: 1004
Date: 7/6/2009
Time: 1:31:17 PM
User: NT AUTHORITY\SYSTEM
Computer: CARLAILIENWARE
Description:
Detection of product '{69D89A9A-4436-4256-8D0A-5C8848B08844}', feature 'Complete', component '{F4436FE6-44FB-4761-A498-55655BE8A996}' failed. The resource 'C:\DOCUME~1\CARLOL~1\LOCALS~1\Temp\OMAX_Setup\Reports\OMAX_Static_Media\OMAX_Image_Logo.jpg' does not exist.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

This file is in no way critical. I can't find either of the GUID's anywhere in my install, and I thought for a while that the errors were maybe part of someone else's installer since the GUID's don't match my GUID's. However, the path and file that it reports as missing I do recognise as my own.

I also get this a moment later (next item in event viewer):
 

Event Type: Warning
Event Source: MsiInstaller
Event Category: None
Event ID: 1001
Date: 7/6/2009
Time: 1:31:17 PM
User: NT AUTHORITY\SYSTEM
Computer: CARLAILIENWARE
Description:
Detection of product '{69D89A9A-4436-4256-8D0A-5C8848B08844}', feature 'Complete' failed during request for component '{E7F8025F-5C83-4950-BCE9-69BBB1EFFAE5}'

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Regarding late running custom actions:

I have two custom actions that I run at the very end of the install.  Both of them are "synchronous".

Also, in case I have not noted it before, the 2 copies of msiexec.exe run even after rebooting.  If I kill them from the task manager, they disappear for a while, then come back.

...and the MSI is of my own making using Wise version 7

Just for the heck of it, I decided to browse to the temporary folder where the .jpg file mentioned in one of the event logs in the previous message resided, and I discovered something.

My installer includes a bunch of sample files.  Nothing important here, just some 1000 or so images and CAD drawings and such that new users can refer to as samples of what they can do in the software, or use as clip-art, etc.

These sample files originally were installed into a sub folder of my main application ("C:\Program Files\MyApp\Samples\"), but when Windows Vista came out, I had to move them to another folder that is visible to all users (The "Public" folder).   In order to keep it so the same installer would work for both Vista and XP, I changed the installer to install all the sample files into the Windows Temp folder, and then created a custom extension would run at the end of the install to either copy the files to the old location (if XP) or copy the files to the new public folder if Vista.   Then, in order to conserve the users disk space, I delete the files from the temporary folder.

Now what seems to be happening is that when the comptuer is rebooted, or possibly at other times, the Windows Installer goes "Oh my gosh!  The temporary folder is missing important files that I put there!  I need to put them back!!!".  So, it launches multiple copies of msiexec.exe, and starts repairing these folders.  (If I am quick, I can even watch the repair in progress by exploring to this foloder location and watching the files and folders magically pop back into existance - the whole process seems to take a few minutes).

So, it seems that I have a few possible solutions, and some new questions:

Possible solutions

1. Don't delete the temporary files, and simply hog this disk space of the users.  (Easy test, I will try this shortly.)
2. Find some way in Wise to flag the temp folder as "do not repair" (I have no idea how to do this.  I have done some searching with no luck.)
3. Find some way in Wise to say, "If XP or older, then install sample folders to Program Files\MyApp\MySamples\, if Vista or newer then install samples to the Users\Public\MySamples\ folder"  (I have no idea how to do this.)
4. Find some way to globally say, "Do not ever auto repair for this MSI".  (Again, no idea how to do this, but this would be ideal.)

Questions:

• Why would this suddently start occuring?  Previous installers running the same code and doing the same temp folder stuff worked fine.
• Why would the auto-repair only kick in on Windows XP, and not Vista?

Any thoughts or pointers?

Thanks,

Carl

Windows XP runs windows installer 3.x and Vista runs windows installer 4.x unless you have specifically updated either platform to a later release. So this may be one area responsible for different behaviour.

You are also making this unnecessarily complex. Start with a default install location for these image files, based on whichever operating system you perceive as being the "default".
Identify the directory table entry which points to this location - I'm assuming it won't be INSTALLDIR, but a separate folder.

Now add a Set Directory custom action in your project, which will point your directory table entry to a new location - the required location on the alternative operating system. Set a condition on this custom action using the VersionNT and/or VersionNT64 property values, depending on whether you want to include 64 bit operating system variants.

So assuming your default operating system is XP, you would use the Set Directory custom action to redefine the destination of these files for Vista, and your condition for the Set directory custom action would be VersionNT = 6.

By installing the files into the correct destination folder, and avoiding any installs into the temp folder, you will solve your repair problem and maybe other issues that are consequent on this problem.

EdT,

Excellent, excellent information in the above! - This has the potential of making my installer much cleaner.

I have a test of what you describe working now (I just made a simple installer that installs only a few small files).  Below is the script that I stuck in the middle of my "Execute Immediate".  I'm not sure if this is 100% correct, or stuck in the right spot in Wise, but it appears to work in my initial sanity checks:

(So what I am trying to accomplish with the above is that if we are running XP, then we install in a sub-folder of "Program files", and if we are installing on Vista or newer, then we install in a sub folder of "Users\Public\")

Important Question: What is to prevent this from being auto-healed, in the event a user changes a file?  For example, say the user deletes or edits one of the sample files?  Auto-healing would not be very friendly for them.

Thanks!

Carl

Yea, I noticed the overkill after I posted the message.  At any rate, it is now working fine as far as I can tell

Thank you VERY MUCH for all your help!

Carl.