Understanding cryptic LocalServer32 registry entries created by MSI

0
votes

I notice when I use the Class MSI table and other related tables to register COM classes during an MSI install, the LocalServer32 values don't have paths, but rather have some cryptic value. I see limited information on the web, suggesting this may be some sort of hash of the MSI ProductCode and Component GUID, but I can't find detailed information on how this works.

I'm wondering specifically if one of the features of this sort of registration is to ensure, in a multi-instance installation, that the instance of the component returned is from the same installation as the client, where possible. I kind of doubt it, but I want to understand everything this scheme accomplishes, and don't know where to find the information.

Here's a sample of such a registry entry:

Darwin Descriptor

1
comwindows-installerbasic-msi
Hard to see why we have to guess at the content of those keys, obviously that detail is very relevant. You are probably seeing MSI's self repair feature at work. blogs.flexerasoftware.com/installtalk/2011/02/… – Hans Passant
The answer to your "hard to guess" reason is that I'm on the bus without access to my computer as I write this question. Otherwise I would have included that detail. I figured since it looks like nonsense, anyone who knows the answer would know what I was talking about anyway. – BlueMonkMN

1 Answers

1
votes

It's called a "Darwin Descriptor". It exists to support self-repair on COM activation. That was an interesting idea with horrible execution (endless repair loops with source prompts and ugly basic UI), WiX defaults to writing the raw COM registry keys to avoid it.