Re: Svchost process at 99% CPU Utilisation

DJT wrote:
> I have an old computer with an AMD Althon chip which I use for backup.
> I run at least once a week to keep it updated.
> I started it yesterday and a windows update was found, but since I
> started the download of the update the CPU utilisation has been 100%
> solid, no variation. The only thing that changes is the split of what
> process if using the CPU.
>
> Svchost is continually using 96 - 99 % and has been for over 24 hours.
> The download is only at 78 % after running for 24 hrs.
> During this time the internet connection shows barely any use at any
> time and certainly is not saturated.
>
> I have had the situation before when downloading updates but only for
> a maximum of 20 Min, not for over 24 hrs.
>
> I am not able to determine what actual update is being done.
>
> I originally thought that it could be sp3? but the amount of data is
> negligible
>
> Any idea whay svchost should tie up tyhe CPU for so long
>
>
> DJT

[You may ignore PA Bear, he screams malware no matter what the question is]

Windows Updates are downloaded by the BITS service which runs in one of
the systems svchost.exe instances. Windows Update itself runs in
another instance of svchost.exe. So if anything in Windows Update
itself is using too much CPU to be useable, Task Manager will show that
CPU waste as happening in svchost.exe .

When Windows Update gets stupid about its download handling, I usually
solve it like this (This procedure cleans out half-downloaded updates
and old long-ago-installed updates, plus the internal state of Windows
Update):

1. Reboot
2. Open a "Command Prompt window"
3. NET STOP wuauserv
4. NET STOP BITS
5. CD /D %SystemRoot%
6. DIR \
7. (Note if the disk was almost full)
8. CD SoftwareDistribution
9. rd /s Download
10. Y
11. rd /s DataStore
12. Y
13. DIR \
14. (STOP if the disk is still almost full)
15. NET START wuauserv
16. Try again


--
Jakob Bøhm, M.Sc.Eng. * * direct tel:+45-45-90-25-33
Netop Solutions A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right.
Information in this posting may not be the official position of Netop
Solutions A/S, only the personal opinions of the author.

It is not unusual to see spikes in CPU when Automatic Updates is doing it's
thing but anything other than a temporary (e.g., 5-10 minutes) spike most
likely is NOT related to AU.

Continued & repeated spikes in CPU is most often associated with hijackware
so it only makes sense to rule it out.
--
~Robear Dyer (PA Bear)
MS MVP-IE, Mail, Security, Windows Client - since 2002


Jakob Bohm wrote:
> DJT wrote:
>> I have an old computer with an AMD Althon chip which I use for backup.
>> I run at least once a week to keep it updated.
>> I started it yesterday and a windows update was found, but since I
>> started the download of the update the CPU utilisation has been 100%
>> solid, no variation. The only thing that changes is the split of what
>> process if using the CPU.
>>
>> Svchost is continually using 96 - 99 % and has been for over 24 hours.
>> The download is only at 78 % after running for 24 hrs.
>> During this time the internet connection shows barely any use at any
>> time and certainly is not saturated.
>>
>> I have had the situation before when downloading updates but only for
>> a maximum of 20 Min, not for over 24 hrs.
>>
>> I am not able to determine what actual update is being done.
>>
>> I originally thought that it could be sp3? but the amount of data is
>> negligible
>>
>> Any idea whay svchost should tie up tyhe CPU for so long
>>
>>
>> DJT
>
> [You may ignore PA Bear, he screams malware no matter what the question
> is]
>
> Windows Updates are downloaded by the BITS service which runs in one of
> the systems svchost.exe instances. Windows Update itself runs in
> another instance of svchost.exe. So if anything in Windows Update
> itself is using too much CPU to be useable, Task Manager will show that
> CPU waste as happening in svchost.exe .
>
> When Windows Update gets stupid about its download handling, I usually
> solve it like this (This procedure cleans out half-downloaded updates
> and old long-ago-installed updates, plus the internal state of Windows
> Update):
>
> 1. Reboot
> 2. Open a "Command Prompt window"
> 3. NET STOP wuauserv
> 4. NET STOP BITS
> 5. CD /D %SystemRoot%
> 6. DIR \
> 7. (Note if the disk was almost full)
> 8. CD SoftwareDistribution
> 9. rd /s Download
> 10. Y
> 11. rd /s DataStore
> 12. Y
> 13. DIR \
> 14. (STOP if the disk is still almost full)
> 15. NET START wuauserv
> 16. Try again

Jakob Bohm wrote:


> [You may ignore PA Bear, he screams malware no matter what the question is]
>
> Windows Updates are downloaded by the BITS service which runs in one of
> the systems svchost.exe instances. Windows Update itself runs in
> another instance of svchost.exe. So if anything in Windows Update
> itself is using too much CPU to be useable, Task Manager will show that
> CPU waste as happening in svchost.exe .
>
> When Windows Update gets stupid about its download handling, I usually
> solve it like this (This procedure cleans out half-downloaded updates
> and old long-ago-installed updates, plus the internal state of Windows
> Update):
>
> 1. Reboot
> 2. Open a "Command Prompt window"
> 3. NET STOP wuauserv
> 4. NET STOP BITS
> 5. CD /D %SystemRoot%
> 6. DIR \
> 7. (Note if the disk was almost full)
> 8. CD SoftwareDistribution
> 9. rd /s Download
> 10. Y
> 11. rd /s DataStore
> 12. Y
> 13. DIR \
> 14. (STOP if the disk is still almost full)
> 15. NET START wuauserv
> 16. Try again
>
>

Each time the SoftwareDistribution subfolders are deleted they are
recreated when the update service starts. Said update service is
started on boot by it's Default setting, no matter which options one
chooses for Automatic or Windows Update's settings.

If there is 3rd party software [security software] installed that is
monitoring system files, then one will see a slight spike in CPU usage
by svchost when the subfolders of SD are recreated.

When the update database located in DataStore is scanned or monitored
[DataStore.edb] there will be a spike in CPU usage due to it being in
use [ locked ].
This spike will become more noticeable over time as DataStore.edb can
become either corrupted or irreparrably damaged.
To mitigate this issue, see:

Virus scanning recommendations for computers that are running Windows
Server 2008, Windows Server 2003, Windows 2000, Windows XP, or Windows Vista
http://support.microsoft.com/kb/822158

On a system that has had subfolders of the SoftwareDistrbution directory
deleted and *if the CPU cycles stays at 99%*, then the logical
conclusion is that 3rd party software is hindering the OS from
recreating said subfolders, and/or there is an issue with the detection
logic, and/or there is an issue with the Windows Installer associated
..dll file, .msi.dll.
The latter two issues have been mitigated in the latest releases of the
Windows Update Agent.

" Old long ago updates " are flushed from the Download subfolder of SD
on a regular cycle IF the automatic update components are functioning
properly and are not being hindered from carrying out their operations
by 3rd party software.

Said 3rd party software will either be security software or malware.
Since the *vast majority of issues* posted to this newsgroup *are*
directly related to the presence of malware, then it's not illogical to
conclude that malware is present on systems where the CPU cycle issue is
present.

Conclusion: Ignore Jakob Bohm since he's unaware that malware can cause
the CPU utilization issue or that security software should be configured
to not scan nor monitor DataStore.edb


MowGreen
===============
*-343-* FDNY
Never Forgotten
===============

MowGreen wrote:
> Jakob Bohm wrote:
>
>
>> [You may ignore PA Bear, he screams malware no matter what the
>> question is]
>>
>> Windows Updates are downloaded by the BITS service which runs in one of
>> the systems svchost.exe instances. Windows Update itself runs in
>> another instance of svchost.exe. So if anything in Windows Update
>> itself is using too much CPU to be useable, Task Manager will show that
>> CPU waste as happening in svchost.exe .
>>
>> When Windows Update gets stupid about its download handling, I usually
>> solve it like this (This procedure cleans out half-downloaded updates
>> and old long-ago-installed updates, plus the internal state of Windows
>> Update):
>>
>> 1. Reboot
>> 2. Open a "Command Prompt window"
>> 3. NET STOP wuauserv
>> 4. NET STOP BITS
>> 5. CD /D %SystemRoot%
>> 6. DIR \
>> 7. (Note if the disk was almost full)
>> 8. CD SoftwareDistribution
>> 9. rd /s Download
>> 10. Y
>> 11. rd /s DataStore
>> 12. Y
>> 13. DIR \
>> 14. (STOP if the disk is still almost full)
>> 15. NET START wuauserv
>> 16. Try again
>>
>>
>
> Each time the SoftwareDistribution subfolders are deleted they are
> recreated when the update service starts. Said update service is started
> on boot by it's Default setting, no matter which options one chooses for
> Automatic or Windows Update's settings.
>
Yes, I know that and the procedure above assumes that.

> If there is 3rd party software [security software] installed that is
> monitoring system files, then one will see a slight spike in CPU usage
> by svchost when the subfolders of SD are recreated.
>
Two other sources of spikes which I have seen over the years:

1. If the DataStore has become corrupted by a random event, the code
that manages it can spend a lot of CPU cycles spinning its wheels for
little or no gain. Clearing out the database and starting over gets you
a clean uncorrupted database in a few minutes.

2. The delta-download mechanism used by Windows Update to avoid
downloading the parts of an update already on your system sometimes
spends more time computing differences than it saves in download time.
Clearing out the download folder and starting over forces a clean
download without so much work.

> When the update database located in DataStore is scanned or monitored
> [DataStore.edb] there will be a spike in CPU usage due to it being in
> use [ locked ].

Whenever the DataStore is being processed to figure out what updates are
needed on your computer there will be a spike of a few minutes, with or
without a broken AV-scanner slowing things down further.

Additional CPU time wasted by AV scanners may be attributed to the
process that is being slowed down (svchost in the case of WU/AU) or the
scanners own processes depending on the scanner product. Most AV
scanners use an architecture where the actual scanning CPU load occurs
in a dedicated scanning process easily recognized in task manager.

> This spike will become more noticeable over time as DataStore.edb can
> become either corrupted or irreparrably damaged.

Now you are really confusing the issues: There is extra CPU waste due to
the scanner itself repeatedly scanning the database file, this does not
involve corruption or damage to the file (unless the AV product is
incompetent enough to corrupt any file being scanned while in use). And
then there is CPU waste due to a corrupted or damaged database for which
the quickest cure is to clear out the database and start over with a
fresh WU/MU/AU run.

> To mitigate this issue, see:
>
> Virus scanning recommendations for computers that are running Windows
> Server 2008, Windows Server 2003, Windows 2000, Windows XP, or Windows
> Vista
> http://support.microsoft.com/kb/822158

Hilarious article written by someone who see bugs in some AV products
(corruption of binary files that are being changed by their application
while the AV product tries to scan them), assume they apply to all AV
products, and then go on to recommend a bad partial workaround (exclude
the handful of files most important to their personal pet software) as
a general and complete solution.

>
> On a system that has had subfolders of the SoftwareDistrbution directory
> deleted and *if the CPU cycles stays at 99%*, then the logical
> conclusion is that 3rd party software is hindering the OS from
> recreating said subfolders, and/or there is an issue with the detection
> logic, and/or there is an issue with the Windows Installer associated
> .dll file, .msi.dll.

The OP was about a computer where the subfolders had not been deleted
(before applying my advice) and thus it cannot be concluded that the
slowdown is due to software interfering with WU now. Performing my
clean out procedure once, will either eliminate old corruption or
definitively show that something is continuing to interfere. You and PA
Bear blindly assume the latter possibility even when there is lots of
evidence pointing to the other one (In this case: Slow old machine,
machine generally up to date on older updates, machine not used for
general Internet access or other high risk activities, CPU usage in the
exact processes associated with a corrupted SoftwareDistribution folder).

> The latter two issues have been mitigated in the latest releases of the
> Windows Update Agent.
In which case starting over with a clean database would reap the
benefits of this improvement.

>
> " Old long ago updates " are flushed from the Download subfolder of SD
> on a regular cycle IF the automatic update components are functioning
> properly and are not being hindered from carrying out their operations
> by 3rd party software.

Unfortunately, this does not match my own experience. At least until
recently, WU was a real disk space hog, constantly eating additional
disk space every month and not listing its own temporary files in the
Disk Cleanup wizard. Because disk full on the Windows drive is a really
bad situation to be in I have made a habit out of culling excess files
from WU on a regular basis.

>
> Said 3rd party software will either be security software or malware.
> Since the *vast majority of issues* posted to this newsgroup *are*
> directly related to the presence of malware, then it's not illogical to
> conclude that malware is present on systems where the CPU cycle issue is
> present.
>

So you assume the worst, ignore all innocent explanations, then go on to
call the fire department every time you see smoke, even if it is coming
out the top of a chimney.

> Conclusion: Ignore Jakob Bohm since he's unaware that malware can cause
> the CPU utilization issue or that security software should be configured
> to not scan nor monitor DataStore.edb
>

THAT is an insult. I KNOW that malware can do all kinds of bad things,
including eat lots of CPU in strange situations. I strongly disagree
that *all* brands of security software need to specifically exclude
Windows Update files from scanning. But I also KNOW that not all
computer problems are from malware and that telling everyone to panic
and ignoring all non-malicious explanations is not helpful.

In this case the symptoms clearly matched a known problem for which
there is a quick and harmless cure. So that cure should be tried before
starting panic measures to combat an infection that might not be there.

If after cleaning out the dynamic part of the SoftwareDistribution
folder the problem immediately recurs, the next step would be to turn
off automatic updates, clean out again, then use interactive WU/MU to
see the name of the affected update. Then manually download and install
that update from Microsoft downloads and try again. If the problem is
still there after bypassing WU/MU for the directly affected update, THEN
there is something fundamentally wrong and checking for malware would be
a relevant thing to do.

--
Jakob Bøhm, M.Sc.Eng. * * direct tel:+45-45-90-25-33
Netop Solutions A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right.
Information in this posting may not be the official position of Netop
Solutions A/S, only the personal opinions of the author.

You nedd to instal KB927891....This will fix it.

"Jakob Bohm" wrote:

> MowGreen wrote:
> > Jakob Bohm wrote:
> >
> >
> >> [You may ignore PA Bear, he screams malware no matter what the
> >> question is]
> >>
> >> Windows Updates are downloaded by the BITS service which runs in one of
> >> the systems svchost.exe instances. Windows Update itself runs in
> >> another instance of svchost.exe. So if anything in Windows Update
> >> itself is using too much CPU to be useable, Task Manager will show that
> >> CPU waste as happening in svchost.exe .
> >>
> >> When Windows Update gets stupid about its download handling, I usually
> >> solve it like this (This procedure cleans out half-downloaded updates
> >> and old long-ago-installed updates, plus the internal state of Windows
> >> Update):
> >>
> >> 1. Reboot
> >> 2. Open a "Command Prompt window"
> >> 3. NET STOP wuauserv
> >> 4. NET STOP BITS
> >> 5. CD /D %SystemRoot%
> >> 6. DIR \
> >> 7. (Note if the disk was almost full)
> >> 8. CD SoftwareDistribution
> >> 9. rd /s Download
> >> 10. Y
> >> 11. rd /s DataStore
> >> 12. Y
> >> 13. DIR \
> >> 14. (STOP if the disk is still almost full)
> >> 15. NET START wuauserv
> >> 16. Try again
> >>
> >>
> >
> > Each time the SoftwareDistribution subfolders are deleted they are
> > recreated when the update service starts. Said update service is started
> > on boot by it's Default setting, no matter which options one chooses for
> > Automatic or Windows Update's settings.
> >
> Yes, I know that and the procedure above assumes that.
>
> > If there is 3rd party software [security software] installed that is
> > monitoring system files, then one will see a slight spike in CPU usage
> > by svchost when the subfolders of SD are recreated.
> >
> Two other sources of spikes which I have seen over the years:
>
> 1. If the DataStore has become corrupted by a random event, the code
> that manages it can spend a lot of CPU cycles spinning its wheels for
> little or no gain. Clearing out the database and starting over gets you
> a clean uncorrupted database in a few minutes.
>
> 2. The delta-download mechanism used by Windows Update to avoid
> downloading the parts of an update already on your system sometimes
> spends more time computing differences than it saves in download time.
> Clearing out the download folder and starting over forces a clean
> download without so much work.
>
> > When the update database located in DataStore is scanned or monitored
> > [DataStore.edb] there will be a spike in CPU usage due to it being in
> > use [ locked ].
>
> Whenever the DataStore is being processed to figure out what updates are
> needed on your computer there will be a spike of a few minutes, with or
> without a broken AV-scanner slowing things down further.
>
> Additional CPU time wasted by AV scanners may be attributed to the
> process that is being slowed down (svchost in the case of WU/AU) or the
> scanners own processes depending on the scanner product. Most AV
> scanners use an architecture where the actual scanning CPU load occurs
> in a dedicated scanning process easily recognized in task manager.
>
> > This spike will become more noticeable over time as DataStore.edb can
> > become either corrupted or irreparrably damaged.
>
> Now you are really confusing the issues: There is extra CPU waste due to
> the scanner itself repeatedly scanning the database file, this does not
> involve corruption or damage to the file (unless the AV product is
> incompetent enough to corrupt any file being scanned while in use). And
> then there is CPU waste due to a corrupted or damaged database for which
> the quickest cure is to clear out the database and start over with a
> fresh WU/MU/AU run.
>
> > To mitigate this issue, see:
> >
> > Virus scanning recommendations for computers that are running Windows
> > Server 2008, Windows Server 2003, Windows 2000, Windows XP, or Windows
> > Vista
> > http://support.microsoft.com/kb/822158
>
> Hilarious article written by someone who see bugs in some AV products
> (corruption of binary files that are being changed by their application
> while the AV product tries to scan them), assume they apply to all AV
> products, and then go on to recommend a bad partial workaround (exclude
> the handful of files most important to their personal pet software) as
> a general and complete solution.
>
> >
> > On a system that has had subfolders of the SoftwareDistrbution directory
> > deleted and *if the CPU cycles stays at 99%*, then the logical
> > conclusion is that 3rd party software is hindering the OS from
> > recreating said subfolders, and/or there is an issue with the detection
> > logic, and/or there is an issue with the Windows Installer associated
> > .dll file, .msi.dll.
>
> The OP was about a computer where the subfolders had not been deleted
> (before applying my advice) and thus it cannot be concluded that the
> slowdown is due to software interfering with WU now. Performing my
> clean out procedure once, will either eliminate old corruption or
> definitively show that something is continuing to interfere. You and PA
> Bear blindly assume the latter possibility even when there is lots of
> evidence pointing to the other one (In this case: Slow old machine,
> machine generally up to date on older updates, machine not used for
> general Internet access or other high risk activities, CPU usage in the
> exact processes associated with a corrupted SoftwareDistribution folder).
>
> > The latter two issues have been mitigated in the latest releases of the
> > Windows Update Agent.
> In which case starting over with a clean database would reap the
> benefits of this improvement.
>
> >
> > " Old long ago updates " are flushed from the Download subfolder of SD
> > on a regular cycle IF the automatic update components are functioning
> > properly and are not being hindered from carrying out their operations
> > by 3rd party software.
>
> Unfortunately, this does not match my own experience. At least until
> recently, WU was a real disk space hog, constantly eating additional
> disk space every month and not listing its own temporary files in the
> Disk Cleanup wizard. Because disk full on the Windows drive is a really
> bad situation to be in I have made a habit out of culling excess files
> from WU on a regular basis.
>
> >
> > Said 3rd party software will either be security software or malware.
> > Since the *vast majority of issues* posted to this newsgroup *are*
> > directly related to the presence of malware, then it's not illogical to
> > conclude that malware is present on systems where the CPU cycle issue is
> > present.
> >
>
> So you assume the worst, ignore all innocent explanations, then go on to
> call the fire department every time you see smoke, even if it is coming
> out the top of a chimney.
>
> > Conclusion: Ignore Jakob Bohm since he's unaware that malware can cause
> > the CPU utilization issue or that security software should be configured
> > to not scan nor monitor DataStore.edb
> >
>
> THAT is an insult. I KNOW that malware can do all kinds of bad things,
> including eat lots of CPU in strange situations. I strongly disagree
> that *all* brands of security software need to specifically exclude
> Windows Update files from scanning. But I also KNOW that not all
> computer problems are from malware and that telling everyone to panic
> and ignoring all non-malicious explanations is not helpful.
>
> In this case the symptoms clearly matched a known problem for which
> there is a quick and harmless cure. So that cure should be tried before
> starting panic measures to combat an infection that might not be there.
>
> If after cleaning out the dynamic part of the SoftwareDistribution
> folder the problem immediately recurs, the next step would be to turn
> off automatic updates, clean out again, then use interactive WU/MU to
> see the name of the affected update. Then manually download and install
> that update from Microsoft downloads and try again. If the problem is
> still there after bypassing WU/MU for the directly affected update, THEN
> there is something fundamentally wrong and checking for malware would be
> a relevant thing to do.
>
> --
> Jakob Bøhm, M.Sc.Eng. * * direct tel:+45-45-90-25-33
> Netop Solutions A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
> http://www.netop.com * tel:+45-45-90-25-25 * fax:+45-45-90-25-26
> Information in this mail is hasty, not binding and may not be right.
> Information in this posting may not be the official position of Netop
> Solutions A/S, only the personal opinions of the author.
>
>

"Release Date: June 26, 2007"

If the machine needs KB927891, you've got way bigger problems, my friend!!

Vinny V wrote:
> You nedd to instal KB927891....This will fix it.
>
> "Jakob Bohm" wrote:
>
>> MowGreen wrote:
>>> Jakob Bohm wrote:
>>>
>>>
>>>> [You may ignore PA Bear, he screams malware no matter what the
>>>> question is]
>>>>
>>>> Windows Updates are downloaded by the BITS service which runs in one of
>>>> the systems svchost.exe instances. Windows Update itself runs in
>>>> another instance of svchost.exe. So if anything in Windows Update
>>>> itself is using too much CPU to be useable, Task Manager will show that
>>>> CPU waste as happening in svchost.exe .
>>>>
>>>> When Windows Update gets stupid about its download handling, I usually
>>>> solve it like this (This procedure cleans out half-downloaded updates
>>>> and old long-ago-installed updates, plus the internal state of Windows
>>>> Update):
>>>>
>>>> 1. Reboot
>>>> 2. Open a "Command Prompt window"
>>>> 3. NET STOP wuauserv
>>>> 4. NET STOP BITS
>>>> 5. CD /D %SystemRoot%
>>>> 6. DIR \
>>>> 7. (Note if the disk was almost full)
>>>> 8. CD SoftwareDistribution
>>>> 9. rd /s Download
>>>> 10. Y
>>>> 11. rd /s DataStore
>>>> 12. Y
>>>> 13. DIR \
>>>> 14. (STOP if the disk is still almost full)
>>>> 15. NET START wuauserv
>>>> 16. Try again
>>>>
>>>>
>>>
>>> Each time the SoftwareDistribution subfolders are deleted they are
>>> recreated when the update service starts. Said update service is started
>>> on boot by it's Default setting, no matter which options one chooses for
>>> Automatic or Windows Update's settings.
>>>
>> Yes, I know that and the procedure above assumes that.
>>
>>> If there is 3rd party software [security software] installed that is
>>> monitoring system files, then one will see a slight spike in CPU usage
>>> by svchost when the subfolders of SD are recreated.
>>>
>> Two other sources of spikes which I have seen over the years:
>>
>> 1. If the DataStore has become corrupted by a random event, the code
>> that manages it can spend a lot of CPU cycles spinning its wheels for
>> little or no gain. Clearing out the database and starting over gets you
>> a clean uncorrupted database in a few minutes.
>>
>> 2. The delta-download mechanism used by Windows Update to avoid
>> downloading the parts of an update already on your system sometimes
>> spends more time computing differences than it saves in download time.
>> Clearing out the download folder and starting over forces a clean
>> download without so much work.
>>
>>> When the update database located in DataStore is scanned or monitored
>>> [DataStore.edb] there will be a spike in CPU usage due to it being in
>>> use [ locked ].
>>
>> Whenever the DataStore is being processed to figure out what updates are
>> needed on your computer there will be a spike of a few minutes, with or
>> without a broken AV-scanner slowing things down further.
>>
>> Additional CPU time wasted by AV scanners may be attributed to the
>> process that is being slowed down (svchost in the case of WU/AU) or the
>> scanners own processes depending on the scanner product. Most AV
>> scanners use an architecture where the actual scanning CPU load occurs
>> in a dedicated scanning process easily recognized in task manager.
>>
>>> This spike will become more noticeable over time as DataStore.edb can
>>> become either corrupted or irreparrably damaged.
>>
>> Now you are really confusing the issues: There is extra CPU waste due to
>> the scanner itself repeatedly scanning the database file, this does not
>> involve corruption or damage to the file (unless the AV product is
>> incompetent enough to corrupt any file being scanned while in use). And
>> then there is CPU waste due to a corrupted or damaged database for which
>> the quickest cure is to clear out the database and start over with a
>> fresh WU/MU/AU run.
>>
>>> To mitigate this issue, see:
>>>
>>> Virus scanning recommendations for computers that are running Windows
>>> Server 2008, Windows Server 2003, Windows 2000, Windows XP, or Windows
>>> Vista
>>> http://support.microsoft.com/kb/822158
>>
>> Hilarious article written by someone who see bugs in some AV products
>> (corruption of binary files that are being changed by their application
>> while the AV product tries to scan them), assume they apply to all AV
>> products, and then go on to recommend a bad partial workaround (exclude
>> the handful of files most important to their personal pet software) as
>> a general and complete solution.
>>
>>>
>>> On a system that has had subfolders of the SoftwareDistrbution directory
>>> deleted and *if the CPU cycles stays at 99%*, then the logical
>>> conclusion is that 3rd party software is hindering the OS from
>>> recreating said subfolders, and/or there is an issue with the detection
>>> logic, and/or there is an issue with the Windows Installer associated
>>> .dll file, .msi.dll.
>>
>> The OP was about a computer where the subfolders had not been deleted
>> (before applying my advice) and thus it cannot be concluded that the
>> slowdown is due to software interfering with WU now. Performing my
>> clean out procedure once, will either eliminate old corruption or
>> definitively show that something is continuing to interfere. You and PA
>> Bear blindly assume the latter possibility even when there is lots of
>> evidence pointing to the other one (In this case: Slow old machine,
>> machine generally up to date on older updates, machine not used for
>> general Internet access or other high risk activities, CPU usage in the
>> exact processes associated with a corrupted SoftwareDistribution folder).
>>
>>> The latter two issues have been mitigated in the latest releases of the
>>> Windows Update Agent.
>> In which case starting over with a clean database would reap the
>> benefits of this improvement.
>>
>>>
>>> " Old long ago updates " are flushed from the Download subfolder of SD
>>> on a regular cycle IF the automatic update components are functioning
>>> properly and are not being hindered from carrying out their operations
>>> by 3rd party software.
>>
>> Unfortunately, this does not match my own experience. At least until
>> recently, WU was a real disk space hog, constantly eating additional
>> disk space every month and not listing its own temporary files in the
>> Disk Cleanup wizard. Because disk full on the Windows drive is a really
>> bad situation to be in I have made a habit out of culling excess files
>> from WU on a regular basis.
>>
>>>
>>> Said 3rd party software will either be security software or malware.
>>> Since the *vast majority of issues* posted to this newsgroup *are*
>>> directly related to the presence of malware, then it's not illogical to
>>> conclude that malware is present on systems where the CPU cycle issue is
>>> present.
>>>
>>
>> So you assume the worst, ignore all innocent explanations, then go on to
>> call the fire department every time you see smoke, even if it is coming
>> out the top of a chimney.
>>
>>> Conclusion: Ignore Jakob Bohm since he's unaware that malware can cause
>>> the CPU utilization issue or that security software should be configured
>>> to not scan nor monitor DataStore.edb
>>>
>>
>> THAT is an insult. I KNOW that malware can do all kinds of bad things,
>> including eat lots of CPU in strange situations. I strongly disagree
>> that *all* brands of security software need to specifically exclude
>> Windows Update files from scanning. But I also KNOW that not all
>> computer problems are from malware and that telling everyone to panic
>> and ignoring all non-malicious explanations is not helpful.
>>
>> In this case the symptoms clearly matched a known problem for which
>> there is a quick and harmless cure. So that cure should be tried before
>> starting panic measures to combat an infection that might not be there.
>>
>> If after cleaning out the dynamic part of the SoftwareDistribution
>> folder the problem immediately recurs, the next step would be to turn
>> off automatic updates, clean out again, then use interactive WU/MU to
>> see the name of the affected update. Then manually download and install
>> that update from Microsoft downloads and try again. If the problem is
>> still there after bypassing WU/MU for the directly affected update, THEN
>> there is something fundamentally wrong and checking for malware would be
>> a relevant thing to do.

DJT Wrote:

Thanks for all the suggestions. I was running adaware and spybot SD
and scans by either of these found nothing.

I removed them and installed a copy of Trend Micro Internet Security
pro that I had tried on my Vista machine( removed due to Excessive
slowdown). It found several items of malware and the PC has been ok
since

Thanks

DJT
===========================
Well, I'll be it was malware after all. Congrats PA Bear et al.

--
antwesor

As posted by DJT in regards to the presence of malware causing the CPU
utilization issue:

> Thanks for all the suggestions. I was running adaware and spybot SD
> and scans by either of these found nothing.
>
> I removed them and installed a copy of Trend Micro Internet Security
> pro that I had tried on my Vista machine( removed due to Excessive
> slowdown). It found several items of malware and the PC has been ok
> since
>
> Thanks
>
> DJT

As PABear suspected in the first place -

> [You may ignore PA Bear, he screams malware no matter what the question is]

So, it turns out that his suspicion of malware causing the issue was
spot on despite your lengthy treatise that attempted to dispute that fact.

> Since the *vast majority of issues* posted to this newsgroup *are* directly related to the presence
> of malware, then it's not illogical to conclude that malware is present on systems where the CPU cycle
> issue is present.

Perhaps if you spent more time in this NG then you would have understood
the above statement.



MowGreen
===============
*-343-* FDNY
Never Forgotten
===============

DJT wrote:
<snip>
> Thanks for all the suggestions. I was running adaware and spybot SD
> and scans by either of these found nothing.
>
> I removed them and installed a copy of Trend Micro Internet Security
> pro that I had tried on my Vista machine( removed due to Excessive
> slowdown). It found several items of malware and the PC has been ok
> since

Ad-Aware and Spybot are NOT anti-virus applications, DJT.

Protect Your PC!
http://www.microsoft.com/athome/secu...r/default.mspx

Steps To Help Prevent Spyware
http://www.microsoft.com/protect/com...e/prevent.mspx

Steps to Help Prevent Computer Worms
http://www.microsoft.com/protect/com...s/prevent.mspx

Avoid Rogue Security Software!
http://www.microsoft.com/protect/com...ses/rogue.mspx
--
~Robear Dyer (PA Bear)
MS MVP-IE, Mail, Security, Windows Client - since 2002