Nom_d_EE
asked on
Another MSCOMCT2.OCX Error 339 registration problem
An extensive search of the web and EE show a number of similar problems to this one, but not quite the same.
I've just introduced a new version of a program which has been successfully running on several thousand machines with a variety of Windows operating systems, 98 through Vista. About one half to one percent of the users of the new version are experiencing a program crash with the message "Run-time error 339. Component 'MSCOMCT2.OCX' or one of its dependencies not correctly registered: a file missing or invalid." These have occurred on XP systems, and one user has reported the same problem on two machines, one with XP and the other Vista. The crash occurs fairly soon after starting the program, apparently as soon as any function in that OCX is called.
My program installs (in the Windows system directory) and registers mscomct2.ocx. It works exactly like my earlier and trouble free program in that regard.
I had one user manually register mscomct2.ocx with regsvr32. The operation reported success, but he still gets the crash when the program tries to access any function in the ocx. Uninstalling and reinstalling the program doesn't help. Users whom I've asked confirm they installed the program as administrator (it won't install otherwise), and are running it as administrator. I had one user run the Dependency Walker on mscomct2.ocx, and he got the same result I do on my properly functioning system.
I'm unable to duplicate the problem here, on my fully updated and well-used XP system, or on a clean new installation of XP or Vista.
One change I made fairly recently is that I went from an old InstallShield Express installer to Inno Setup. There are probably a few hundred copies of the previous version of my program in use with the Inno Setup installer, with no one having reported this problem, so I don't know if that change is related to the problem or not.
Has anyone seen this or a similar problem? Anybody have a clue what the cause might be or how I might go about tracking it down?
Thanks,
I've just introduced a new version of a program which has been successfully running on several thousand machines with a variety of Windows operating systems, 98 through Vista. About one half to one percent of the users of the new version are experiencing a program crash with the message "Run-time error 339. Component 'MSCOMCT2.OCX' or one of its dependencies not correctly registered: a file missing or invalid." These have occurred on XP systems, and one user has reported the same problem on two machines, one with XP and the other Vista. The crash occurs fairly soon after starting the program, apparently as soon as any function in that OCX is called.
My program installs (in the Windows system directory) and registers mscomct2.ocx. It works exactly like my earlier and trouble free program in that regard.
I had one user manually register mscomct2.ocx with regsvr32. The operation reported success, but he still gets the crash when the program tries to access any function in the ocx. Uninstalling and reinstalling the program doesn't help. Users whom I've asked confirm they installed the program as administrator (it won't install otherwise), and are running it as administrator. I had one user run the Dependency Walker on mscomct2.ocx, and he got the same result I do on my properly functioning system.
I'm unable to duplicate the problem here, on my fully updated and well-used XP system, or on a clean new installation of XP or Vista.
One change I made fairly recently is that I went from an old InstallShield Express installer to Inno Setup. There are probably a few hundred copies of the previous version of my program in use with the Inno Setup installer, with no one having reported this problem, so I don't know if that change is related to the problem or not.
Has anyone seen this or a similar problem? Anybody have a clue what the cause might be or how I might go about tracking it down?
Thanks,
have you tried to include a copy of the OCX in the application's directory? I found that with one of my old applications that some people had to copy the ocx and dll into their program directory to work (in my case it was a md5 lib)
ASKER
No, I've never thought or heard of that as a solution. I was under the impression that all apps calling a registered ActiveX component would use the copy at the registered location and ignore other copies. Is that sometimes not true? I certainly wouldn't want to register the copy in the app directory, since deleting it later could break any other applications calling that component.
Among the dependent files for mscomct2.ocx are comctl32.dll and comdlg32.dll. It appears that comctl32.dll has different versions for different operating systems, but I'm not sure. They also might have different language versions. Is it necessary to put these in the app directory also? How about other dependent files?
Thanks!
Among the dependent files for mscomct2.ocx are comctl32.dll and comdlg32.dll. It appears that comctl32.dll has different versions for different operating systems, but I'm not sure. They also might have different language versions. Is it necessary to put these in the app directory also? How about other dependent files?
Thanks!
no you will not need to register a copy
You program will start OCX in the following order:
- System Version thats registered
Should that fail it will run the file thats included in the program's root directory.
Sometimes that can solve random, unexplained problems
You program will start OCX in the following order:
- System Version thats registered
Should that fail it will run the file thats included in the program's root directory.
Sometimes that can solve random, unexplained problems
Unfortunatly dependency walker does not show COM references.
Make sure they install the VB6SP6 redist.
If you are able to reproduce on a system in your lab, I have written a base dependency installation program that updates computers using our importing software for our importing application written in visual basic. This solves 99.9% of all our problems since it checks and registers all COM/ActiveX dependent files properly.
http://www.smartborder.com/sbdependsxpsp2.msi
(also availabe in the downloads section of the site) Please install in your lab/controled environment since this is designed for our software and I cannot be held accountable for any problems with yours. After installing in the lab, you can run a search on files change to determine what files you may be missing. I know it's probably not the best method, but it may get you the answer you need on the missing file.
Remember when updating that file you should check to see if the "dllcache" folder is not undoing your update with the older version. The .MSI file (.NET steup project) properly installs the files. Simply check the version to ensure that you really did update the file.
COM/ActiveX problems are a pain to debug because you never know what's been installed on the system incorrectly.
Make sure they install the VB6SP6 redist.
If you are able to reproduce on a system in your lab, I have written a base dependency installation program that updates computers using our importing software for our importing application written in visual basic. This solves 99.9% of all our problems since it checks and registers all COM/ActiveX dependent files properly.
http://www.smartborder.com/sbdependsxpsp2.msi
(also availabe in the downloads section of the site) Please install in your lab/controled environment since this is designed for our software and I cannot be held accountable for any problems with yours. After installing in the lab, you can run a search on files change to determine what files you may be missing. I know it's probably not the best method, but it may get you the answer you need on the missing file.
Remember when updating that file you should check to see if the "dllcache" folder is not undoing your update with the older version. The .MSI file (.NET steup project) properly installs the files. Simply check the version to ensure that you really did update the file.
COM/ActiveX problems are a pain to debug because you never know what's been installed on the system incorrectly.
however, by placing your own version in the same path as your application you can get around that problem
That only works with standard DLLs, side-by-side compoents or COM components that are referenced as "isoldated" within a .NET project as it includes a manifest and XP knows to look for this manifest.
In a standard visual basic project, you must register the COM/ActiveX control. Regardless if it's located in the local folder or not, it will use the registry to find the file at the location it was originally registered at. It uses the registry for locating the location and class id's by name.
Try it with a VB test app and you will see the functionality of COM.
In a standard visual basic project, you must register the COM/ActiveX control. Regardless if it's located in the local folder or not, it will use the registry to find the file at the location it was originally registered at. It uses the registry for locating the location and class id's by name.
Try it with a VB test app and you will see the functionality of COM.
yeah some ActiveX components do not have to be registered, I have yet to understand why though. I have serveral projects with such activex components.
maybe someone can explain to me or point me to some readings?
Thanks
maybe someone can explain to me or point me to some readings?
Thanks
ASKER
I want to thank everyone who has suggested a solution. But I never like to apply a fix to a problem when I have no clue as to its cause -- unless I'm desperate, anyway. I've spent several days working with a user who experiences the problem, and managed to track it down.
For about seven years I've been using Instant Plus, a SoftwareKey product, to provide compression and some obfuscation of my .exe files. It's worked flawlessly -- until fairly recently. Apparently changes in operating systems have caused its algorithm to produce erratically faulty results. I found that some processed .exe files were ok, but slightly different ones weren't. I've been using version 1 of Instant Plus, and I see that version 2 is now available. But since I no longer use the other features of the package (I quit using them quite some time ago because they were causing other problems), I won't be upgrading.
Anyway, the problem was Instant Plus. There was no need to chase obscure registration problems at all -- all I needed to do was quit using it.
Thanks again for the suggestions. It's been educational.
For about seven years I've been using Instant Plus, a SoftwareKey product, to provide compression and some obfuscation of my .exe files. It's worked flawlessly -- until fairly recently. Apparently changes in operating systems have caused its algorithm to produce erratically faulty results. I found that some processed .exe files were ok, but slightly different ones weren't. I've been using version 1 of Instant Plus, and I see that version 2 is now available. But since I no longer use the other features of the package (I quit using them quite some time ago because they were causing other problems), I won't be upgrading.
Anyway, the problem was Instant Plus. There was no need to chase obscure registration problems at all -- all I needed to do was quit using it.
Thanks again for the suggestions. It's been educational.
ASKER
Please accept my apology. I'm new here and wasn't aware of how things should be done.
I found the cause of my problem. It was use of a product by SoftwareKey called Instant Plus. This is an anti-hacking exe file compressor. It can be used for generating trial software versions with an activation key. I wasn't using it for that purpose, only for its obfuscation properties. I've been using it for years without a problem, but fairly recently, around one percent of users reported the Error 339 message. Anyone seeing this or a similar problem might take a look at any exe file obfuscation or compression that's being done.
I found the cause of my problem. It was use of a product by SoftwareKey called Instant Plus. This is an anti-hacking exe file compressor. It can be used for generating trial software versions with an activation key. I wasn't using it for that purpose, only for its obfuscation properties. I've been using it for years without a problem, but fairly recently, around one percent of users reported the Error 339 message. Anyone seeing this or a similar problem might take a look at any exe file obfuscation or compression that's being done.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.