Why does MSI configuration starts when I open a VB 6 form with ListView (MSCOMCTL.OCX)

Question

I am facing a very strange situation. It took me almost 3 days to figure out what is causing one of our installers (MSI) to automatically run. We have a wizard application built in VB6 and one of the form contains ListView (Microsoft Windows Common Controls 6.0 (SP6) - MSCOMCTL.OCX). Everything goes fine until we click next to display this form with ListView control. As soon as I click Next, the configuration starts for one of our products (which is already installed on the system) with a message saying "Please wait while Windows configures {ProductName}". The dialog comes up again and again about 6-7 times and then finally this ListView form is displayed.

I have confirmed that the configuration dialog only comes up when the form to be displayed has ListView control. What could be the problem here? Why is this form triggering one of our MSIs?

---

Click the 'Vote as Helpful' arrow if this post was helpful.

Answer 1

Sounds like an MSI repair, in which case there should be clues in Event Viewer.

Answer 2

This would be caused something of your product changed, which make the installer think your current status is not valid, so it re-config your product to the safe and valid status.

Maybe the change is caused manually, or some other software(common or malicious) changed it.

---

Mike Zhang[MSFT]
MSDN Community Support | Feedback to us

Answer 3

There are log entries in event log:

Detection of product '{1E6FC31C-315E-4129-8140-67E7E618BF6E}', feature 'Client', component '{14680E43-B57F-4DB9-865F-680F303CF52A}' failed.  The resource 'C:\Program Files (x86)\xxx\yyy\zzz' does not exist.

Detection of product '{1E6FC31C-315E-4129-8140-67E7E618BF6E}', feature 'Client' failed during request for component '{22056900-C842-11D1-A0DD-00A0C9054277}'

{22056900-C842-11D1-A0DD-00A0C9054277} = MSCOMCTL.OCX. What can I do to fix this one? Because of missing MSCOMCTL.OCX problem on some of our systems, I bundled the MSCOMTL with our wizard application (copied in the same folder as executable) and now we are seeing this problem.

Note: I have replaced the actual folder hierarchy with "xxx\yyy\zzz" above to hide confidential information related to product.

---

Click the 'Vote as Helpful' arrow if this post was helpful.

Answer 4

OK, now the problem is founded out, it is your application needed component missing.

The remain things I think you should use the VB Forums to ask for help, about how to use it and do not let it missing in your VB6 product in Windows. http://www.vbforums.com/forumdisplay.php?forumid=1

---

Mike Zhang[MSFT]
MSDN Community Support | Feedback to us

Answer 5

I think this is more of a Setup & Deployment problem rather than a VB problem. The problem is seen even if I copy the OCX to "C:\Windows\System" folder and register it using REGSVR32. Why is the MSI installer searching/repairing this component even though its already in the SYSTEM folder and registered? Is there any settings\property in the MSI installer that can turn off this behavior?

---

Click the 'Vote as Helpful' arrow if this post was helpful.

Answer 6

http://www.experts-exchange.com/Programming/Installation/MSI/A_3507-How-to-fix-Windows-Installer-Efforts-to-Self-Repair.html

This article described several ways for your to just disable/prevent this self-repair for your product:

1. Use the regular shortcut replace the advertised shortcut you created in the Setup project.

2. Remove the component information form your .msi file.

 

---

Mike Zhang[MSFT]
MSDN Community Support | Feedback to us

Answer 7

Thanks Mike. The link looks helpful. I'll post how the information in the link helped us fix this issue.

---

Click the 'Vote as Helpful' arrow if this post was helpful.

Answer 8

You're welcome!

---

Mike Zhang[MSFT]
MSDN Community Support | Feedback to us

Answer 9

If a repair is kicking in to do something with mscomctl.ocx, you've done something wrong, and the most likely issue is that you installed mscomctl.ocx without following the sharing rules.  That guid you quoted in that repair message is not the correct one, so perhaps your MSI-based install did not install it using the redistributable merge module. 

Windows doesn't care only that the file is there in a folder. There are sharing rules that must be followed (the guids) to ensure correct reference counting when products that use it are uninstalled, and it cares about versions too, especially if you try to force replacement of a new version with an older version.

---

Phil Wilson

Answer 10

OK. So if MSCOMCTL.OCX is missing on my Windows 7 system then which MSM (Merge Module) or package do I need to use to correctly install MSCOMCTL? Can you provide a link?

Yes, I just copied the MSCOMCTL.OCX in the same folder as my application that uses it. The application is working fine now but one of the MSI starts self repair when it is run, not others. Which makes me think that the problem can be resolved by tweaking this MSI.

---

Click the 'Vote as Helpful' arrow if this post was helpful.

Answer 11

It seems that the MSCOMCTL.OCX is in the "Microsoft Visual Basic 6.0 Common Controls", then try to install it, and then use this command to register it if your System is a x64.

C:\WINDOWS\sysWOW64\regsvr32.exe C:\WINDOWS\sysWOW64\MSCOMCTL.OCX 

---

Mike Zhang[MSFT]
MSDN Community Support | Feedback to us

Answer 12

The problem with that package is that its an update. It says "This package will not install these Common Controls if they do not already exist on the target system".

Seems like I have to remove the ListView from my application. I introduced it because it gives me a clean UI without using mutliple LABEL controls.

---

Click the 'Vote as Helpful' arrow if this post was helpful.

Answer 13

http://www.microsoft.com/download/en/details.aspx?id=5883

---

Phil Wilson

Answer 14

I am writing to check the status of the issue on your side.

What about this problem now?

Would you mind letting us know the result of the suggestions?

---

Mike Zhang[MSFT]
MSDN Community Support | Feedback to us

Answer 15

Hi Mike,

The installer people are still working on it. Phil gave a link for MSCOMCTL Merge Modules for which we'll first need to create a MSI project to wrap the merge module and then call this MSI from our VB application. I'll try that if the installer people are unable to fix it in the MSI with the links that you provided.

---

Click the 'Vote as Helpful' arrow if this post was helpful.

Answer 16

OK.

Have a good weekend!

---

Mike Zhang[MSFT]
MSDN Community Support | Feedback to us