...but does it exist in its entirety? There can be all sorts of junk beneath the key.

Match what you have against what the package is supposed to write. I imagine that the repair is failing because the key is permissioned and the account you're logged in with has insufficient rights to write the data. Hence the repair will be attempted again and again. ProcMon will show you exactly what's happening as it happens.

Remember that HKCR is an amalgam of HKLM\Software\Classes and HKCU\Software\Classes.

Was your MSI installed per-machine (ALLUSERS set to 1) or per-user (ALLUSERS not set or set to 0) ?

HKCR is a merge of HKLM/Software/Classes and HKCU/Software/Classes, with the HKCU branch given priority where there is a conflict.  Thus if you happen to have installed "Per user", the key may be present in the HKCU branch of the user account that was used for installation, but be missing in the HKCU branch of the account you are using for testing. So the first step is to check whether the registry key CLSID\{GUID} is present in the HKLM or HKCU branch of the registry.

If you are getting this error in the event log every time the app is started, and the key is present in the HKLM branch, then I suspect you may have a permissions problem in this part of the registry. Bear in mind that HKLM is read only for non admin users so if the actual key being search for is not present, a standard user will not be able to repair this.

If removing this key path generates an error on another component, which was not previously reported, then there may be something more serious amiss with your package or your test machine. You MUST test on a clean build each time, so use a VM that you can revert back to a clean snapshot after every test install, or rebuild the test machine after each test install. That is the only way to ensure that a corruption of your test build is not to blame for the errors you are seeing.

Hi,

I have the last issue you describe Edt. Removing this key triggers a repair on another key that is not in the eventviewer before.

Installation is done per-user

I have a clean build, test it on more than one pc and vm's all the same problem.

Detection of product '{8C063E86-146E-46EC-9381-A060326DD1C8}', feature 'Complete', component '{1D8981D5-8CAB-4182-8B9B-B1AAB7A82B73}' failed.  The resource 'HKEY_CLASSES_ROOT\CLSID\{09F312C6-9B0F-457E-B523-C39B81B3C36D}\' does not exist.

Just as a test, try setting ALLUSERS to 1 at install time and see if this fixes the problem.

If not, then tell us more about your package - is it a vendor MSI, or a capture, or a manually created install?

Also, have you checked registry key permissions on the affected key(s)?

Finally, are there any group policies being applied when you log on?

Ok here is what i have tested.

When i run from the commandline with a ALLUSERS=1 or ALLUSERS=2 property the eventvwiere repair problem is gone.

When i just click te MSI the problem exist?!?

Is there a specific reason you wish to deploy "Per User" ?    I cannot think of any corporate clients I have worked for that deploy "per user" - all of them have used the "per machine" setting by adding the ALLUSERS property to the property table and setting it to 1.

As you have not responded to my question about how the package was created or whether it is a vendor MSI. all I can add at this point is that I believe the issue is caused by the way that your DLL registration is (not) taking place at the time of installation.

Hi Edt,

Thanks for you response.

Yes there is a reason, the corporate where the package is for, deploys them with SMS on a per-user basis.

The package by the way, is a recapture of a setup.

Aplogize for my late respond, didn't have the time last week to look as this problem.

I know the benefits of installing per-machine, but this is the policy of the company i can't change that.

I have tried distirbuting the package trough SMS on a per-machine and per-user based installation, both gave the problem as i described in my first post.

Installing it from the commandline per-machine based doesn't show the repair in the event viewer.

...that HKCR is an amalgam of HKEY_CURRENT_USER\Software\Classes and HKEY_LOCAL_MACHINE\Software\Classes, have you checked which the package is actually trying to write? My guess is that it's HKLM (poor COM registration handling during the MSI creation pahse?) and, as stated previously, vanilla users will probably have insufficient rights to write to this area.