a VB6 service that triggers another MSI healing
Hi all,
I am experiencing a strange behavior. Some time ago, we created a service in VB6 and the service has always worked well until now. Lately, a workmate created a repackage of a huge home VB6 application which is now in production.
Now the VB6 service does not start automatically anymore and is still set to automatic. If I start it manually via computer management console. It launches self healing of the repackage VB6 application the repair last for about 2 minutes. The event viewer is about some HKCU apparently missing. The service is running as system. I understand that the service is loosing track and failed after some time (if failure it is), then I can start again the service once the repair is finish and the problem is now fixed with the service.
I discovered that the repackaged application includes 12 merged modules, about VB6 ocx. I now understand that these objects can be healed ( I thought that heal could only be triggered via a shortcut, my bad... )
What can I do to try and solve this issue, on every reboot, it appears that the service is unable to start and will not until manual intervention. What was done wrong in the repackaged application with the merged modules? It appears it try to heal for system users because the service is running as system. Is all this normal behavior?
Any help will be appreciated.
Thks,
I am experiencing a strange behavior. Some time ago, we created a service in VB6 and the service has always worked well until now. Lately, a workmate created a repackage of a huge home VB6 application which is now in production.
Now the VB6 service does not start automatically anymore and is still set to automatic. If I start it manually via computer management console. It launches self healing of the repackage VB6 application the repair last for about 2 minutes. The event viewer is about some HKCU apparently missing. The service is running as system. I understand that the service is loosing track and failed after some time (if failure it is), then I can start again the service once the repair is finish and the problem is now fixed with the service.
I discovered that the repackaged application includes 12 merged modules, about VB6 ocx. I now understand that these objects can be healed ( I thought that heal could only be triggered via a shortcut, my bad... )
What can I do to try and solve this issue, on every reboot, it appears that the service is unable to start and will not until manual intervention. What was done wrong in the repackaged application with the merged modules? It appears it try to heal for system users because the service is running as system. Is all this normal behavior?
Any help will be appreciated.
Thks,
0 Comments
[ + ] Show comments
Answers (13)
Please log in to answer
Posted by:
AngelD
14 years ago
The event log will help to find the cause of the repair.
My guessing is that the service is using one or more COM-Component and COM-advertising is in place for the registration in any of the packages.
My guessing is that the service is using one or more COM-Component and COM-advertising is in place for the registration in any of the packages.
Posted by:
pjgeutjens
14 years ago
Whatever the situation, if your VB application gets a selfheal triggered, that means it was done through one of its entrypoints. It could be an advertised DLL or OCX that gets triggered during the startup of the service. Maybe they have files in common and your new package has advertised them?
It could be that some files that are linked to merge modules in one package correspond to files that SHOULD have been merge modules in the other one, but were actually just dumped in the MSI. Because the goal of using merge modules is actually to prevent these kinds of conflicts when using the same files in multiple packages.
Kinda weird that you get nothing from the eventlog, because every selfheal triggered causes an event identifying the product and component that caused it.
It could be that some files that are linked to merge modules in one package correspond to files that SHOULD have been merge modules in the other one, but were actually just dumped in the MSI. Because the goal of using merge modules is actually to prevent these kinds of conflicts when using the same files in multiple packages.
Kinda weird that you get nothing from the eventlog, because every selfheal triggered causes an event identifying the product and component that caused it.
Posted by:
pjgeutjens
14 years ago
as a little experiment, could you dump those missing ODBC keys into the .Default User's HKCU hive.
Reason why I say this is an experiment is this: besides being the HKCU hive that LocalSystem uses, this is also the template for all new users that get created so each user that logs in for the first time will get these values, so this really shouldn't be made permanent.
EDIT : this last part about new users is actually not true, dunno what I was thinking, but anyway, check if the values are in the HKU\.DEFAULT hive
Also, can you tell me what the value of the ALLUSERS property is in both your packages, and, if possible, look at the MSI for the service to verify that the service is started with LocalSystem credentials
Reason why I say this is an experiment is this: besides being the HKCU hive that LocalSystem uses, this is also the template for all new users that get created so each user that logs in for the first time will get these values, so this really shouldn't be made permanent.
EDIT : this last part about new users is actually not true, dunno what I was thinking, but anyway, check if the values are in the HKU\.DEFAULT hive
Also, can you tell me what the value of the ALLUSERS property is in both your packages, and, if possible, look at the MSI for the service to verify that the service is started with LocalSystem credentials
Posted by:
AngelD
14 years ago
You need to fix the repair.
Check the event viewer for which component that is broken, the entry point that triggered the self-healing check would also be interesting.
Check the event viewer for which component that is broken, the entry point that triggered the self-healing check would also be interesting.
Posted by:
unreal2me
14 years ago
The error in event viewer did not help me.
The triggers in my situation is a service that has nothing to do with the package that get repaired. I think the merged modules VB6 OCX are the causes of this because if I removed them all from the package, then the service starts normally withtout triggering repair of the app.
It appears that other applications can triggered healing of the app which have merged modules. Can I prevent this from happening?
Thks,
The triggers in my situation is a service that has nothing to do with the package that get repaired. I think the merged modules VB6 OCX are the causes of this because if I removed them all from the package, then the service starts normally withtout triggering repair of the app.
It appears that other applications can triggered healing of the app which have merged modules. Can I prevent this from happening?
Thks,
Posted by:
unreal2me
14 years ago
PJgeutjens, your post is very helpful, I feel this is exactly what is happening. The service triggers the self heal of the other app. What I dont understand is that the service app only has one OCX does not have either merged modules or OCX in the package itself. It assumes the shared one are on system 32 I guess.
Other thing is, if I start the application by clicking the exe alone, it doesn't trigger the heal. If I start the service, I get the heal (system user vs admin user). Can I do anything to prevent the self heal from happening for the system user?
The event viewer is about missing HKCU in the current user but they are not missing and were populated on previous launch of the application. There is some confusion between admin and system user, which keys for sure are not populated. The CU keys seems to have no relation at all with the merged modules.
I need to make an update to this service package, the one that triggers the heal of the other app. Can I do anything in that package to fix this situation or do I have to fix the orginal one that includes advertised merged modules?
Many thanks,
Other thing is, if I start the application by clicking the exe alone, it doesn't trigger the heal. If I start the service, I get the heal (system user vs admin user). Can I do anything to prevent the self heal from happening for the system user?
The event viewer is about missing HKCU in the current user but they are not missing and were populated on previous launch of the application. There is some confusion between admin and system user, which keys for sure are not populated. The CU keys seems to have no relation at all with the merged modules.
I need to make an update to this service package, the one that triggers the heal of the other app. Can I do anything in that package to fix this situation or do I have to fix the orginal one that includes advertised merged modules?
Many thanks,
Posted by:
unreal2me
14 years ago
Small update. The first event viewer message was related to HKCU ODBC keys that were missing. The second message was Failed during request of component GUID which refers to MSCOMCTLOCX. This is one of the merged component inside the first package.
This OCX is not part of the service package that triggers the heal of the app which have it in his merged components. The heal is triggered by a service because it is running as SYSTEM. If an admin is running the service EXE file manually, then the heal is not triggered.
When the service is starting (running as system), the heal is initiated and does not finish before the service timeout. I guess the service is loosing track of what is happening and simply time out. If you start the service again after, everything is fine.
Hope it helps you to point me in the right direction.
Thks
This OCX is not part of the service package that triggers the heal of the app which have it in his merged components. The heal is triggered by a service because it is running as SYSTEM. If an admin is running the service EXE file manually, then the heal is not triggered.
When the service is starting (running as system), the heal is initiated and does not finish before the service timeout. I guess the service is loosing track of what is happening and simply time out. If you start the service again after, everything is fine.
Hope it helps you to point me in the right direction.
Thks
Posted by:
unreal2me
14 years ago
ORIGINAL: pjgeutjens
as a little experiment, could you dump those missing ODBC keys into the .Default User's HKCU hive.
Reason why I say this is an experiment is this: besides being the HKCU hive that LocalSystem uses, this is also the template for all new users that get created so each user that logs in for the first time will get these values, so this really shouldn't be made permanent.
I am puzzled. It worked. Merging these keys to the default hive, now my service starts normally. I don't understand what is happening here.
Application -A- has which was built with VB6 is a service and now it triggers self healing of new Application -B- because -B- updates VB6 OCX via merged modules and these OCX are used by -A-. But -A- which runs as SYSTEM, triggers the self healing of -B- via some missing -B- KU keys missing in his current hive(SYSTEM).
I am a little confused about all this.
Posted by:
unreal2me
14 years ago
Well, I think I understand what is happening now.
The application -B- Com objects are advertised and -A- invoke self healing of -B- because of the new -B- OCX file. So -B-'s integrity is fully verified. Because -A- runs as system, the HKCU keys which dont exist as SYSTEM are found to be broken and then the whole feature is repaired, in this case, the whole package. I guess having package -B- HKCU keys in a separate feature would have prevent this from happening
It makes sense now.
Thanks for those who helped me understand this one.
The application -B- Com objects are advertised and -A- invoke self healing of -B- because of the new -B- OCX file. So -B-'s integrity is fully verified. Because -A- runs as system, the HKCU keys which dont exist as SYSTEM are found to be broken and then the whole feature is repaired, in this case, the whole package. I guess having package -B- HKCU keys in a separate feature would have prevent this from happening
It makes sense now.
Thanks for those who helped me understand this one.
Posted by:
unreal2me
14 years ago
I am wonder, what would be the best practice in my situation? Is it a good idea to isolate the COM objects in a separate feature so that the HKCU keyrs are not verified when they are accessed?
Thks
Thks
Posted by:
anonymous_9363
14 years ago
My brain hurts...
Why are you forcing registration into HKCU? Remember that HKCR is an amalgam of HKCU\Software\Classes and HKLM\Software\Classes: COM information ends up in the former if a package is installed per-user and the latter if installed per-machine. If you're forcing stuff into HKCU (which you are, in effect), that has implications for uninstalling, upgrading, etc.
In your position, I'd consider re-doing both packages, perhaps ensuring that both use the same MM for the OCX. It's simple enough to re-cache the MSI for any already-installed instances.
Why are you forcing registration into HKCU? Remember that HKCR is an amalgam of HKCU\Software\Classes and HKLM\Software\Classes: COM information ends up in the former if a package is installed per-user and the latter if installed per-machine. If you're forcing stuff into HKCU (which you are, in effect), that has implications for uninstalling, upgrading, etc.
In your position, I'd consider re-doing both packages, perhaps ensuring that both use the same MM for the OCX. It's simple enough to re-cache the MSI for any already-installed instances.
Posted by:
AngelD
14 years ago
You need to find out why the repair is failing.
Dump the user ODBC to system ODBC instead.
Dump the user ODBC to system ODBC instead.
Posted by:
unreal2me
14 years ago
The HKCU keys I am referring to are related to the application itself, not the COM objects. Seems like my whole story is not very clear.
Thanks
Thanks
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.