MSI self healing is only hurting :-)
This is an excellent forum and I'd like to thank everyone for helping me sleuth the problems which were tripping up my installations. Still, the MSI self healing facility is beating me up and I would be very appreciative if I could get some advice on resolving the problem.
Everytime I start JobTabs 2005, the MSI program starts to install a program it believes needs to be healed. Through the insightful posts found in this thread, I've been able to duplicate the problem by reading the Application log. What I fail to understand is how my program could possibly be initiating the reinstall. For example, I have an application called Help Studio that was installed with MSI. I moved the application from Start -> Programs to Start -> Programs -> MS Visual Studio because I had too many applications on the start menu and wanted to categorize them more efficiently. Upon executing JobTabs 2005, all of a sudden Help Studio starts reinstalling itself! The application log states,
++++++++++++++++++++++++++++++++++++++++++++
Event Type: Warning
Event Source: MsiInstaller
Event Category: None
Event ID: 1004
Date: 4/20/2005
Time: 9:34:03 PM
User: TOSHJPC\JPC
Computer: TOSHJPC
Description:
Detection of product '{88C21977-8B69-4C53-8627-A73AAFD031A4}', feature 'Complete', component '{0CE06C66-17C1-4267-9369-447F0CC5FA57}' failed. The resource 'C:\Documents and Settings\All Users\Start Menu\Programs\Innovasys HelpStudio 2\' does not exist.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
++++++++++++++++++++++++++++++++++++++++++++
Upon replacing the shortcut to Start -> Programs the problem is solved. (Thanks guys!) The perplexing part is how on earth could starting JobTabs 2005 (which was not even installed using MSI) possibly have triggered Help Studio to take inventory of its installation? The sleuthing I've done on the internet, suggests that mscomctl.ocx or some common control shared by almost every application could be what is triggering the problem but I haven't found anything definitive. Any ideas?
Sincerely,
John Coffey
Everytime I start JobTabs 2005, the MSI program starts to install a program it believes needs to be healed. Through the insightful posts found in this thread, I've been able to duplicate the problem by reading the Application log. What I fail to understand is how my program could possibly be initiating the reinstall. For example, I have an application called Help Studio that was installed with MSI. I moved the application from Start -> Programs to Start -> Programs -> MS Visual Studio because I had too many applications on the start menu and wanted to categorize them more efficiently. Upon executing JobTabs 2005, all of a sudden Help Studio starts reinstalling itself! The application log states,
++++++++++++++++++++++++++++++++++++++++++++
Event Type: Warning
Event Source: MsiInstaller
Event Category: None
Event ID: 1004
Date: 4/20/2005
Time: 9:34:03 PM
User: TOSHJPC\JPC
Computer: TOSHJPC
Description:
Detection of product '{88C21977-8B69-4C53-8627-A73AAFD031A4}', feature 'Complete', component '{0CE06C66-17C1-4267-9369-447F0CC5FA57}' failed. The resource 'C:\Documents and Settings\All Users\Start Menu\Programs\Innovasys HelpStudio 2\' does not exist.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
++++++++++++++++++++++++++++++++++++++++++++
Upon replacing the shortcut to Start -> Programs the problem is solved. (Thanks guys!) The perplexing part is how on earth could starting JobTabs 2005 (which was not even installed using MSI) possibly have triggered Help Studio to take inventory of its installation? The sleuthing I've done on the internet, suggests that mscomctl.ocx or some common control shared by almost every application could be what is triggering the problem but I haven't found anything definitive. Any ideas?
Sincerely,
John Coffey
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
craig16229
18 years ago
John,
If I am following you, it sounds like you have repackaged and app named HelpStudio 2 into .msi format. If that is true, is the file mscomctl.ocx installed as part of your package? If it is, then it should be (in most cases) removed from your package, and the merge module mscomctl.msm (a.k.a. "redistributable") should be added instead.
Are you familiar with merge modules?
Craig --<>.
If I am following you, it sounds like you have repackaged and app named HelpStudio 2 into .msi format. If that is true, is the file mscomctl.ocx installed as part of your package? If it is, then it should be (in most cases) removed from your package, and the merge module mscomctl.msm (a.k.a. "redistributable") should be added instead.
Are you familiar with merge modules?
Craig --<>.
Posted by:
jpcoffey
18 years ago
Craig, thank you for responding to my question. I am considering altering the terms under which I install mscomctl.ocx. The details are below.
The crux of my problem is that MSI is interfering with the normal functioning of my application. Often when my users start my application, they will report that another application is trying to install itself. I have done some research on the internet and through the discussions on this board, I've been able to conclude that the culprit is the Windows Installer. I successfully duplicated the error by altering slightly a program on my computer that was installed using Windows Installer and lo and behold the application, in this case Innovasys Help Studio, started to install itself. The alteration I made? I simply moved a shortcut on the Start -> Programs - Help Studio to another location. Why any MSI packager would classify this as a problem is beyond me, but it is something I have to reckon with all the same.
My consternation is I can't figure out what my application is doing that would cause the Windows Installer to begin making changes to programs that were installed with the Windows Installer. I didn't even use Windows Installer to install my application, JobTabs 2005, and yet Windows Installer is auditing the system when JobTabs starts. Every time my application starts on a system with an altered configuration - no matter how small - applications installed with the Windows Installer start to self-heal themselves. I have gone to great lengths trying to fix the problem. I have downloaded RegMon and FileMon yet haven't been able to identify the specific instruction that is causing the Windows Installer to begin auditing itself.
What I have succeeded in doing, is narrowing down the specific line of code in my application which causes the Windows Installer to run. That statement is simply "Load frmMain' in VB6. Now, there are 3rd party controls which are on my form that were installed on my development system with Windows Installer, but how could this possibly be relayed to my users? Again, I am not using Windows Installer to install my application.
At this juncture, I can only conclude that there are a lot of poor installations of MSI floating around. Maybe the culprit is the mscomctl.ocx. If so, I need to determine what is the minimum version mscomctl.ocx my application can work safely with and simply not install the mscomctl.ocx if a decent copy is already on my client's machine. This I am working on, but it is a work around and not a solution. What if some other completely unrelated application installs a newer version of mscomctl.ocx? Will starting my application initiate a reinstall of some MSI application that is trying to "heal" itself?
If you, or anyone who has read this far, can let me know that I should proceed with the mscomctl.ocx work around then I will. I guess I just need the input of battle hardened, experienced professionals to move forward with a clear conscience that I have done all I can do. In any case, thank you for sharing your insight on mscomctl.ocx.
Sincerely,
John Coffey
The crux of my problem is that MSI is interfering with the normal functioning of my application. Often when my users start my application, they will report that another application is trying to install itself. I have done some research on the internet and through the discussions on this board, I've been able to conclude that the culprit is the Windows Installer. I successfully duplicated the error by altering slightly a program on my computer that was installed using Windows Installer and lo and behold the application, in this case Innovasys Help Studio, started to install itself. The alteration I made? I simply moved a shortcut on the Start -> Programs - Help Studio to another location. Why any MSI packager would classify this as a problem is beyond me, but it is something I have to reckon with all the same.
My consternation is I can't figure out what my application is doing that would cause the Windows Installer to begin making changes to programs that were installed with the Windows Installer. I didn't even use Windows Installer to install my application, JobTabs 2005, and yet Windows Installer is auditing the system when JobTabs starts. Every time my application starts on a system with an altered configuration - no matter how small - applications installed with the Windows Installer start to self-heal themselves. I have gone to great lengths trying to fix the problem. I have downloaded RegMon and FileMon yet haven't been able to identify the specific instruction that is causing the Windows Installer to begin auditing itself.
What I have succeeded in doing, is narrowing down the specific line of code in my application which causes the Windows Installer to run. That statement is simply "Load frmMain' in VB6. Now, there are 3rd party controls which are on my form that were installed on my development system with Windows Installer, but how could this possibly be relayed to my users? Again, I am not using Windows Installer to install my application.
At this juncture, I can only conclude that there are a lot of poor installations of MSI floating around. Maybe the culprit is the mscomctl.ocx. If so, I need to determine what is the minimum version mscomctl.ocx my application can work safely with and simply not install the mscomctl.ocx if a decent copy is already on my client's machine. This I am working on, but it is a work around and not a solution. What if some other completely unrelated application installs a newer version of mscomctl.ocx? Will starting my application initiate a reinstall of some MSI application that is trying to "heal" itself?
If you, or anyone who has read this far, can let me know that I should proceed with the mscomctl.ocx work around then I will. I guess I just need the input of battle hardened, experienced professionals to move forward with a clear conscience that I have done all I can do. In any case, thank you for sharing your insight on mscomctl.ocx.
Sincerely,
John Coffey
Posted by:
John_RM
18 years ago
John
I don’t know weather you problem with regards to self healing has been solved or not.
If mscomctl.ocx is included in any applications that your users have had installed via MSI, then the entry’s in the registry for the ProgID’s exposed by mscomctl.ocx, will point to Classes that have an InprocServer32 entry that is a (Darwin Descriptor), this is advertising information and as such is a pointer to a specific Component not a hard coded path to the OCX.
If your application programmatically calls one of the ProgID’s associated with mscomctl.ocx then this initiates a check of the MSI that installed it. If this MSI has any problems such as a missing or corrupted Keypath e.g. a shortcut or Current user information, then that MSI will initiate a self repair.
I don’t know weather you problem with regards to self healing has been solved or not.
If mscomctl.ocx is included in any applications that your users have had installed via MSI, then the entry’s in the registry for the ProgID’s exposed by mscomctl.ocx, will point to Classes that have an InprocServer32 entry that is a (Darwin Descriptor), this is advertising information and as such is a pointer to a specific Component not a hard coded path to the OCX.
If your application programmatically calls one of the ProgID’s associated with mscomctl.ocx then this initiates a check of the MSI that installed it. If this MSI has any problems such as a missing or corrupted Keypath e.g. a shortcut or Current user information, then that MSI will initiate a self repair.
Posted by:
jpcoffey
18 years ago
Guys, thanks for your excellent feedback. Craig, you were dead-on with the mscomctl.ocx. I now only install the control if it doesn't exist on the user's computer; otherwise I don't install it at all. (Its a new control with very few changes between builds.) John, I really wanted to know the details of this perplexing problem and your feedback cleared the air. Thanks.
As a measure of my appreciation I am providing you guys with a free copy of JobTabs 2005. It can be downloaded via the JobTabs website at jobtabs.com. Please look for your free registration codes in your email. Thanks again.
Sincerely,
John Coffey
As a measure of my appreciation I am providing you guys with a free copy of JobTabs 2005. It can be downloaded via the JobTabs website at jobtabs.com. Please look for your free registration codes in your email. Thanks again.
Sincerely,
John Coffey
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.