Re: KB867801 Security Update installs(?) every day

"Bill Pfeifer" <BillPfeifer@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:27612B61-CDD8-49BE-9253-629573E4A2CB@xxxxxxxxxxxxxxxx
>
>
> "Robert Aldwinckle" wrote:
>
>> "Bill Pfeifer" <BillPfeifer@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:4AB64A33-0E49-4264-A2E5-5D5EDE718930@xxxxxxxxxxxxx
>> ....
>> > I looked at MS05-020, and its versions of those 6 files matched the ones I
>> > have.
>>
>> The only ideas I have now then are:
>> 1. presumably you found those in System32?
>> 2. where all would WU be looking for them? e.g. perhaps in dllcache too?
>
> I searched for the files, and they are in both System32 and dllcache. The
> versions are the same in those directories.
> All of them are also in:
> C:\WINNT\$NtUninstallKB867282-IE6SP1-20050127.163319$
>
> Browseui.dll Mshtml.dll Shdocvw.dll wininet.dll are also in:
> C:\WINNT\$NtUninstallKB890923-IE6SP1-20050225.103456$
> The versions in those 2 directories are all older than the ones in System32
> and dllcache.
>
>> 3. I'm not familiar with your OS but my understanding is that you can't use WUv5?
>> and I've forgotten all I ever used to know about how WUv4 works. So here is an
>> idea in the form of a WUv5 analogy. If it is just a repeated *install* that is happening
>> I would try deleting the downloaded files which are making the install possible.
>> In XP (e.g. WUv5) you would do that with rd /s %SystemRoot%\SoftwareDistribution\Download
>
> I searched for the folder "SoftwareDistribution" with no result.

Sorry for the confusion. SoftwareDistribution is a WUv5 directory.
I guess this proves my understanding about your OS.
As I wrote, I can't remember where WUv4 downloads to and installs from.
My hazy recollection is that it isn't anywhere as specific so you will either have to
widen the filter, get some better hints from somebody else, or guess and get lucky.
(I would have hoped that the update portion of the FileMon filter would at least snag
an update.exe in operation if there was one of them involved. E.g. I think I mentioned
that the filter I like to use now (for WUv5) is update;SoftwareDistribution which has the
effect of interleaving trace entries of writes to the folder with whatever logging is being
done in WindowsUpdate.log (Windows Update.log in your case.))

Hmm... speaking of getting lucky. Do you have any extra large partitions?
(I mean partitions or drives which contain more freespace other than the System partition.)
I seem to recall that WUv4 tries to download to and install from the partition
which has the most freespace. If that is a rarely used drive you could use
the drive letter (plus the colon) as a useful filter to see if that is where things
are going. Also, of course, if 867801 creates an install log it may contain
some incidental clues about where the files are coming from, which you could
then incorporate into your filter when you need to understand why the install
is repeating, etc.

Are you unsure of whether the update is just being installed or both downloaded
and installed? Could you use the AU Custom Install to do that? E.g. if you set
AU's option to be "Notify me but don't automatically download or install..."
and you get prompted that there are updates ready to be installed you would know
that the update had already been downloaded and was just waiting to be installed
(from somewhere). Only if that turned out to be the source of your loop would it really
be necessary to identify where the files had been downloaded to (e.g. using FileMon.)

BTW I just remembered some of the quirky things that used to happen to me with WUv4
which could be relevant for your case. I normally downloaded and installed updates
using AU's double prompt method. However, occasionally I did see the same
update offered more than once (i.e. I was prompted to download one I had already
installed, even several days later.). In that case what I found I had to do was redownload
and reinstall the update manually using the WU site instead. That AFAIR always shut up
the extraneous prompt.

When you're downloading and installing using WU AFAIR you don't get a chance to stop
at just the download portion (which is annoying IMO because then I feel I have to be more
careful about what I have open while the download is proceeding, e.g. so what is open
doesn't interfere with what needs to be changed, even though that only really matters,
if it matters at all, when the install phase of an update is occurring.)


>
>> 4. I would try monitoring the download/install process with FileMon filtering with:
>> SoftwareDistribution;Update;CatRoot
>> Again this is a WUv5 analogy that would have to be adapted to whatever WUv4 uses
>> instead of the SoftwareDistribution subdirectory. My recollection is that it uses a
>> huge random number (e.g. GUID) which it sticks in the root directory of the volume with
>> the largest available freespace. The second two terms in the filter should have the same
>> effect in WUv4 as they do in WUv5: Update would capture accesses to Windows Upate.log
>> (i.e., instead of WindowsUpdate.log) and CatRoot would capture accesses to both
>> CatRoot and CatRoot2.
>> FWIW I use that monitor to fill in the blanks when looking at my WindowsUpdate.log.
>> From what I recall Windows Update.log in WUv4 was nothing *but* blanks (<eg>)
>> so this FileMon idea may be even more useful in WUv4. Oh, you also have iuhist
>> in WUv4 too, don't you? So I would stick that in the filter too. Etc.
>
> Contrary to what I may have come across, I'm actually pretty dumb when it
> comes
> to the operating system. I did download and run filemon with the filtering
> you
> suggested, but I don't know how to interpret the result.


You're doing fine. ;)

As I mentioned above, you would have to be lucky if this filter found anything really useful
for WUv4. I would expect at least that the update portion would show you when
writes were being done to Windows Update.log and if you added iuhist you would
see any writes being done to that log too. Since you know the name of the update
you are trying to install you could tack on 867801 too. E.g. if a subdirectory is created
called that you would be able to see all the files being added under it. Etc.

Hmm... I just thought of another approach which might work better in this case
instead of filters since we really don't have any clear ideas of any patterns to use.
FileMon has some checkboxes on the bottom which apparently would allow us to focus
only on writes. You could try using an unlimited filter (e.g. an asterisk) with that.
If there were too many writes to things such as the registry, pagefile, etc. you could
use the Exclude filter to specify those and then see if what was left gave a clearer
picture of what was happening. This idea would be most useful for analysing
the download phase but could also help to some extent with the the install phase too.
(E.g. though you would be able to see where the install was coming from
you would be able to see what it did.)


>
>> 5. If KB867801 is being selected for download as well as having an install attempt made
>> I would suspect there is a registry check being done which is causing that (assuming you
>> have clearly ruled out the possibility of a filecheck causing it instead. Notice that we have
>> only been looking at file version as the criteria; if there is minor corruption in other factors
>> which could be checked for too--such as timestamp, size or CRC value--they might still
>> trigger a download based only on a failed file check.) You might be able to detect if a
>> registry check is the cause by using RegMon. The TechNet Security bulletin gives
>> a clue for what to use for a filter (e.g. under Registry Key Verification); I think that I would
>> use Hotfix;867801 in case there is a pattern in checking the other hotfixes which
>> appears broken in the 867801 case.
>
> Pardon my ignorance, but I'm lost here.

Sorry. Ignore my ramble about other possibilities for filecheck and focus on the registry check.
RegMon is another tool from SysInternals which works similar to FileMon.
The filter I suggested for it was Hotfix;867801 based on the information contained in

http://www.microsoft.com/technet/security/bulletin/ms04-025.mspx

(MSN search for
867801
)


Note that you have to expand
[+] Security Update Information
and
[+] Internet Explorer 6 SP1...

to find:

<quote>
You may also be able to verify the files that this security update has installed by reviewing the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{2298d453-bcae-4519-bf33-1cbf3faf1524}
</quote>


Oops. Evidently I was looking at the wrong expansion when I suggested the above filter.
So instead of Hotfix you would need to use something from that information. However,
the 867801 portion of the filter might still allow something relevant to turn up. Etc.


Good luck

Robert
---


>
>> 6. You could try opening an online support case for this. FWIW my only experience
>> using it was disappointing. There seems to be very little of a "diagnose, analyse
>> and tweak" approach to problem solving there, more of "demolish and rebuild"
>> mindset for "fixing". YMMV.
>>
>>
>> BTW thanks for pointing out that KB303215 is no longer available.
>> It looks as if KB320454 contains the same sort of information that
>> I would have been pointing to.
>>
>>
>> >>>>> Our IT department threw in the towel and doesn't know how to resolve this
>> >>>>> issue.
>>
>> I can now see why. <EG>
>>
>>
>> Good luck
>>
>> Robert
>> ---
>>
>>
>>



.

Relevant Pages

  • Re: Windows 2000 Update Installation failure
    ... FileMon filter that I suggested; although parts of it could actually capture ... Did you use the Windows Update site to do a download first? ... Or are you trying to install something that you already have downloaded? ...
    (microsoft.public.windowsupdate)
  • Re: KB867801 Security Update installs(?) every day
    ... Again this is a WUv5 analogy that would have to be adapted to whatever WUv4 uses ... So I would stick that in the filter too. ... If KB867801 is being selected for download as well as having an install attempt made ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • Re: KB867801 Security Update installs(?) every day
    ... and they are in both System32 and dllcache. ... > and I've forgotten all I ever used to know about how WUv4 works. ... So I would stick that in the filter too. ... If KB867801 is being selected for download as well as having an install attempt made ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • Re: Auto Updates not so Auto.
    ... If my settings say download and install at 3am why is this happening. ... That may be a clue for us about your OS? ... aren't using WUv4 so the above troubleshooting info should be relevant. ...
    (microsoft.public.windowsupdate)
  • Re: spyware not working
    ... You cannot really "download from a disc" - you could install. ... Microsoft has these suggestions for Protecting your computer from the ... More full function applications for CD/DVD burning would be: ...
    (microsoft.public.windowsxp.security_admin)