Weird MSI behaviour and 1605 return code (Installer corruption?)
Dennis Bareis
We have just updated a product in about 900 sites, in 23 of these it
failed.
To work around the problem the previous version of the product had to
be manually removed first.
The new product uses upgrade codes to uninstall any previous versions
(all our products do this and have done so for a long time) and I have
a verbose log (below) which shows what happens.
The log shows very little so the only reason I think the upgrade bit
might be involved is that the uninstall "fixed it" (mind you maybe any
uninstall of any product may have done the same for all I know -
corrupt registry?.
The log does not show the "FindRelatedProducts" action being used. BUT
it does appear to be looking for itself in the registry TWICE (another
1605 bug on another product shows this being done ONCE). Then it fails
when it can't find itself, why would it expect to, it is being
installed....
Anyway the complete log follows:
=== Verbose logging started: 11/02/2003 14:01:20 Build type: SHIP
UNICODE 1.11.2405.00 Calling process: C:\WINNT\System32\msiexec.exe
===
MSI (c) (10:28): Resetting cached policy values
MSI (c) (10:28): ******* RunEngine:
******* Product: {C6AEF16D-6898-4FB5-9723-2FA3AE0A5DAA}
******* Action:
******* CommandLine: REINSTALL=ALL REINSTALLMODE=dmus
MSI (c) (10:28): Client-side and UI is none or basic: Running entire
install on the server.
MSI (c) (10:28): Grabbed execution mutex.
MSI (c) (10:28): Cloaking enabled.
MSI (s) (54:C8): Resetting cached policy values
MSI (s) (54:C8): ******* RunEngine:
******* Product: {C6AEF16D-6898-4FB5-9723-2FA3AE0A5DAA}
******* Action:
******* CommandLine: REINSTALL=ALL REINSTALLMODE=dmus
CURRENTDIRECTORY="C:\Program Files\netDeploy\Launcher\C
ache\Common\GlobalFSServicePack 01" CLIENTUILEVEL=3
CLIENTPROCESSID=6160 %HOMEPATH="" %HOMEDRIVE=""
MSI (s) (54:C8): Searching for item
Products\D61FEA6C89865BF47932F23AEAA0D5AA in per-user managed key
MSI (s) (54:C8): Searching for item
Products\D61FEA6C89865BF47932F23AEAA0D5AA in per-user non-managed key
MSI (s) (54:C8): Searching for item
Products\D61FEA6C89865BF47932F23AEAA0D5AA in per-machine key
MSI (s) (54:C8): Did not find item
Products\D61FEA6C89865BF47932F23AEAA0D5AA
MSI (s) (54:C8): Searching for item
Products\D61FEA6C89865BF47932F23AEAA0D5AA in per-user managed key
MSI (s) (54:C8): Searching for item
Products\D61FEA6C89865BF47932F23AEAA0D5AA in per-user non-managed key
MSI (s) (54:C8): Searching for item
Products\D61FEA6C89865BF47932F23AEAA0D5AA in per-machine key
MSI (s) (54:C8): Did not find item
Products\D61FEA6C89865BF47932F23AEAA0D5AA
MSI (s) (54:C8): MainEngineThread is returning 1605
MSI (c) (10:28): MainEngineThread is returning 1605
=== Verbose logging stopped: 11/02/2003 14:01:20 ===
Any ideas?
Thanks,
Dennis
Phil Wilson
If it's a major upgrade, running msiexec with REINSTALL=ALL REINSTALLMODE=dmus isn't really
necessary. You just run the MSI and the incoming install removes the old version if it's there(the
details depend on where you've sequenced RemoveExistingProducts), and you would have the changed the
product code guid. Applying a small update by reinstalling the product would use a command line with
REINSTALL=ALL etc, and that would look for the existing product to update it in-place, and you would
not have the changed the product code guid. I'm also wondering if those 23 had Windows Installer
1.0 (1.1 supports upgrades that change product code, 1.0 didn't).
"Dennis Bareis" <dba...@labyrinth.net.au> wrote in message
news:266bedb4.03021...@posting.google.com...
Dennis Bareis
> How did the users install the new MSI? And did you change the product code guid?
Each release of the MSI is built from scratch using an automated tool,
the product/package codes are unique for each build. The MSI old/new
installed via a tool called NetDeploy under the system account (and
per-machine install).
> If it's a major upgrade, running msiexec with REINSTALL=ALL REINSTALLMODE=dmus isn't really
> necessary.
NetDeploy added these...
You just run the MSI and the incoming install removes the old version
if it's there(the
> details depend on where you've sequenced RemoveExistingProducts),
From the doco :
Between the InstallValidate action the InstallInitialize action. In
this case, the installer removes the old applications entirely before
installing the new applications. This is an inefficient placement for
the action because all reused files have to be recopied.
>and you would have the changed the
> product code guid. Applying a small update by reinstalling the product would use a command line with
> REINSTALL=ALL etc, and that would look for the existing product to update it in-place, and you would
> not have the changed the product code guid. I'm also wondering if those 23 had Windows Installer
> 1.0 (1.1 supports upgrades that change product code, 1.0 didn't).
OK, I'll check that thanks. Mind you there were other products that
should have failed if that was the case, but I'll check it for sure.
Note also that if it really was to do with RemoveExistingProducts etc
I'd have expected a lot more in the verbose log (and specifically see
these actions mentioned), it says its a verbose log unless the flags
mean different things when used from the command line versus via
policy (doco says not)...
Bye
Dennis
Phil Wilson
"Dennis Bareis" <dba...@labyrinth.net.au> wrote in message
news:266bedb4.0302...@posting.google.com...
> "Phil Wilson" <phil....@unisys.spamcom> wrote in message
news:<OjLwSDi0CHA.1296@TK2MSFTNGP11>...
> > How did the users install the new MSI? And did you change the product code guid?
>
> Each release of the MSI is built from scratch using an automated tool,
> the product/package codes are unique for each build. The MSI old/new
> installed via a tool called NetDeploy under the system account (and
> per-machine install).
>
> > If it's a major upgrade, running msiexec with REINSTALL=ALL REINSTALLMODE=dmus isn't really
> > necessary.
>
> NetDeploy added these...
ok, but does that mean the new product was installed with msiexec /i <path to msi> REINSTALLMODE=ALL
etc or not ? There's a certain incompatibility between using that command line to do a minor
update and doing the major upgrade that you think you're doing and which doesn't need that command
line and will usually just install the new version when there is no prior version.
>
> You just run the MSI and the incoming install removes the old version
> if it's there(the
> > details depend on where you've sequenced RemoveExistingProducts),
>
> From the doco :
> Between the InstallValidate action the InstallInitialize action. In
> this case, the installer removes the old applications entirely before
> installing the new applications. This is an inefficient placement for
> the action because all reused files have to be recopied.
I know what the docs say, the issue is whether you are really doing a major upgrade or not.
> >and you would have the changed the
> > product code guid. Applying a small update by reinstalling the product would use a command line
with
> > REINSTALL=ALL etc, and that would look for the existing product to update it in-place, and you
would
> > not have the changed the product code guid. I'm also wondering if those 23 had Windows
Installer
> > 1.0 (1.1 supports upgrades that change product code, 1.0 didn't).
>
>
> OK, I'll check that thanks. Mind you there were other products that
> should have failed if that was the case, but I'll check it for sure.
>
> Note also that if it really was to do with RemoveExistingProducts etc
> I'd have expected a lot more in the verbose log (and specifically see
> these actions mentioned), it says its a verbose log unless the flags
> mean different things when used from the command line versus via
> policy (doco says not).
Well that's why I asked if you're really really doing a major upgrade or not - it looks as if you're
not sure. The point here is that you can have a minor update or a major upgrade. You think you're
doing a major upgrade but that command line implies you're doing a minor update. A minor update with
your new product code won't produce much of a log (especially when there's no client-side UI)
because it will search for its product code on the system, not find it and go away. In other words
there is command line evidence that you're doing a minor update by reinstalling the product which
fails because you've changed the product code.
> Bye
> Dennis