Infamous "svchost" Automatic Updates horrors continue

I've been plagued by the automatic updates problems on a portion of my 400+
Windows XP/2000 systems since July, 2006 - and not the same systems, month
to month, either. The October MSI.DLL update (KB916089) seemed like it fix
it, but since there is apparently no way to know from monthly patch day to
monthly patch day what computer is going to have problems updating itself,
I can't say for sure. Subsequently, I installed the January MSI.DLL update
(KB927891) on those systems, since it supercedes the prior MSI.DLL hotfix.

Well, I am now not getting the svchost application errors, BUT automatic
updates, or even manual Windows/Microsoft Updates, is causing near 100% CPU
utilization for, well... on my own laptop (1200MHz Pentium M), which has
yet to have had this updates problem thus far, got hit this month (April
2007). The rogue svchost.exe process used 14 minutes of CPU time just to
show me what updates I had ready to install. Of course, during that time,
basically Windows was useless, clicking any application would take anywhere
from 20 seconds to a couple minutes to launch, so I just had to sit it down
and walk away from throw it against the wall. I'm actually even surprised
it eventually did figure itself out, I'd have never guessed it would have
taken 14 minutes for something that normally should only take about 1
minute, at most 2 minutes.

Yes, yes, I've done all the re-registering wua*.dll files, deleting the
%windir%\system32\catroot2 folder, re-installing Windows Installer 3.1 to
let catroot2 re-create itself, and whatnot, and my laptop has the KB927891
MSI.DLL hotfix and I ** STILL ** got hit again by this Microsoft updating
nightmare on a computer that had never had this happen before now, even
though it has been a known issue for going on a year across the large
number of computers I support.

Obviously, this is a problem Microsoft has lost control of and they don't
know what the root cause is. Sure, the application crashing appears to have
been fixed with the January MSI.DLL hotfix, but not the underlying cause
for the 100% CPU utilization and abnormally long updates processing
problem.

The problem persists if you change the default update source from Microsoft
Update to Windows Update?

[Go to Microsoft Update > Click on Change Settings in left pane > Scroll to
bottom of page > To Stop Using Microsoft Update > Disable Microsoft Update
software and let me use Windows Update only (check).]

Try deleting the contents of this folder (or the folder itself) & reboot:

C:\WINDOWS\SoftwareDistribution\DataStore

If no joy, try deleting the contents of this folder (or the folder itself) &
reboot:

C:\WINDOWS\SoftwareDistribution
--
~Robear Dyer (PA Bear)
MS MVP-Windows (IE, OE, Security, Shell/User)
AumHa VSOP & Admin; DTS-L.org


CogX wrote:
> I've been plagued by the automatic updates problems on a portion of my
> 400+
> Windows XP/2000 systems since July, 2006 - and not the same systems, month
> to month, either. The October MSI.DLL update (KB916089) seemed like it
> fix
> it, but since there is apparently no way to know from monthly patch day to
> monthly patch day what computer is going to have problems updating itself,
> I can't say for sure. Subsequently, I installed the January MSI.DLL
> update
> (KB927891) on those systems, since it supercedes the prior MSI.DLL hotfix.
>
> Well, I am now not getting the svchost application errors, BUT automatic
> updates, or even manual Windows/Microsoft Updates, is causing near 100%
> CPU
> utilization for, well... on my own laptop (1200MHz Pentium M), which has
> yet to have had this updates problem thus far, got hit this month (April
> 2007). The rogue svchost.exe process used 14 minutes of CPU time just to
> show me what updates I had ready to install. Of course, during that time,
> basically Windows was useless, clicking any application would take
> anywhere
> from 20 seconds to a couple minutes to launch, so I just had to sit it
> down
> and walk away from throw it against the wall. I'm actually even surprised
> it eventually did figure itself out, I'd have never guessed it would have
> taken 14 minutes for something that normally should only take about 1
> minute, at most 2 minutes.
>
> Yes, yes, I've done all the re-registering wua*.dll files, deleting the
> %windir%\system32\catroot2 folder, re-installing Windows Installer 3.1 to
> let catroot2 re-create itself, and whatnot, and my laptop has the KB927891
> MSI.DLL hotfix and I ** STILL ** got hit again by this Microsoft updating
> nightmare on a computer that had never had this happen before now, even
> though it has been a known issue for going on a year across the large
> number of computers I support.
>
> Obviously, this is a problem Microsoft has lost control of and they don't
> know what the root cause is. Sure, the application crashing appears to
> have
> been fixed with the January MSI.DLL hotfix, but not the underlying cause
> for the 100% CPU utilization and abnormally long updates processing
> problem.

One note on deleting DataStore ... *sometimes*, deleting the
DataStor.edb file will provide a temp resolution when the size or
integrity of the file is out of whack.
Doing so *will* also delete the history of updating that is viewed on
the WU or MU site.

To mitigate the size/integrity issue of the contents of
SoftwareDistribution it is suggested that this folder by excluded from
scans by the installed AV. As of today, there is no known malware that
has used it as an attack vector.


MowGreen [MVP 2003-2007]
===============
*-343-* FDNY
Never Forgotten
===============



PA Bear wrote:

> The problem persists if you change the default update source from
> Microsoft Update to Windows Update?
>
> [Go to Microsoft Update > Click on Change Settings in left pane > Scroll
> to bottom of page > To Stop Using Microsoft Update > Disable Microsoft
> Update software and let me use Windows Update only (check).]
>
> Try deleting the contents of this folder (or the folder itself) & reboot:
>
> C:\WINDOWS\SoftwareDistribution\DataStore
>
> If no joy, try deleting the contents of this folder (or the folder
> itself) & reboot:
>
> C:\WINDOWS\SoftwareDistribution

Hi Mow, I'm gonna try excluding that folder from the regular scans of Trend.
I've had a few problems with corruption ever since about January. As that is
about the time I installed Trend, it may be worth excluding that folder from
the scans just to see if it makes a difference. Trend seems to go off on it's
own little merry way regardless of what I try to tell it. LOL.

K

"MowGreen [MVP]" wrote:
> To mitigate the size/integrity issue of the contents of
> SoftwareDistribution it is suggested that this folder by excluded from
> scans by the installed AV. As of today, there is no known malware that
> has used it as an attack vector.
>
>

You run AV scans? <eg>

TaurArian wrote:
> Hi Mow, I'm gonna try excluding that folder from the regular scans of
> Trend.
> I've had a few problems with corruption ever since about January. As that
> is
> about the time I installed Trend, it may be worth excluding that folder
> from
> the scans just to see if it makes a difference. Trend seems to go off on
> it's own little merry way regardless of what I try to tell it. LOL.
>
> K
>
> "MowGreen [MVP]" wrote:
>> To mitigate the size/integrity issue of the contents of
>> SoftwareDistribution it is suggested that this folder by excluded from
>> scans by the installed AV. As of today, there is no known malware that
>> has used it as an attack vector.

Not me, I forget, AV does it (it never forgets!)
Really quite annoying sometimes when it just pops up while you're reading
something then it does it's own thing then disappears. (Must figure out how
to program it not to pop up - perhaps I'll read the instructions, nah - I'll
just play with it until I break it)
<laughing>
K

"PA Bear" wrote:

> You run AV scans? <eg>
>
>

Trend doesn't have an exclusion area that I can find anyway.
K

--

====================================
TaurArian [MS-MVP] 2005-2007 - Australia
====================================
How to make a good post: http://www.dts-l.org/goodpost.htm
Backup and data recovery: http://www.acronis.com.sg/
Enhancing file system performance: http://www.diskeeper.com/defrag.asp


"TaurArian" <> wrote in message
news:C8C2375A-9D82-4C9C-8FFE-...
| Hi Mow, I'm gonna try excluding that folder from the regular scans of Trend.
| I've had a few problems with corruption ever since about January. As that is
| about the time I installed Trend, it may be worth excluding that folder from
| the scans just to see if it makes a difference. Trend seems to go off on it's
| own little merry way regardless of what I try to tell it. LOL.
|
| K
|
| "MowGreen [MVP]" wrote:
| > To mitigate the size/integrity issue of the contents of
| > SoftwareDistribution it is suggested that this folder by excluded from
| > scans by the installed AV. As of today, there is no known malware that
| > has used it as an attack vector.
| >
| >

Is this PC-cillin Internet Security or just a standalone AV ?
If it's the 'security suite' then suggest you disable the firewall and
switch back to the native Windows firewall. I found that the Trend
firewall was finicky, at best.

MG

TaurArian [MS-MVP] wrote:

> Trend doesn't have an exclusion area that I can find anyway.
> K
>

I found that I had a svchost running at 99% I tracked it down to automatic
updates set to automatic. When I turned off auto update the computer came
back. How can we fix this problem? Also I noticed that when I went to
microsoft update and asked it to scan for updates the svchost at 99% cpu
usage came back and it never finishes the scan. I was able to end tree and
get the computer back. Hope someone can help. Kelly

"CogX" wrote:

> I've been plagued by the automatic updates problems on a portion of my 400+
> Windows XP/2000 systems since July, 2006 - and not the same systems, month
> to month, either. The October MSI.DLL update (KB916089) seemed like it fix
> it, but since there is apparently no way to know from monthly patch day to
> monthly patch day what computer is going to have problems updating itself,
> I can't say for sure. Subsequently, I installed the January MSI.DLL update
> (KB927891) on those systems, since it supercedes the prior MSI.DLL hotfix.
>
> Well, I am now not getting the svchost application errors, BUT automatic
> updates, or even manual Windows/Microsoft Updates, is causing near 100% CPU
> utilization for, well... on my own laptop (1200MHz Pentium M), which has
> yet to have had this updates problem thus far, got hit this month (April
> 2007). The rogue svchost.exe process used 14 minutes of CPU time just to
> show me what updates I had ready to install. Of course, during that time,
> basically Windows was useless, clicking any application would take anywhere
> from 20 seconds to a couple minutes to launch, so I just had to sit it down
> and walk away from throw it against the wall. I'm actually even surprised
> it eventually did figure itself out, I'd have never guessed it would have
> taken 14 minutes for something that normally should only take about 1
> minute, at most 2 minutes.
>
> Yes, yes, I've done all the re-registering wua*.dll files, deleting the
> %windir%\system32\catroot2 folder, re-installing Windows Installer 3.1 to
> let catroot2 re-create itself, and whatnot, and my laptop has the KB927891
> MSI.DLL hotfix and I ** STILL ** got hit again by this Microsoft updating
> nightmare on a computer that had never had this happen before now, even
> though it has been a known issue for going on a year across the large
> number of computers I support.
>
> Obviously, this is a problem Microsoft has lost control of and they don't
> know what the root cause is. Sure, the application crashing appears to have
> been fixed with the January MSI.DLL hotfix, but not the underlying cause
> for the 100% CPU utilization and abnormally long updates processing
> problem.
>
>
>
>
>

[psst! click on the + to see replies!]

Kelly wrote:
> I found that I had a svchost running at 99% I tracked it down to automatic
> updates set to automatic. When I turned off auto update the computer came
> back. How can we fix this problem? Also I noticed that when I went to
> microsoft update and asked it to scan for updates the svchost at 99% cpu
> usage came back and it never finishes the scan. I was able to end tree and
> get the computer back. Hope someone can help. Kelly
>
> "CogX" wrote:
>
>> I've been plagued by the automatic updates problems on a portion of my
>> 400+
>> Windows XP/2000 systems since July, 2006 - and not the same systems,
>> month
>> to month, either. The October MSI.DLL update (KB916089) seemed like it
>> fix
>> it, but since there is apparently no way to know from monthly patch day
>> to
>> monthly patch day what computer is going to have problems updating
>> itself,
>> I can't say for sure. Subsequently, I installed the January MSI.DLL
>> update
>> (KB927891) on those systems, since it supercedes the prior MSI.DLL
>> hotfix.
>>
>> Well, I am now not getting the svchost application errors, BUT automatic
>> updates, or even manual Windows/Microsoft Updates, is causing near 100%
>> CPU
>> utilization for, well... on my own laptop (1200MHz Pentium M), which has
>> yet to have had this updates problem thus far, got hit this month (April
>> 2007). The rogue svchost.exe process used 14 minutes of CPU time just to
>> show me what updates I had ready to install. Of course, during that
>> time,
>> basically Windows was useless, clicking any application would take
>> anywhere
>> from 20 seconds to a couple minutes to launch, so I just had to sit it
>> down
>> and walk away from throw it against the wall. I'm actually even
>> surprised
>> it eventually did figure itself out, I'd have never guessed it would have
>> taken 14 minutes for something that normally should only take about 1
>> minute, at most 2 minutes.
>>
>> Yes, yes, I've done all the re-registering wua*.dll files, deleting the
>> %windir%\system32\catroot2 folder, re-installing Windows Installer 3.1 to
>> let catroot2 re-create itself, and whatnot, and my laptop has the
>> KB927891
>> MSI.DLL hotfix and I ** STILL ** got hit again by this Microsoft updating
>> nightmare on a computer that had never had this happen before now, even
>> though it has been a known issue for going on a year across the large
>> number of computers I support.
>>
>> Obviously, this is a problem Microsoft has lost control of and they don't
>> know what the root cause is. Sure, the application crashing appears to
>> have
>> been fixed with the January MSI.DLL hotfix, but not the underlying cause
>> for the 100% CPU utilization and abnormally long updates processing
>> problem.