822925 & 828750

  • Thread starter Thread starter Ox
  • Start date Start date
Ox said:
Hi,

I have two machines that I have not been able to sucessfully install
the above mentioned patches. It was suggested that I post to this
group.

Here are two messages posted earlier.

http://groups.google.com/[email protected]
http://groups.google.com/[email protected]

Does anyone have any suggestions?
Click to expand...

<quote>
After applying 828750 all dlls were updated
except URLMON.DLL

And again setupapi.log has mention of it being replaced upon reboot
but it has not.
</quote>

Two possibilities come to mind. Security programs can interfere
with the update and prevent either phase of the update (pre-boot
and during reboot) from completing successfully. It is not sufficient
to just stop your security programs. You must disable them so they
don't restart and interfere during the reboot phase.

The second case is less well understood. Others have discovered
that apparently some of the updates don't work properly if your Profile
files such as History, or Cookies have been moved out of their normal
location. (One of the people who found this factor preferred to keep
History and Cookies in a RAM disk.)

Unfortunately it appears that the poster who reported this must have
done something to suppress his messages from appearing in the
Google Groups archive and it will no longer be available on the msnews
server because of the recent cutback to a 30-day archive. I can only find
it on mine. Here is an excerpt from one of my posts which refers to it:

<excerpt>
Some who have non-standard History or Cookies or TIF apparently
have had a problem getting all the right .dll's until they changed
those folders back to their standard locations. See recent thread
by HiMan for example which concluded that way.

Subject: Re: 822925 Cum IE Patch causes problem with XP built in admin account - solved sort of
Date: Sat, 30 Aug 2003 04:13:59 +0200

The OP used X-No-Archive: yes so the thread is most easily found
using OE Find with the first half of that Subject: going back to
2003-08-25.

BTW I first became aware of the issue from somebody who had to stop
putting his History and Cookies in a RAM disk. I believe that the same
person participated in the thread I just I just referred you to.


FYI

Robert Aldwinckle
 
Robert Aldwinckle said:
<quote>
After applying 828750 all dlls were updated
except URLMON.DLL

And again setupapi.log has mention of it being replaced upon reboot
but it has not.
</quote>

Two possibilities come to mind. Security programs can interfere
with the update and prevent either phase of the update (pre-boot
and during reboot) from completing successfully. It is not sufficient
to just stop your security programs. You must disable them so they
don't restart and interfere during the reboot phase.

The second case is less well understood. Others have discovered
that apparently some of the updates don't work properly if your Profile
files such as History, or Cookies have been moved out of their normal
location. (One of the people who found this factor preferred to keep
History and Cookies in a RAM disk.)

Unfortunately it appears that the poster who reported this must have
done something to suppress his messages from appearing in the
Google Groups archive and it will no longer be available on the msnews
server because of the recent cutback to a 30-day archive. I can only find
it on mine. Here is an excerpt from one of my posts which refers to it:

<excerpt>
Some who have non-standard History or Cookies or TIF apparently
have had a problem getting all the right .dll's until they changed
those folders back to their standard locations. See recent thread
by HiMan for example which concluded that way.

Subject: Re: 822925 Cum IE Patch causes problem with XP built in admin account - solved sort of
Date: Sat, 30 Aug 2003 04:13:59 +0200

The OP used X-No-Archive: yes so the thread is most easily found
using OE Find with the first half of that Subject: going back to
2003-08-25.

BTW I first became aware of the issue from somebody who had to stop
putting his History and Cookies in a RAM disk. I believe that the same
person participated in the thread I just I just referred you to.


FYI

Robert Aldwinckle
Click to expand...

The patches where originally pushed to the pcs with Shavlik HFNetChkLT
using the domain administrator credentials. The pcs use Vet antivirus
as do the ones where the installation worked without a problem.

Since posting the last message I tried installing the patches by using
the local administrator and by putting XP under safe mode.

Again the same result.

While in Safe mode I checked, using Task Manager, that there was no
antivirus software running.

I've just checked the local admin account is using the default
Internet Temp Files, History and the Cookies folders.

Is it possible to force the update to produce a more verbose log? Some
way to find out why the dlls where not updated?

Thanks.

Ox.
 
Is it possible to force the update to produce a more verbose log?
Some way to find out why the dlls where not updated?
Click to expand...

Are you more interested in fixing the discrepancies or
finding out why they occurred?

For the former you could try things such as uninstalling the
problem fixes and checking out the resulting versions of the modules
the problem fix involved, or try reinstalling the problem fixes
from the catalog instead of relying on WU or AU. Etc.

Did your dllcache get updated with the correct versions?
Then maybe even an sfc /scannow would update your System32.
(I notice that setupapi.log doesn't record any changes to dllcache
but the related .inf files do show which ones should occur and
I think you might even be able to infer the order that the copies
would be done in.)

I don't understand the WU implementations. There may be a consistent
pattern to them but I think that they seem to change between products
and from fix to fix. One relevant thing that I noticed (after searching
my harddrive for the string 828750) is that there is an XML file called
item.xml which could have something to do with choosing which version
of module you would regress to if you tried uninstalling that patch;
otherwise I'm not sure how its uninstall would be implemented.


Good luck

Robert
 
Robert Aldwinckle said:
Are you more interested in fixing the discrepancies or
finding out why they occurred?
Click to expand...

Fixing it is more important at the moment but there is a real need to
understand what is going on. The problem is occurring on two machines
and more may start in the future. Understanding why this is happening
may help prevent it in the future or atleast overcome the problem.
For the former you could try things such as uninstalling the
problem fixes and checking out the resulting versions of the modules
the problem fix involved, or try reinstalling the problem fixes
from the catalog instead of relying on WU or AU. Etc.
Click to expand...

I've just reinstalled the patch by downloading 828750 from the Catalog
and running it while in safe mode. That did not fix it.

I'll try the uninstall approach later today.
Did your dllcache get updated with the correct versions?
Then maybe even an sfc /scannow would update your System32.
(I notice that setupapi.log doesn't record any changes to dllcache
but the related .inf files do show which ones should occur and
I think you might even be able to infer the order that the copies
would be done in.)
Click to expand...

with urlmon.dll for example, I've found copies in

\windows\$ntservicepackuninstall$ 442kb 18/08/2001
\windows\ServicePackFiles\i386 445kb 29/08/2002
\windows\system32 473kb 14/04/2003
\windows\LastGood.Tmp\System32 473kb 14/04/2003
\windows\system32\dllcache 435kb 10/09/2003
\windows\LastGood.Tmp\System32\dllcache 435kb 10/09/2003

the last two are the correct files for 828750

I'm not familiar with sfc. I'll check it out.

I've checked the setupapi.log of machines where the patch was
installed successfully and it doesn't record changes to dllcache.

Ox.
 
I have exactly the same problems with 822925 and 828750. Until
yesterday 822925 kept reappearing and reappearing. It always says that
the installation was successful. Today I installed the roll-up pack 1
and suddenly 822925 is not offered anymore but now it is 828750.

In the about box of my IE it says: update version; SP1; Q818529;
Q330994;.

Like some other users I also moved some of the Windows standard
directories to other directories.
I moved C:\Program Files to the root of D:\ . Maybe that is causing
the problems. But I don't want to have my program files on C:\ and I
definitely won't move them to C:\ just because Microsoft is to stupid
to implement a working update function.

Regards,
(e-mail address removed)
 
Fixing it is more important at the moment but there is a real need to
understand what is going on. The problem is occurring on two machines
and more may start in the future. Understanding why this is happening
may help prevent it in the future or atleast overcome the problem.


I've just reinstalled the patch by downloading 828750 from the Catalog
and running it while in safe mode. That did not fix it.

I'll try the uninstall approach later today.
Click to expand...

Alas uninstalling it didnt work. Yesterday, I rolled out another set
of patches, using HFNetChkPro, and among them was 828750 since it
detected it not having installed correctly. When I checked later they
had all installed successfully. I double checked the dlls and yes they
were installed correctly on both pcs.

The other patches were

828035 (MS03-043)
825119 (MS03-044)
823182 (MS03-041)
824141 (MS03-045)

Cheers,

Ox.
 
Back
Top