Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

MsiExec never terminates

387 views
Skip to first unread message

JahMic

unread,
Feb 19, 2008, 12:28:32 AM2/19/08
to
One of my customers experiences a problem when he installs my VS based
installer program. 2-3 separate msiexec processes are created and one
of them never stops, even though the installer finishes without
reporting any errors. However, it seems that at least of the DLLs is
never installed. I checked the installer log, but nothing seemed to
jump out at me, (a lot of info is put into there).

If he manually kills the last msiexec process everything seems to be
installed fine. Upon uninstall, there seems to be no lingering
components, reg keys, etc.

Any thoughts on I can diagnose or resolve this issue?

Thanks in advance,

J

Bruno

unread,
Feb 19, 2008, 3:53:02 AM2/19/08
to
Hi
I could be wrong here, but as long as i know, two processes are launched
when you install an msi, and one keeps running for a couple of minutes
(that's part of the installer service that stops after that).
Please check if the behaviour you see is the same with a different msi, as
this could very well be completely normal.

hope it helps

bruno

doc

unread,
Feb 19, 2008, 8:51:36 AM2/19/08
to
A number of MSIExec processes can be running during an installation.
The reason for this is that Windows Installer uses a client-server
model for performing installations. Additionally for security reasons,
Windows Installer hosts DLL and script custom actions in a "sandbox"
process.

Depending on how the install was initiated, one of the MSIExec
processes can be the client process. Another MSIExec process is
Windows Installer service.

I believe the "server" process runs as System in the Task Manager. The
"client" process runs as the instantiating user.

JahMic

unread,
Feb 20, 2008, 4:36:51 AM2/20/08
to
Hi All,

Thanks for the replies.

A few clarifications:
I'm aware that it is normal for x amount of msiexec processes to start
up during an install. No problem with that. As far as not
terminating, I guess, that is also not such a big deal, as I
frequently find on my systems, a msiexec process going about it's
business without, seemingly, any problems.

The key point here, is that, if he doesn't kill the last msiexec
process, the install never completely installs the files. So
something isn't going right. I'm not keen on manually killing a
msiexec process, so I would to figure out what's going on and then
have a more elegant solution. I haven't seen this happen on other
machines, and he says it doesn't happen with other msi based
installers.

If somebody has advise on where or what to look for or try, I would
really appreciate it.

Regards, J

Adrian Accinelli

unread,
Feb 25, 2008, 7:38:46 PM2/25/08
to

"JahMic" <jah...@gmail.com> wrote in message
news:db8b0a52-b8cb-4d86...@i7g2000prf.googlegroups.com...

>Hi All,
>
>Thanks for the replies.
>
>A few clarifications:
>I'm aware that it is normal for x amount of msiexec processes to start
>up during an install. No problem with that. As far as not
>terminating, I guess, that is also not such a big deal, as I
>frequently find on my systems, a msiexec process going about it's
>business without, seemingly, any problems.
>
>The key point here, is that, if he doesn't kill the last msiexec
>process, the install never completely installs the files. So
>something isn't going right. I'm not keen on manually killing a
>msiexec process, so I would to figure out what's going on and then
>have a more elegant solution. I haven't seen this happen on other
>machines, and he says it doesn't happen with other msi based
>installers.
>
>If somebody has advise on where or what to look for or try, I would
>really appreciate it.
>
>Regards, J

If the installer "never completely installs the files" then you have a
custom action that either is deadlocked or waiting for an event that has not
occurred yet. A verbose log in this case should indicate what the last
action is and that's pretty much your culprit.

You can easily deadlock the installer.

One way:
http://blogs.msdn.com/astebner/archive/2007/04/07/ngen-service-can-cause-deadlocks-during-product-installation-in-some-scenarios.aspx

Another:
The custom action that calls CoCreateInstance on an advertised but not fully
installed COM component. This causes a self-repair which blocks because
installation is already in progress and the CoCreateInstance never returns
thus deadlocking the install.

Sincerely,
Adrian Accinelli


0 new messages