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. *
jb@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.
Linear Mode
