/build/static/layout/Breadcrumb_cap_w.png

Service Starts - Causes MSI to Self Repair (HKEY-Current-USER Setting missing)

Guys,

I have a snapshotted MSI that installs a service. I did the snapshot in InstallShield 2008

This service runs in System context.

Every time this service starts the MSI self heals, a component with a key path in the HKEY_Current_User REg hive is the culprit.

I can only assume that the service in system context is raising the self repair in the same context and "System" doesn't have a HKEY_Current_USER Hive...

I have never seen this before....so I am wondering if anybody else has?


To try to resolve it I have tried to isolate the service elemtns in a seperate feature that is a child of a parent feature that has all the current user setting in...

Any help much appreciated.

Thanks.

0 Comments   [ + ] Show comments

Answers (6)

Posted by: anonymous_9363 13 years ago
Red Belt
0
What kind of service puts stuff in the user profile?!? Have you asked the vendor? Are you sure you haven't captured something unrelated to the service? Have you tried moving the entry to HKLM?
Posted by: wynnem 13 years ago
Orange Belt
0
It's not the Service writing to CurrentUser..

The service calls a number of Dll that have COM info (advertising) and these are the entry point into the package's self healing.

I am working on getting around it be re-organising my features...moving the service related components into an isolated feature on the same level as the feature that contains the current user details...

Will post how I get on.
Posted by: anonymous_9363 13 years ago
Red Belt
0
So you're installing a service, per-user? That's the principal reason that the healing would attempt to put stuff into HKCU. Either that, or the relevant Registry.Root cells in the package is set to 1...
Posted by: Yaduveer 13 years ago
Orange Senior Belt
0
I am not aware how you have captured the service, but if I just think to resolve this issue only, then I will suggest you to use Activesetup in your package.
Posted by: pjgeutjens 13 years ago
Red Belt
0
What probably happens is the service uses one of the advertised DLLs in your package, this triggers the repair and indeed, since the service runs in SYSTEM something goes wrong finding the correct CU hive. The event log should have data on exactly what component is missing what data.

Like Yadu said, you can always remove the offending component and replace it with Active Setup

PJ
Posted by: wynnem 13 years ago
Orange Belt
0
I resolved the issue by adding the offending components into an isolated feature...
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ