IE6 update makes certain CHM pages slow to load

[osRe]

After installing IE6SP1 update 916281 CHM pages that make use of HHCTRL.OCX take long to load.

Here's an example of embedding such an HHCtrl object:

<OBJECT ID="hhobj_2" TYPE="application/x-oleobject" CLASSID="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11">
	<PARAM NAME="Command" VALUE="ALink,MENU">
	<PARAM NAME="DefaultTopic" VALUE="../../notopic_0pk4.htm">
	<PARAM NAME="Item1" VALUE="">
	<PARAM NAME="Item2" VALUE="_win32_wm_cut">
</OBJECT>

The more instances of this object there are, the longer it takes to load.

If ActiveX is disabled the pages load quickly.

Any idea how to fix it?

(It looks like KB916281 doesn't provide an uninstall, so I'm not even sure how to cleanly remove it if that's the only solution.)

[ShadeTreeLee]

Look for "Internet Explorer Q916281" under Add/Remove Programs list for the uninstaller. It should restore original files you had before this Cumulative Internet Explorer Update was installed. But the one prior to this one (912812) had broken ActiveX issues of it's own, serious ones.

You might be able to kill bit that particular ActiveX object to defeat the delay?

How to stop an ActiveX control from running in Internet Explorer

Deja Vu? I was thinking MS already kill bitted(sic?) web help files way-way back when we still had support?

[osRe]

You're right, there is an uninstall entry. I looked for it under another name.

Any advantages to using a killbit to disable the CLSID rather than just renaming the CLSID key or deleting its DLL reference? In both cases I suspect some CHM features may stop working.

You say the previous cumulative IE update had ActiveX problems too. Are those really bugs or perhaps intentional "security" measures?

Any idea if using newer IE updates (that are officially Win2K+ only) or perhaps a newer version of HHCTRL.OCX might help instead?

And what do you mean by "killed web help files"? CHM documentation is still the standard. Or you mean CHM features when used under IE and not HTML Help?

[osRe]

ShadeTreeLee, turns out your suggestion was spot on, but in reverse.

That CLSID had a kill bit set by the update (or so it seems). Removing the ActiveX Compatibility entry removed the delay. I'm not sure why a disabled control would add a delay, though. Maybe it's related to the AlternateCLSID provided for it (which I don't think was set by the update).

(I also don't get the point of that AlternateCLSID which points to exactly the same OCX with the same parameters, but with another CLSID: 41B23C28-488E-4E5C-ACE2-BB0BBABE99E8. But whatever, no delay, mission accomplished.)

Thanks for the help.

[cluberti]

(I also don't get the point of that AlternateCLSID which points to exactly the same OCX with the same parameters, but with another CLSID: 41B23C28-488E-4E5C-ACE2-BB0BBABE99E8. But whatever, no delay, mission accomplished.)

It's a trampoline of sorts - it tells the application doing the lookup to use the same .dll file, but load a specific (different, newer) version of it. So yes, killbit'ed controls with an AlternateCLSID will actually slow a page load down (it shouldn't be as much that it would be that noticeable, but I guess it is indeed possible).

Note that it was killed for security reasons, so removing the killbit means you're loading the old (less secure) control again.

[osRe]

It's a trampoline of sorts - it tells the application doing the lookup to use the same .dll file, but load a specific (different, newer) version of it.

Of course, but in this case while the CLSIDs are different, their contents is exactly the same. Same referenced OCX, same keys and values. So I don't see the point.

killbit'ed controls with an AlternateCLSID will actually slow a page load down

Doing a few more registry probes shouldn't slow down, or you mean something else? (I guess it's possible though, with the way Microsoft sometimes does things. It might take a few seconds for IE's Find dialog to show [a self contained COM object, no less. ], so who knows...

Note that it was killed for security reasons, so removing the killbit means you're loading the old (less secure) control again.

From what I gather newer version of HHCTRL.OCX should have fixed it, and I seem to have that newer version (too much reading to do to really figure out what's going on, so I may be wrong). But it doesn't matter, otherwise it'd be the removal of that IE update altogether; I care more about rapid access to the docs than worry about theoretical exploits. (Loading those particular slow pages felt like I was using, *shudder*, Document Explorer.)

[ShadeTreeLee]

You're right, there is an uninstall entry. I looked for it under another name.

Any advantages to using a killbit to disable the CLSID rather than just renaming the CLSID key or deleting its DLL reference? In both cases I suspect some CHM features may stop working.

I wouldn't know but I have the same suspicions.

You say the previous cumulative IE update had ActiveX problems too. Are those really bugs or perhaps intentional "security" measures?

No not at all. Total lockup requiring cold boot up when using ActiveX in a normal manner type of a bug. That's why I called it a serious bug, it is serious. As far as I am concerned that is a broken update (912812) and always will be.

Any idea if using newer IE updates (that are officially Win2K+ only) or perhaps a newer version of HHCTRL.OCX might help instead?

Nope, none at all. So best of luck.

And what do you mean by "killed web help files"? CHM documentation is still the standard. Or you mean CHM features when used under IE and not HTML Help?

I meant killing online help which is where the bug was that was allowing site hijacking to occur without the users permission or notice. And this allowed code to be run that was bad stuff. So MS kill bitted it. And then they fixed it. And then, I forget what they did but it was confusing at the time and has remained so all this time. I have no idea what came first or how it was left. I suspect no one ever got hurt from the vunerablity but when you leave gapping holes wide open something tends to fly in them eventually. Kill bitted means dead to me which is where I want a service I never used anyway to be at.

[erpdude8]

From what I gather newer version of HHCTRL.OCX should have fixed it, and I seem to have that newer version (too much reading to do to really figure out what's going on, so I may be wrong). But it doesn't matter, otherwise it'd be the removal of that IE update altogether; I care more about rapid access to the docs than worry about theoretical exploits. (Loading those particular slow pages felt like I was using, *shudder*, Document Explorer.)

Did you install the latest HTML Help update, shae?

Try MDGx's unofficial HTML Help update which has the latest HHCTRL.OCX file:

http://www.mdgx.com/files/HHUPD.EXE

A MUST when installing the latest available cumulative IE6 security update.

[osRe]

Did you install the latest HTML Help update, shae?

Doesn't look like it. I don't remember anymore if I'm using the latest IE6 updates (beside the one that broke CHM browsing), but CHM is fine now, so no reason to shake the equilibrium.

(I shudder to think what I'd have to do if I ever reinstall Win98. Impossible to remember what strange installs and tweaks took place.)