If one of the ActiveX controls on your machine has registration problems, PowerBuilder can end up being unable to use any ActiveX controls. This manifests itself in a couple of different ways when you go to the Insert->Control->OLE... menu option and then click on the Insert Control tab.
PowerBuilder 9.x:Â You will get a system fault as follows:Â Faulting application pb90.exe, version 9.0.0.5507, faulting module msvcrt.dll, version 7.0.2600.2180, fault address 0x0000beab.
PowrBuilder 10.x: PowerBuilder won't crash, and in fact the list of ActiveX controls will display. When you drop one on the window, however, it won't behave properly.
Sybase solved case 10906461 explains what PowerBuilder does when you click on that tab. It's basically looping through every ActiveX control entered in the registry and loading information about them. The issue is that Powerbuilder does not responsd well when one of them has registration problems. It also doesn't give you any information about which one is causing the problem. If you've got several hundred ActiveX controls installed on the machine, it can be a nightmare to figure out which one is the issue.
The way I recently addressed it was by loading up both RegMon and FileMon from SysInternals and started them capturing information right before I hit the Insert Control tab. When PowerBuilder crashed (in the case of PB 9.0.3), I reviewed the captured logs to determine which ActiveX control it might have been trying to access when the crash occurred. I then exported the registry keys for that particular ActiveX and then removed those keys from the registry. Note that a single ActiveX can have a number of entries, so once you find a potential bad actor you need to make sure you remove all of the entries for that particular control.
I had to do that several time before I finally tracked it down to the correct ActiveX. Then I re-imported the exported registry entries (restoring the system to the previous state). Finally, I ran REGSVR32 on the misbehaving ActiveX to unregister and reregister it.
3 comments:
Hi,
Thank you for your solution.
And I found this...
FileMon and Regmon are no longer available for download. They have been replaced by Process Monitor
from
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Bruce,
Thanks for the advice; I have been through the algorithm twice. After the third iteration, I was down to a single registry listed by procmon, and ater deleting the key, tried to add a customolecontrol on my PB window. PB blew up and procman displayed all the keys that I had deleted! Apparently that last key was a windows critical key and it issued a restore. My question is this: can you give me something specific to look for in the procmon listing to identify the offending key(s)? I am not a particularly strong Windows programmer, and have had little experience with the Registry to boot. My client is under a lot o pressure from on high to get the hardware operational, ergo so am I, even though when they asked me to take this on, they acknowledged that they understood I was not an expert. Thanks
Bruce Hall
It should be the last entry (or close to it) that accesses something under HKEY_CLASSES_ROOT\CLSID.
Post a Comment