Observation : windows update

Started by edkiefer, August 13, 2011, 08:38:18 AM

Previous topic - Next topic

edkiefer

This is just an observation I noticed while updating to net ver 4.0 and 2 service updates for it afterwards . While windows was updating I noticed PL stopsign icon keep going on/off in tray , at time not really thinking to much of it .
After update was done, no issue there , I look at log an see like 50 entries with mscorsvw.exe . here 2 for example

,mscorsvw.exe,2904,Process priority temporarily lowered,The process may have been affecting system responsiveness.
,mscorsvw.exe,2904,Process terminated while restrained,This process terminated while its priority was lowered or CPU affinity changed in accordance with ProBalance parameters

Not saying anything wrong but seemed odd so many entries, maybe this service/exe should not be allowed to be restrained ?

Ed
Bitsum QA Engineer

Hotrod

I had the same issue on several of my machines and some of them just seemed to stop cold. The solution? I excluded the process you mentioned and on some machines had to elevate it's priority. I also found that there were several .NET packages that need a helping hand, so I made and exclusion entry for "ndp*x86.exe". Using the wildcard allowed a single entry to work for several different but similar updates. Also in some cases the "setup.exe" had to be excluded and so on...... This however, I removed after the update, since so many Applications use a "setup" file to install. In general, Windows Updates like to have full control especially on the older slower XP machines, so raising priority helps and shutting down as many competing processes as possible. There were several more I modified for this update, but I am at work right now and on a Win 7 laptop so I can't copy them here right now...maybe when I get home, but you get the idea.  ;)

edkiefer

yeh, I did update at windows update site, not DL the update .
As net ver 4.0 is new to me, it took long time IMO to update ,for min I thought it froze on the updating part as progress bar took for every to even show any progress, then it just ripped through install .

Not to long, as it feels long when your watching it , just seemed longer than the norm (maybe 7min or so ) .I believe it is around 40+mb .
I have no idea if PL had any affect on time, I kind of doubt it .

Ed
Bitsum QA Engineer

Hotrod

I tried it on several machines, after the first one took 3 hours or so to finish. I then watched the entire thing through PL as well as the update box. I definitely saw a marked improvement as I applied first exclusions, then on subsequent installs I applied priority adjustments. By the last one I had it all figured out and flew through it in about 20 minutes. The actual downloading portion went smoothly a quickly in all cases...it was the file verification and the actual install that took the longest and was prone to hangups. This was a perfect example of how PL can make an old box do new tricks. It is the best investment I've ever made in the software department.  :D

edkiefer

WOW, 3 hrs I would of freaked out I think . at max it took 15min for me (core2 2.13ghz/2gig mem) . yes the DL was fast it was the install part that "seemed" to hang .

Ok, let me understand, so you excluded the file (rules =X) and then you raised it priority and that improved installation process ?
Bitsum QA Engineer

Hotrod

Yes exactly. Exclusion (X) means it will NOT be restrained when PL sees it using alot of cpu cycles. Higher priority levels will allow it to get the cpu cycles more often than lower priority processes. These are trial and error settings though. You have to watch to see if you get the desired result after each change, so it's best to only make one change at a time and then watch for a bit. In some instances you actually get better results by lowering priority(like when it keeps one of it's own dependencies from getting any cpu time thus grinding itself to a halt waiting on results from something that will never get them) so it helps to watch ALL processes closely when you make changes. With this in mind, I excluded the processes that were being restrained too often, then watched to see who among these was using the most CPU cycle time.