A Windows XP help forum. PCbanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PCbanter forum » Microsoft Windows XP » General XP issues or comments
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Firewall/networking delay, Slow Windows Update



 
 
Thread Tools Display Modes
  #1  
Old August 31st 13, 01:59 PM posted to microsoft.public.windowsxp.general
Paul
external usenet poster
 
Posts: 18,275
Default Firewall/networking delay, Slow Windows Update

I have a couple items to report, based on running
Windows Update over the last couple days.

Before doing the updates this time, I did a backup of C:.
And after my first attempt, I actually restored from backup.
Because I didn't like the symptoms I was seeing.

So today, I gave it another try, and here
are a couple hints at what I was seeing. I
can't really say they are "fixes", because
with this stuff, you can never really be sure
what step is fixing it.

*******

OK, so I do the .NET updates first. I usually select
all the .NET ones, turn off the rest, and run them.
That's because .NET has a habit of doing obnoxious things.

After the updates are finished, it appears network
services aren't starting promptly after a reboot.
I get a message box (eventually), telling me the firewall
isn't started. Then the firewall starts, and soon after,
so does regular networking. I have one program I run
promptly after a reboot, and it is "held hostage" until
these other events happen (networking starts). This
phenomenon was seen back in SP2, and was patched at that
time. But this is not the same problem.

So somehow, this is related to .NET 4.0 , or so some
web page is claiming. The solution they propose, is
an issue that's been around for some time. And that is,
that .NET assemblies are pre-compiled. And when you
install .NET updates, the installer will set a flag indicating
these need to be pre-compiled again. They seem to
run in two groups. Some of the assemblies are pre-compiled
immediately (during Windows Update). Others are "queued"
for later. They get processed when the machine is idle.

When you use Windows Update, and install say, a half dozen
..NET updates, each one of them triggers pre-compilation.
Which means there is a great deal of wasted cycles along
the way (five pre-compilations wasted).

Now, the next time you reboot Windows (and it would seem,
each time after that), the items in the queue get considered.
Yet, nothing seems to be happening. It doesn't appear this
process runs to completion.

You can open a command prompt, navigate to a location like:

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319

and run this command in the command prompt window:

ngen.exe executequeueditems

Note that, when you have a few of the layers of .NET installed,
there is an ngen.exe in v2.0.50727 and an ngen.exe in v4.0.30319 .
And in this case, I'm running the one in v4.0.30319 . The
service that normally does this stuff, one instance knows
it is not supposed to run (as noted in the .log file kept in
each of those folders).

Anyway, after a couple minutes of grinding, the queue is drained.
And, on the next reboot, there is no longer s pregnant pause
until networking services begin. My system is back to normal.

Note that, the problem can be triggered again, by the slightest
change in the system. I happened to run a Microsoft Fixit after
this, and it appeared to bring the problem back. The Fixit patched
something PowerShell related. Issuing the above command
again (ngen.exe executequeueditems) returned things to normal.
I expect I'll be running this again, next month... :-(

*******

The second issue this month, was with Windows Update itself.
I have things set up "manual", and when I click the "Custom"
button in the IE window for Windows Update, off it goes.

Then, wuauserv (living inside a svchost), pegs the CPU on one
core. So it's spinning in some kind of a loop. It can stay there
for five minutes or more, on a whim.

You can list the guilty party, by using "tasklist /svc", but that is
only available on Pro. For those Home users out there, they
can use Process Explorer from sysinternals.com , to get largely
the same info.

Seeing the high CPU, I didn't really need to verify who was doing
it. High CPU due to Windows Update has been seen before. Several
times.

OK, so I get the Microsoft Fixit for Windows Update, and it
pretends my "data storage location is incorrect" and pretends to
correct it. Subsequent runs of the Fixit, report the same problem
and the same fix. I don't see an "aggressive reset" option that
I've heard of.

So at this point, I'm getting a bit ****ed at the whole thing.

Windows Update will eventually show up, but not until some
time has passed. So it does eventually resolve itself, but
since I install Updates a few at a time (like, do all the
..NET ones first), I can't put up with this. I would have
to sit on my hands for quite a few of those five to ten
minute delays, to finish the job.

I happen to go to the "Software, Optional" section
of Windows Update, and there is a "root certificate" update
pending. And because I like new root certificates (they're
like fresh baked bread), I install it. Just on a whim.
None of the other pending ones in there, interest me
in the least. I was just bored at this point.

http://support.microsoft.com/kb/931125

And after I do that, suddenly Windows Update "Custom button" is
coming back after only 15 to 20 seconds of pondering. Appears
to be fixed, but who really knows for sure about these things.
In other words, the wuauserv was jammed up, because a
certificate it needed wasn't right!

Paul
Ads
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off






All times are GMT +1. The time now is 01:20 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 PCbanter.
The comments are property of their posters.