How To Fix Component Mscomctl.ocx
Rosy Demorest
I've tried installing MVPedit 2006.2, but when I try to open it, it says "Component 'mscomctl.ocx' or one of its dependencies not correctly registered: a file is missing or invalid." I tried running both the installer and the prjMVP with XP/SP3 and it's still not working. Anyone have any ideas to get it working? Thank you.
We have an application for which we are creating a new more modern installer using the Wix Toolset.
This application requires several files that from what I have read have been deemed by Microsoft as redistributable by applications.
Those files are comctl32.ocx, ComDlg32.ocx, mscomctl.ocx, mscomct2.ocx, msstdfmt.dll, tabctl32.ocx, and Tlbinf32.dll
We are trying to ensure that these files are properly installed as shared so that if our application, or another, were to uninstall them, they would not be removed until no application needs them any longer.
From what I can determine, this is apparently by using the same Component ID (Guid) for these files by each installer (separate one per file).
The issue is that I am unable to find what this Component ID should be.
We managed to scavenge Component IDs for these files from the registry of a machine that has them installed, but in most cases, more than one Component ID was identified.
The other way to approach this is to use a merge module, unfortunately, it seems that Microsoft does not provide that for these files.
Although I have not opened that update in any editor, based on the information in the registry, that seems to be one of the two component id we got from the registry.
The problem is that the other component id is apparently from Office 2010, Visual Studio 2015, and other similar apps, as well as QuickBooks, and Crystal Reports, so I really was not sure what the correct value should be.
It seemed odd to me that the Component IDs for shared files would have changed, especially for those specified by Microsoft installers.
Because of that I was unsure how to correctly do this.
As far as I can tell tlbinf32.dll was distributed with VS6 and VB6 and was also updated with related service packs. Perhaps you can test to see if those products are installed and/or do a file search for the dll. In my ancient 32-bit Win2K VM it was installed in the System32 folder. When I peeked inside the VS6SP6.exe iinstaller I did not see any .msi files. The tlbinf32.dll file was contained inside the vs6sp61.cab file and the main application seemed to be acmsetup.exe.
I am pretty sure that I read that it was on a Microsoft webpage years ago, but I would not be surprised if that page is now gone with Microsoft removing and changing everything.
There is actually an 8 year old nuget package for that dll ( ) with the source here:
According to C:\Program Files (x86)\Microsoft Visual Studio\VB98\REDIST.TXT the tlbinf32.dll is part of REDISTRIBUTABLE CODE - STANDARD which I take it to mean that it IS redistributable, even though it is now no longer supported.
As I mentioned before, I am unsure of a way to replace this file at this time, that is without a full rewrite to .NET which is just not a possibility at this time. We still need to be able to support COM and to dynamically call methods in COM objects from an exe that was created with VB6.
Unfortunately, replacing the exe with a .NET app will not work at this time. They initialize the process differently which causes some COM dlls to fail when running under a .NET exe. If I knew what the differences were and how to get the .NET exe to initialize like the VB6 one, then perhaps we could invest the manpower to convert, however we would still need to dynamically call methods in COM dlls, and I do not know how to do that currently. When calling .NET dlls from .NET it is simple to use reflection to accomplish that.
Have you considered using registration-free COM with tlbinf32.dll so that you can install your own private-use copy and avoid having to deal with the registry for COM? I'm not intimate with VB6 but I think I remember reading that it does support registration-free COM.
The old msdn magazine article about tlbinf32.dll is at visual-basic-inspect-com-components-using-the-typelib-information-object-library. There is a related sample but of course the link doesn't work.
Then I copied the sample program executable, TLBINF32.DLL, MSCOMCTL.OCX and COMDLG32.OCX to a folder on my Win10 21H1 system. I placed manifests for the above into the same folder. No COM registration was performed. The sample program executed on my Win10 system as seen below -
The manifest tool was able to embed manifests in the VB6 executables. But it seems that when creating activation contexts from embedded manifests the system will only search for DLLs. So it doesn't find the two .OCX files and an SXS error results. I worked around this by merging the manifest information for COMDLG32.OCX and MSCOMCTL.OCX into the manifest that was embedded in TLBINF32.DLL. The manifest embedded in TypeLibraryExplorer.exe was adjusted accordingly. Success!
The actual name of the common control class will vary depending on what control the project references, such as ProgressBar, StatusBar or TreeView; however the error always indicates a Windows Common Control name. Visual Basic will generate a logfile that lists the control or controls that could not be loaded, along with various invalid property names.
This error occurs when one or more of the Microsoft Windows Common Controls are not registered, or the registry information has been corrupted. There are three common controls components available for Visual Basic 6:
Most of the SocketTools examples for Visual Basic 6 use the first common controls component (mscomctl.ocx), but there are several that may use the others as well. To fix this problem, it is recommended that you re-register each of these components using the regsvr32.exe utility. Prior to registering these components, make sure that you have closed all running instances of the VB6 IDE. If the IDE prompts you to save any changes, do not save them to prevent the references to the common controls from being removed from the project.
If the system is running Windows Vista or later versions of Windows, the control registration must be performed with administrative privileges. To do this, you should open a command prompt by selecting Start > All Programs > Accessories and then right-click on Command Prompt. From the context menu, select Run as Administrator. With UAC enabled, this will cause a confirmation dialog to be shown.
If the system is running a 64-bit version of Windows, the components listed above will be in the C:\Windows\SysWOW64 folder. This is where 32-bit ActiveX components and DLLs are stored on 64-bit systems. Change your current working directory to that directory before registering the components.
After each command is entered, a confirmation message box should be displayed indicating that the control has been registered successfully. When all three common control components have been registered, re-open your project in Visual Basic 6.
64591212e2