plugin.ocx revisited

[BikinDutchman]

Warning: this gets a little techical

I have been testing Boooggy's WMP11 integrator and found some strange behavior for plugin.ocx.

I know that plugin.ocx is obsolete and a security risk, and we all hope that WinXP SP3 arrives soon so that we can forget it.

Right now it is common to just delete plugin.ocx from nLite WinXP SP2 integrations and that results in the following message in Setuperr.log:

"Setup could not register the OLE Control C:\WINDOWS\system32\plugin.ocx because of the following error:

LoadLibrary returned error 126 (the specified module could not be found)."

Well, that seems pretty harmless but I decided to fix it so added "plugin.ocx = 16" to the fileflags list in TXTSETUP.SIF.

After that I suddenly got many signing errors in Setuperr.log for WMP11 files because I used the WMP11 integrator without nLite in a WinNT32 install (will report that later).

IMHO this indicates that the plugin.ocx registration failure led to skipping other steps.

My suggestion is: Do not just remove plugin.ocx during integration (by addons), add it to the FileFlags list (Nuhi?), and uninstall it after installation (regsvr32 /s /u & DEL)

This problem will go away soon enough enough but there will be other crap files in the future; so also for those: remove them without any installer errors because you never know what other effects these errors have.

[redxii]

I'm not sure about it going away in SP3. I integrated 3205 and the one before that and it still copies plugin.ocx and complains about it if it isn't in i386. I had already emailed them about it.

[newsposter]

plugin.ocx is a pretty generic filename. I've seen it (most often) reference to a specific MSIE file (hosts Netscape-style plugins) **and** as wholly different files for Access, Oracle9/10, etc, etc.

This article may be of relavance:

http://support.microsoft.com/kb/912945

If we're talking about the MSIE component, it appears to make a great difference in which order that plugin.ocx is registered when compared to other MSIE components.

Edited November 18, 2007 by newsposter

[BikinDutchman]

redxii: ouch!

newsposter: It is the plugin.ocx that comes with the WinXP SP2 installation (I slipstreamed RTM with the SP2 update)

[Kelsenellenelvian]

The plugin ocx error is due to one of the hotfixes MS released awhile ago.

There is no way around it and it causes no system problems MS simply killed a file and never fixed the fact that it causes that setuperr on integration.

You can find lots of information on it at ryans site...

[BikinDutchman]

The plugin ocx error is due to one of the hotfixes MS released awhile ago.

There is no way around it and it causes no system problems MS simply killed a file and never fixed the fact that it causes that setuperr on integration.

You can find lots of information on it at ryans site...

Kel:

I do not believe this has anything to do with hotfixes. I had an up to date installation (Xable) and could get rid of the error by:

-Adding "plugin.ocx = 16" to the fileflags list in TXTSETUP.SIF.

-Removing any [obsolete_files] entries for plugin.ocx from addons

Also I have indications that the registration error has side effects (Boooggy WMP11 integration), I will try to reproduce that (costs time) and report later.

My main point is that it is risky to ignore installation errors however small they may be. I have bad experience with that myself.

In this case the solution is imho: leave it in and uninstall it later. (I am now running into the issue that plugin.ocx is protected by sfc but maybe more about that later).

[Kelsenellenelvian]

Read THIS:

Why does setuperr.log compain about plugin.ocx being missing?

As of the KB912945 update from Microsoft, plugin.ocx is now obsolete and deleted during the normal installation of any Cumulative Internet Explorer Update. Therefore, setuperr.log complains. However, the message is 100% safe to ignore because the file is obsolete.

[BikinDutchman]

Read THIS:

Yes it is obsolete: KB912945 removes plugin.ocx the official way, so no SFC complaints, and no side effects. (It also changes ActiveX control behavior.)

But I am discussing how to get rid of plugin.ocx in the initial Windows installation without side effects.

I found it out now but it is pretty complicated:

-add plugin.ocx = 16 to [fileflags] to TXTSETUP.sif

-do not remove the plugin.oc_ otherwise

-hex edit sfcfiles.dll to replace all plugin.ocx by <NUL>lugin.ocx (with xvi32)

--repair the checksum (with PEChkSum)

--compress (with cabarc -m LZX:21)

-unreg and delete plugin.ocx after installation

A few questions:

-Did someone ever try to integrate KB912945 upfront (with nLite, Ryan)?

-What about adding a feature to nLite to remove files from sfcfiles.dll (as I did manually)?

[redxii]

SP3 v3244 no longer copies/complains about missing plugin.ocx but you'll have to delete it yourself since their integrator won't.

[BikinDutchman]

SP3 v3244 no longer copies/complains about missing plugin.ocx but you'll have to delete it yourself since their integrator won't.

Could you delete it without tweaking sfcfiles.dll?

[redxii]

Yes you can delete it without tweaking sfcfiles.dll

[BikinDutchman]

The whole plugin.ocx issue seems to be resolved with nLite 1.4.1.

I am still with WinXP SP2 but no longer tweak addons, SFCfiles.dll and the error message does not show up in Setuperr.log.

The updates for v1.4 somehow resolved this issue as well .