Computing habits often have an effect on how well your computer runs. If you’re aware of what can hurt your computer’s performance, you can save yourself some aggravation by cutting down the time you have to wait for software to load or for Windows to boot. Here are ten ways to get your computer to run slower than molasses on a cold day in November.
1) Install Every Anti-Spyware and Anti-Virus Application You Can Find
If one is good, several have to be better, right? Some people think so. If you’re one of those people, this could be a very good reason why it takes forever to start the computer, open up your browser, or open up a Word document. (more…)
adaware,
anti spyware,
anti virus,
computer,
cpu utilization,
display pictures,
firewall one,
google search,
hijackthis,
msn,
spybot,
startup tab,
type msconfig,
virus package,
widget,
widgets,
word document
Written by Jason on November 26th, 2007 with comments disabled.
Read more articles on MSN and adaware and anti spyware and anti virus and computer and cpu utilization and display pictures and firewall one and google search and hijackthis and spybot and startup tab and type msconfig and virus package and widget and widgets and word document.
Just received the following that is related to the SVCHOST issues that I've written about in the past...
MS has released "Microsoft Security Advisory (927891) - Fix for Windows Installer (MSI)" that's not really a direct security concern, but actually addresses concerns that might prevent people from getting critical security or other updates.
As previously mentioned, it involves MS KB 927891 - "You receive an access violation error and the system may appear to become unresponsive when you try to install an update from Windows Update or from Microsoft Update", and the current revision of the article (8.0) states "This fix is one component of a two-part fix that includes a Windows Update client software update. These updates will be deployed automatically using Windows Update in May 2007 and June 2007."
Again, this update is one of two that need to be applied to fully address the issue. The other update is version 3.0 of the Windows Update Client Software, available from MS KB 932494, "When you use Automatic Updates to scan for updates or to apply updates to applications that use Windows Installer, you experience issues that involve the Svchost.exe process".
One can also hope that this will help address the 0x8ddd0009 problems that MANY have been experiencing...
»
Written by «/\/\Ø|ö±ò\/»®© on May 22nd, 2007 with comments disabled.
Read more articles on Automatic Updates and Microsoft Update and SVCHOST and WUAUSERV and Windows Update and cpu utilization and error message.
Previously (here and here), I've written about isolating shared services so that they run in their own process, with a specific focus on the Windows Update Automatic Updates Service (wuauserv) that typically runs in the NETSVCS SVCHOST.EXE instance. One thing that can be done once this is accomplished is to lower the priority of the process so that when the service winds up consuming 100% of the CPU, the system doesn't become unresponsive.
Since we're dealing with a service, setting the priority of such a SVCHOST.EXE process can become problematic - the service may already be running, or, because it is a service, it is not started as non-service processes are, so one is not able to use START / [LOW NORMAL HIGH REALTIME ABOVENORMAL BELOWNORMAL] to impose a priority when the process starts. One can use a utility like Task Manager or Process Explorer to set the priority of a process on an ad hoc basis, but when the service restarts or the system reboots one has to remember to set the priority again.
Though not an ideal solution the following scripts (VBS using WMI, and PowerShell) can be used to set the priority of the SVCHOST.EXE instance hosting the isolated Windows Update Automatic Updates Service service to "below normal". Note that no check is done to ensure that the SVCHOST.EXE instance is only hosting one service - if wuauserv is found to be a service inside of the process, the priority is adjusted. Note also that no error handling is implemented.
I'll try to format the code so it looks nice, but I fear I will be limited...
Here's the code for the VBS / WMI script:
Const BELOW_NORMAL = 16384
Set objWMIService = GetObject("winmgmts:\\.\root\CIMV2")
Set colServices = objWMIService.ExecQuery( _
"SELECT * FROM Win32_Service where name='wuauserv'")
For Each oService in colServices
Set colProcesses = objWMIService.ExecQuery( _
"SELECT * FROM Win32_Process where ProcessId=" & oService.ProcessId )
For Each oProcess in colProcesses
oProcess.SetPriority(BELOW_NORMAL)
Next
Next
Here's the code for the PowerShell script:
(gps -id (get-wmiobject win32_service where {$_.name -eq "wuauserv"}).ProcessId).PriorityClass="BelowNormal"
The different values for the priority parameter of the SetPriority method of the Win32_Process WMI class can be found in the documentation for the SetPriority method.
The different values for the PriorityClass in the PowerShell script are "Normal", "Idle", "High", "RealTime", "BelowNormal", or "AboveNormal". Or, to get a list of the available options, one can use the following PowerShell command:
[ENUM]::getNames("System.Diagnostics.ProcessPriorityClass")
Once the script is in place and working, one can cause it to be invoked at will, or via scheduled task at specific times, or after logon, or any other way that one can get something to happen when Windows boots or a user logs on.
»
Written by «/\/\Ø|ö±ò\/»®© on May 1st, 2007 with comments disabled.
Read more articles on Automatic Updates and Process Explorer and SVCHOST and Shared Services and Troubleshooting and WUAUSERV and Windows Update and cpu utilization and netsvcs and processes and windows.
Previously (
Part 1: Introduction - What's using my CPU?), I kicked off what I expect to be a multi-part series on determining what is causing excessive CPU consumption, outside of the normal "which process has the highest value in the CPU column in Task Manager".
Before I get into things, a little bit of background may prove useful or mildly entertaining. Over on "Sysinternals Forums", there were recently two similar problems that both involved excessive CPU utilization that was not attributable to a specific process. I became involved in both problems and attempted to use similar techniques to get additional information with the hopes of ultimately being able to pinpoint the problem. What may make this mildly entertaining is that in both cases, there was limited or no success in detetmining the cause of or solution to the problem. In the end,
one problem was resolved by disabling the floppy disk controller, and the
other problem appears to be as of yet unresolved. (In the latter case,
the poster did admit that the system was experiencing hardware problems - the chipset fan was dying and there were diagnostic beep codes during / after POST. These hardware problems could be related to the problem.) Despite the lack of success in determining the cause of the problems I do feel that I learned a bit about this type of problem and gained some insight into the use of some tools that can come in handy in this situation.
In the two cases, the problem consisted of the CPU spending a lot of time servicing interrupts and deferred procedure calls (DPCs). What are interrupts and DPCs? "
Windows Internals, Chapter 3 - System Mechanisms" says:
Interrupts ... are operating system conditions that divert the processor to code outside the normal flow of control. An interrupt is an asynchronous event (one that can occur at any time) that is unrelated to what the processor is executing. Interrupts are generated primarily by I/O devices, processor clocks, or timers.
A deferred procedure call (DPC) is a function that performs a system task—a task that is less time-critical than the current one. The functions are called deferred because they might not execute immediately.
It is interesting to note that one may have a problem with excessive CPU use but may not be able determine it by using Windows' Task Manager. This is because for whatever reason, Task Manager adds time the CPU spends servicing interrupts and DPCs to the "System Idle Process". Microsoft's / Sysinternals'
Process Explorer includes separate "artificial" processes for interrupts and DPCs so that one can see how much time the CPU spends dealing with each. Per Process Explorer's help file, "high CPU consumption by these activities can indicate a hardware problem or device driver bug".
Another thing that could be consuming CPU is the SYSTEM process. The process of determining what system thread is consuming the CPU is similar to determining what thread in a user-mode process is utilizing the CPU. However, excessive CPU utilization by the SYSTEM process might be a little more serious as it is an indication that some driver is possibly running rampant.
Next time, I plan to introduce some tools that can be useful in exploring DPC and interrupt activity on a system, as well as discussing how to determine what driver might be inolved with excessive CPU utilization in the SYSTEM process.
»
Written by «/\/\Ø|ö±ò\/»®© on April 17th, 2007 with comments disabled.
Read more articles on DPCs and Interrupts and Sysinternals and cpu utilization.
In the past, I've written about both
high CPU utilization by SVCHOST.EXE as well as
the 0x8ddd0009 Windows Update / Microsoft Update error, so I thought I would mention this...
MS KB 932494 (
When you use Automatic Updates to scan for updates or to apply updates to applications that use Windows Installer, you experience issues that involve the Svchost.exe process) references problems that are addressed by MS KB 916089 (
FIX: When you run Windows Update to scan for updates that use Windows Installer, including Office updates, CPU utilization may reach 100 percent for prolonged periods) and MS KB 927891 (
You receive an access violation when you try to install an update from Windows Update after you apply hotfix package 916089). However, even after applying the patch associated with 927891 (which replaces the patch associated with 916089), 932494 indicates that the following problems remain:
1) Certain 100 percent CPU issues are still present when you use the Svchost.exe process.
2) An access violation may occur in the Svchost.exe process.
I (as well as others) have speculated in the past that 916089 (and its succedent patches) can also help with
the 0x8ddd0009 error message that one might receive from Windows Update / Microsoft Update.
»
Written by «/\/\Ø|ö±ò\/»®© on March 19th, 2007 with comments disabled.
Read more articles on Automatic Updates and SVCHOST and WUAUSERV and Windows Update and cpu utilization.
Recently, I have been involved in attempting to diagnose problems with excessive CPU utilization. Often times, this type of thing is relatively easy to identify - at least as far as pointing the finger at the thing that is consuming CPU cycles. Task Manager can be used for this - simply sort the "CPU" column in descending order and note the process that is at the top of the list. One can use a similar technique with
Process Explorer.
In the past (
here and
here), I've given examples that demonstrate various techniques that can be used to try to determine what a process is doing when it is consuming so much CPU. Sometimes, you can do something about it - if you have the debugging symbols, perhaps there is something in the stack of the thread or threads in the process that is consuming the CPU that will lead you to some setting, feature, or configuration piece that can be manipulated so as to avoid the problem. Or perhaps just knowing the module name is enough information to identify the problem software - a recently installed add-in / plug-in, or a new utility, perhaps. Sometimes you are forced to work around the problem - you don't have any control over it and don't want to stop using the program, or have no choice but to keep using the program.
But what happens when the excessive CPU utilization is not attributable to a "standard" process? In the coming series of articles, I hope to explore some of the things that can be done to diagnose and troubleshoot this type of scenario. Stay tuned...
»
Written by «/\/\Ø|ö±ò\/»®© on March 6th, 2007 with comments disabled.
Read more articles on Sysinternals and Troubleshooting and cpu utilization.