 |
|
 |
|
On Mon, 18 May 2009 12:43:20 -0400, "PA Bear [MS MVP]" <...@gmail.com
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
|
|
 |
|
 |
 |
|
 |
|
On Mon, 18 May 2009 09:57:51 -0700, MowGreen <...@nowandzen.com
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
===============
|
|
 |
|
 |
 |
|
 |
|
On Tue, 19 May 2009 18:38:24 +0200, Jakob Bohm <...@danware.dk
Yes, I know that and the procedure above assumes that.
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.
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.
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.
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.
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).
In which case starting over with a clean database would reap the
benefits of this improvement.
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.
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.
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. * j...@danware.dk * 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.
|
|
 |
|
 |
 |
|
 |
|
On Thu, 21 May 2009 11:37:37 -0700, MowGreen <...@nowandzen.com
As posted by DJT in regards to the presence of malware causing the CPU
utilization issue:
As PABear suspected in the first place -
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.
Perhaps if you spent more time in this NG then you would have understood
the above statement.
MowGreen
===============
*-343-* FDNY
Never Forgotten
===============
|
|
 |
|
 |
 |
|
 |
|
On Wed, 20 May 2009 08:07:01 -0700, Vinny V <Vinny V@discussions.microsoft.com
You nedd to instal KB927891....This will fix it.
>
|
|
 |
|
 |
 |
|
 |
|
On Wed, 20 May 2009 11:15:33 -0400, "PA Bear [MS MVP]" <...@gmail.com
"Release Date: June 26, 2007"
If the machine needs KB927891, you've got way bigger problems, my friend!!
|
|
 |
|
 |
 |
|
 |
|
On Thu, 21 May 2009 15:54:35 +1000, DJT <...@hotmail.com.au
On Wed, 20 May 2009 11:15:33 -0400, "PA Bear [MS MVP]"
<...@gmail.com
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
|
|
 |
|
 |
 |
|
 |
|
On Thu, 21 May 2009 13:07:51 -0500, State of MN <...@nowhere.com
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
|
|
 |
|
 |
|
|