11 replies to this topic

[codec]

Anyone know what some of the log codes mean when you turn on MSI logging?

I think these are
MSI © - running the client code
MSI (s) - running the service code

but
MSI © (80:EC)
What does the 80:EC refer to? And sometimes it logs with a : separator, and occasionally with a ! separator, as in
MSI (s) (3C!2C) [15:27:21:328]: PROPERTY CHANGE: ...

[Stefan Krueger]

I think this is a process ID/handle. Not really helpful in most cases I think.

[akerl]

© indicates the client and (s) the server process. The first hex value indicates the threadid and the last hex value the processíd, because only the last two values of the id are written to the log.

[codec]

Thanks - that helps.
Any idea on the ! v. : separator?

[mandy]

Interesting.

On a slightly different, but equally "interesting" subject... Has anyone ever noticed that the ":" character after the drive letter in file keypaths stored in the registry is replaced by a "?" character when "msidbComponentAttributesSharedDllRefCount" component attribute is set?

What I'd like to understand is "why"... since this information is available in the cached MSI that will be used during the uninstall?

Any ideas?

[Glytzhkof]

The msidbComponentAttributeShareDllRefCount is essentially a compatibility feature with older installation technology. Components are reference counted by their own guid, whereas incrementing the dllshared count will communicate between older setups and MSI that a file might still be needed.

[mandy]

Thank for reminding us all what the "msidbComponentAttributeShareDllRefCount" is for Glytzhkof.

Unfortunately, that wasn't the question. If anyone can think of a reason why this information might be stored in the registry (as well as in the MSI), I'd love to hear about it.

[Zweitze]

Interesting.
I can only assume that this character is interpreted during component removal; when a ? is found the corresponding SharedDlls key must be checked before deciding to remove the file.

Regarding the MSI (*) notation I have an addition:
MSI (N) - Nested installation (CA 23)

[mandy]

[Zweitze]

I can imagine (no: I hope) that MSIZAP uses this kind of information, in case the original MSI is damaged or lost.

2nd explanation: when the component is used in multiple setups, with different settings for SharedDlls. (This could happen with Merge Modules that were updated in a later stage. Obviously this would be a bug of the setup author, but the MSI engine must deal with this situation anyway.)

[mandy]

I may be mistaken, but I don't believe that MSIZAP actually uninstalls the application. I think it just removes all traces of the install from an Installer point of view?

Once a merge module has been merged into an MSI, it's components are written into the component table of that MSI (including the Attributes column). When that MSI is removed, the attributes column of the component table of the MSI used for the uninstall would reveal which components were "Shared".

[Zweitze]

About MSIZAP: Indeed, it only removes the installation information, without requiring the original MSI or a cached version.
I think that MSIZAP interpretes the character, when it is a ? the SharedDlls reference is lowered, when it is a : it is not lowered. This is hypothetical, I haven't tested this.

On the merge modules issue, I'm thinking on merge modules merged in multiple installations, which in turn are installed on the same computer. This shouldn't be a problem, unless multiple versions of this MSM exist, with conflicting Shared information.