 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / Controls / November 2009MSCOMM Control Failed To Create - Suspected Windows Update Issue
Hi All, I have an access application that was working fine for many years, and was using numerous ActiveX components. One of the components is the MSCOMM32.ocx. Last week our customer rang and advised they are getting an error where the application starts and the error indicates registration issues. I have re-registered using regsvr32 utility and it advised registration completed successfully. However running the application which tries to create the control object fails. Any help will be much appreciated.  SignatureBest regards, Eli Abitbol B.Eng. (Hons) Electronic Systems Senior Design Engineer This sounds like a Registry error, that might require some manual editing of the Registry. What might have happened is that some other application was installed that placed another copy of MSComm on the PC and registered it, and now the COM process is confused. What I'd do is to, first, search the hard drive for multiple copies of MSComm32.ocx. There should be only one, in the Windows\System or Windows\System32 folder. If you find multiple copies, run regsvr32 to unregister the one(s) that you next will delete, the run regsvr32 to reregister the instance of MSComm that you want to retain. MSComm32.ocx has no components that it is dependent upon, so this "should" fix the problem. Otherwise, you may need to use REGEDIT to examine the Registry itself to fine the issue. You say that you suspect a Windows Update issue, but I haven't heard of any problems with this process. Still, a fallback that I did at one time (for something that was Update related) was to use a Restore point to restore to a known time when everything was working -- I then verified proper operation and re-executed Windows Update to get back to status quo... Sure enough, this solved the problem. Dick SignatureRichard Grier, MVP Hard & Software Author of Visual Basic Programmer's Guide to Serial Communications, Fourth Edition, ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March 2006. See www.hardandsoftware.net for details and contact information. Hi Richard, Thanks for the prompt feedback. The reason I suspect Windows Update as after performing system state restore for 3 days before the day of problem occurs this fixes the issue. I have found the mscomm32.ocx in Windows\System32 folder and re-run the regsvr32 against it with no success. I will try your suggestion of finding all other mscomm32.ocx in the system un-registering them and the re-registering the one in Windows\System32. I will keep you posted, and many thanks for your help. Eli SignatureBest regards, Eli Abitbol B.Eng. (Hons) Electronic Systems Senior Design Engineer > This sounds like a Registry error, that might require some manual editing of > the Registry. [quoted text clipped - 21 lines] > > Dick I've had others report similar issues.... I'm going to investigate this in more detail when I get the opportunity. Dick SignatureRichard Grier, MVP Hard & Software Author of Visual Basic Programmer's Guide to Serial Communications, Fourth Edition, ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March 2006. See www.hardandsoftware.net for details and contact information. Have you come across any clean solutions? Uninstalling the 969898 patch allows mscomm32 to work as it did, but leaves one vulnerable. ----------------------------------------------------------------------------- Our Peering Groups change Visit : http://spacesst.com/peerin Hi, You only are vulnerable, if you host MSComm in IE. There are no vulnerablilties for other applications that I know about. The fact that these kill-bits affect its use in Access is a bug (IMO). And, I believe that NETComm solves the kill-bit issue, anyway. Dick SignatureRichard Grier, MVP Hard & Software Author of Visual Basic Programmer's Guide to Serial Communications, Fourth Edition, ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March 2006. See www.hardandsoftware.net for details and contact information. I agree the 969898 patch is the culprit. I too have many programs that use the MSCOMM control. And everyone of them fail if 969898 is installed. These are Access based applications using local serial port communication that present no risk. There is no security issue. A solution to this oversight is needed yesterday. The machines that have the patch removed will not install further updates so they are then left vulnerable to 'valid' security risks. If anyone has a solution that does not involve re-writing dozens of applications please post it here... > Hi, > [quoted text clipped - 5 lines] > > Dick I have the same issue. Installed MS Update 973346 and it killed the MSComm controls in MS Access 2007 or 2003. Any word on a fix? SignatureBill Ross Denver, CO > I agree the 969898 patch is the culprit. I too have many programs that use > the MSCOMM control. And everyone of them fail if 969898 is installed. These [quoted text clipped - 14 lines] > > > > Dick Hi Mr. Grier, I also have a couple of MS Access applications (live production systems) which have suddenly stopped working because of this kill bit. One uses the MSComm control to receive input to an Access form from a weighing scale, the other processes input from a scanning device. I can't find anything anywhere that says what to do about it. Sure VB.Net has a new COMM class but what are Access and vB6 users supposed to do???? It is beyond aggravating that Microsoft has just left us hanging. My clients have rolled back the update, but I doubt this is a good long term solution especially since MS seems to keep sneaking the kill bit back in on other updates as well. > Hi, > [quoted text clipped - 5 lines] > > Dick "Lisa_BellHawk" <Lisa_BellHawk@discussions.microsoft.com> wrote... > Hi Mr. Grier, > I also have a couple of MS Access applications (live production systems) [quoted text clipped - 11 lines] > on > other updates as well. Have you read this, http://msmvps.com/blogs/access/archive/2009/06/14/an-older-version-of-mscomm32-o cx-has-had-the-quot-kill-bit-quot-flag-set.aspx It lists 3 options. I have not tried any, but I would think option 2 would be the logical choice, "- locate the newest version of mscomm32.ocx and distribute to your users/customers." David I have over 50 users with applications requiring the MSComm32.ocx. I can just imagine how much fun I'm going to have when the complaints start rolling in. Please - FIX!!! > Hi, > [quoted text clipped - 5 lines] > > Dick Hi Mr Grier, Im using an excel add-in feature to acquire data from an electronic device that uses RS-232 to serial . Recently as has been mentioned before in this blog the new microsoft update patch namely KB969898 once installed gives me a runtime error 424-object required before i even begin gettin data. I went into the VB code and found where the error was MSComm.CommPort = Val(Right(fPORT, 1))-(this is where the error is) fPORT.AddItem "COM1" fPORT.AddItem "COM2" fPORT.AddItem "COM3" fPORT.AddItem "COM4" Im not much of a VB person but based on my investigation the value that we get out of the Val(Right(fPORt,1) code is being assigned to MSComm.CommPort, and i think the new security patch namely KB969898 is not allowing to set values on any MSComm components. Is there a new version of mscomm32.ocx that needs to be installed? or is there any other alternative to using MSComm? Any kind of help will be much appreciated. Rico > I've had others report similar issues.... I'm going to investigate this in > more detail when I get the opportunity. > > Dick Solution: Internet Explorer was blocking the MSCOMM control. It likely does so for other activex controls that are installed from unsigned (won't pay a fee) projects. HKEY_LOCAL_MACHINE\Software\Microsoft\InternetExplorer\ActiveXCompatibility\{648A5600-2C6E-101B-82B6-000000000014}modify the compatibility flag to a value of 0. http://www.tek-tips.com/viewthread.cfm?qid=1564508&page=1 http://support.microsoft.com/default.aspx/kb/957924 > Solution: > [quoted text clipped - 6 lines] > > http://www.tek-tips.com/viewthread.cfm?qid=1564508&page=1 The problem with modifying the registry is that this modification may well be "undone" by future SPs, and would then have to be reapplied. SignatureRichard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue Lakewood, CO 80228 303-986-2179 (voice) Homepage: www.hardandsoftware.net Author of Visual Basic Programmer's Guide to Serial Communications, 4th Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July 2006. Hi, A recent service pack included "kill bits" for MSComm32.ocx. The intent was to keep it from executing (stand-alone) in IE. The effect was to keep it from being used in things like Access and Excel (etc.). It still works fine in VB applications. You can use NETComm.ocx, which is a wrapper for MSComm32.ocx (a free download from by homepage) to avoid this problem. Its use does require that code be modified to use the InputData method instead of MSComm's Input method to read data. All other code should work without additional change, unless the CommEvent property is used, which has the same numeric enumeration, but the enumeration names vary slightly. Dick SignatureRichard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue Lakewood, CO 80228 303-986-2179 (voice) Homepage: www.hardandsoftware.net Author of Visual Basic Programmer's Guide to Serial Communications, 4th Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July 2006. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.