dcom98 Interaction problems

[CLASYS]

Just sleuthed out some sticky interactions involving dcom98 and indirectly related updates.

As many know, currently the Unofficial Service Pack doesn't support QFECHECK information for the underlying updates. Thus, some [including me] are interested in the installation of the readily available updates independently [hopefully in unattended batch files] to establish the QFECHECK information. [QFECHECK is available in virtually every update package; you only need it once. It gives you an opportunity to see problems where installed updates flag installed files that become either missing or too-low versions. It mostly accomplishes what it sets out to do [but not completely!].]

In the course of creating [admittedly somewhat redundant to the SP] these batch update files, I have found a small few sore cases. Here's one I found to watch out for:

There are two updates to 98SE that are the source of the file RPCRT4.DLL, Q258191 provides 4.71.3331.0 and Q269874 provides 4.71.3336.0 [and apparently is the source of the file as found in SESP2.1a].

I generally put the updates together in a batch file containing a bunch of lines like:

START /WAIT 269874usa8.exe /q:a /r:n

and expect to boot once after it finishes, etc.

It didn't seem to work out correctly, because the file RPCRT4.DLL was being set back to version 4.71.3328.0 seemingly out of nowhere. [More below on exactly why what was stated was yet another problem.]

I finally traced it down to update 315575, which nominally does NOT update RPCRT4.DLL, yet it CAN!

Unless DCOM98 1.3 is already installed, the 315575 update runs an internal copy of DCOM that will also attempt to update RPCRT4.DLL, but it's a deferred update until during the next reboot.

Since I used all three updates in the same batch, the back-dating of RPCRT4.DLL from 315575 [from the DCOM98 within] won out after the reboot.

The fix is to first run DCOM98 explicitly before any batched updates. [DCOM98 requires a reboot; I doubt if anyone can provide a way to prevent this reboot, or at least make it not mandatory; I don't know how to suppress the reboot requirement, yet 315575 itself supports the proper switches to do it overall just fine, etc.]

So, the final batch does run the same three updates, in numerical order, if that should matter. Since DCOM98 was accomplished on a prior reboot, all installs as expected [after a single final reboot].

Now back to the QFECHECK problem:

This is now the second occurrence of an anomaly where somehow QFECHECK is thwarted and will not complain when there is a legitimate problem you SHOULD be seeing.

The above [un-repaired version] example installs 258191 and 269874 [and also 315575 that caused the problem without a prior DCOM98 install] winding up with RPCRT4.DLL at the incorrect revision of 4.71.3328.0.

Within the QFECHECK output, totally correctly the 269874 reports the 3328 as invalid [since it requires 3336]. However, 258191 seemingly has no problem with 3328, yet clearly it requires 3331 or better.

If you delete RPCRT4.DLL, the QFECHECK report becomes correct: Each of the two updates complains the file is now MISSING and each indicates its respective required minimum revision.

Anyone able to shed any light on how an update can fool QFECHECK this way?

The other known situation is when you install Q238329, it installs VIP.386 version 4.10.0.2223. But installing this update prevents the file update to still higher revisions associated with Q238453 [2224], Q242962 [2225], and Q2259728 [2226 and apparently the source of the file for the SESP2.1a package]. Even the SESP2.1a package itself cannot fix this! [The only way to fix it is to just delete vip.386; any newer update will then put in the update-appropriate version, including the SP. Fortunately, this file is generally not in use so you can easily delete it from Windows. I delete it in the batch update file after I install 238329 to get the QFECHECK information, and all is fine, etc.]

Not fixing the above problem reveals the same ill behavior of QFECHECK. All of the mentioned updates work the same exact [totally incorrect] way. If VIP.386 is actually present at the 2223 level, all the newer updates aren't complaining about this and seem to like the 2223 level just fine. And deleting Vip.386 makes all of the updates work properly, each reporting MISSING and requiring their respective minimum required levels; any of the newer updates [or applying the SP] fixes the entire problem.

But this is just "burying" the QFECHECK problem. The point is that QFECHECK is supposed to be trustworthy to reveal updates that are corrupted, missing, or accidentally down-graded. To the extent this might involve either of these two files, QFECHECK cannot totally be trusted.

[Note: There is a side issue to the weakness of QFECHECK: There is no indication within QFECHECK whether the indicated revision is merely the minimum requirement or is perhaps somewhat higher. Unless you have QFECHECK information for the HIGHEST installed revision being the minimum requirement for some update, it is possible for a file to be down-graded and yet find no errors in QFECHECK; the one requiring the actually present file will flag it as an error when the file gets down-graded, but prior updates won't because they don't require that high a level, etc. This issue does come up because there are apparently some update files in the SP not even associated with a specific update package for which QFECHECK info even exists. Unless and until the SP provides QFECHECK information to cover the provided revision, these cases can never be flagged when the accidental down-grade occurs. This same situation will happen with packages like 982ME and the like. By providing a QFECHECK manifest file, all of these problems can be averted. However, this assumes the problem associated with the two files cited doesn't happen!]

These two problems likely have something to do with some .inf file issue in their respective installers. Awhile ago I sent Gape the VIP.386 problem update because that early update is obscure; I can give it to anyone who wants to see for themselves; the RPCRT4.DLL problem appears in a more readily available update; I can provide it as well, etc.

cjl

Edited May 9, 2006 by CLASYS

[erpdude8]

I think you got us LOST, CLASYS. Can you please explain what you said in FEWER and SIMPLER words? My head hurts in reading your lengthy post!

Q300234 update for Win98 also has RPCRT4.DLL file v4.71.3331.0 but Q300234 has newer SENS.DLL file than the one found in Q258191, plus Q300234 included the Dcom98.exe package.

also the "/r:n" switch actually prevents the computer from rebooting. I got NO prompt to reboot, nor the computer will automatically reboot after the patch is done.

After installing Q269874, the updated rpcrt4.dll file [v4.71.3336] isnt acutally installed until you reboot the computer. that's because the WININIT.EXE file (in DOS mode when Win98/ME boots up) has to rename & delete the older rpcrt4.dll file and then rename the newer rpcrt4 file (which I think is named as rpcrt4.000 or rpcrt4.001) to rpcrt4.dll before the Win98/ME desktop loads.

It's best to install dcom updates Q315575 & Q240664/Q243220 first and then install the Q269874 update last. then there wont be problems.

[CLASYS]

Sorry to cause headaches, but I really thought a guy who can juggle hundreds of updates on the forum and the great website could handle a few threads multi-tasking [and I do tend to ramble on when posting in the early am!]

In any case, you are correct about the interaction between any updates trying to update the RPCRT4.DLL file and any updates specifically harboring DCOM98 as an internal update option [such as 315575 and 300234 as you mentioned: Can I get a copy of 300234; it clearly is a superset of 258191.]

By first installing ANY update with dcom98 inside of it, the subsequent running of others ought to not try to do it again. Thus, a batch of updates all doing /q:a /r:n and only a single final reboot should install correctly. But only if the dcom98 install is performed EARLIER, rebooted, and apart from the larger batch of updates with the single reboot, etc. Thus, as you state, 269874 gets done "later" [as part of the big batch of updates that run unattended with a single final reboot]

cjl (see next non-headache-provoking post)

[CLASYS]

Now back to ending other confusionaries:

I installed dcom98 DIRECTLY using KB165101's wisdom [direct install of DCOM98.EXE]. This update DOES NOT support the reboot-suppression switch[es] apparently; just install DCOM98 and reboot.

However, 315575 DOES support the /r:n thus if it's gonna be the one to put dcom98 in, you can prevent the reboot as most updates should. [And I assume so does 300234, which I would like to use presumably in the same way, etc.]

But this still requires a reboot so, as you described, wininit.exe can update which file is to become the final rpcrt4.dll taken from the .000 or .001 version, etc. Thus, if 315575 [or presumably 300234] is used as the way to get dcom98 installed once, you still need to reboot before attempting the 269874 or whatever to get a higher rev file installed last.

Thus, the fact that you can defer the reboot is mostly moot; you have to reboot to finish it off before eventually doing 269874. Just that the KB165101 version doesn't give you the option of deferring said reboot.

There is a "dirty 1/3-dozen" of updates that cannot be batched together which I install first. Some of them, such as 249973, are simply broken and bail out instead of doing their job due to flawed interaction with some other updates, such as IE 6.0 SP1 installation to name one. For these uglies I do them separately and firstly. After all of them are done, IE 6.0 SP1 updates can be installed, and then a large batch of most of the 98SE updates available in hotfix form. [And that ends with a single reboot, after which all of the files have their updated QFECHECK info correct.]

Hope that clears up the confusion and doesn't strain your brain

cjl

[CLASYS]

It's best to install dcom updates Q315575 & Q240664/Q243220 first and then install the Q269874 update last. then there wont be problems.

Good ideas about 315575 and 269874 aside:

Isn't Q240664 an NT update? [should we care about this for 98SE? And if so, can I get a copy?]

I don't have Q243220, but it seems to provide RPCLTCCM.DLL to the same level as the SP 2.1a. Again, can I get a copy of this? And what relevance to the rpcrt4.dll problem?

Apparently a relatively new bunch of updates out there, presumably good stock in the erp collection [or mgdx?] Can I get read access or a list of what's available now? [this thread has raised three of them. if you include 300234.]

cjl

[MDGx]

- DCOM98 RPCLTCCM.DLL 4.71.3328 Fix for Windows 98/98 SP1/98 SE:

http://support.microsoft.com/?id=243220

Direct download [151 KB, English]:

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

MUST (re)install this Fix AFTER installing RPCLTSCM.DLL + RPCRT4.DLL Fixes above!

All DCOM patches + updates:

http://www.mdgx.com/add.htm#COM

HTH

[CLASYS]

- DCOM98 RPCLTCCM.DLL 4.71.3328 Fix for Windows 98/98 SP1/98 SE:

http://support.microsoft.com/?id=243220

Direct download [151 KB, English]:

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

MUST (re)install this Fix AFTER installing RPCLTSCM.DLL + RPCRT4.DLL Fixes above!

All DCOM patches + updates:

http://www.mdgx.com/add.htm#COM

HTH

Sorry to have opened this can of worms:

So, KB article 240664 is for NT, but update Q240664.EXE implements what KB243220 describes? [And thus SHOULD have been called Q243220.EXE but they never did that! ?]

I assume that the line "Must (re)install this Fix AFTER ... refers to DCOM98 itself? If not, what? And among other things what could have been installed BEFORE that the AFTER refers to can be 269874? [Raising the rev of rpcrt4.dll using 269874 lowers some other aspect of DCOM98?]

And I assume the DCOM98UP.EXE unofficial package is a way to get all of them at once to avoid a reinstall of whatever?

And finally, if the 98SE SP 2.1a is installed AFTER all of the above as a final step, is that good enough to solve whatever the AFTER is referring to?

cjl (trying to wrestle confusion to the ground)