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. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
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 | |
|
|