Lexington, Mass., was in glorious, late-spring bloom when I visited Windows Secrets reader Helene Mayer.
Helene had a houseful of PCs (running XP, Vista, and Win7) exhibiting a variety of problems. I was there to help.
This is the second installment of the 2012 House Call series — an off-and-on project in which I visit a reader’s home or business and attempt to diagnose and cure real-life PC problems.
The idea behind House Call is simple: I collaborate with selected Windows Secrets readers to learn what really works in analyzing, maintaining, and improving our personal computers. We then share what we find with all Windows Secrets readers via articles like this. (For a fuller explanation of House Calls, see the first article in this series, the April 12 Top Story, “House Call 2012: Fixing a sluggish PC.”)
Assorted glitches, problems, and annoyances
I selected Helene for this House Call because — like many of us — she maintains a variety of Windows systems in her home. As she’s added new systems over the years, the older systems remain in use, handed down to family members with less intensive computing needs.
Here’s the note Helene sent in when I originally asked for House Call participants:
- “I’m one of those users who are afraid to do almost anything complicated to my computer, for fear of doing irreparable harm. I have a 6GB laptop running Windows 7 x64. I’m finding Windows 7 a bit wonky. [Helene then included more details, which I’ll get to later.]
“My son has my old laptop, which is running Vista. It’s still registered to me, and I have no idea how to change that. I used to clean that PC up regularly. I tell my son to do the same, and to apply updates — but I doubt he ever does. He’s 15 and spends a lot of time online. Who knows how much junk he has on that laptop!
“We also have two PCs which are both slow and wonky and are running XP!”
What follows are selected highlights of what we found during the course of the House Call.
Windows shutdown problems
My preferred first step in any PC-maintenance session is a thorough system cleanup and tune-up — removing junk files, updating the software and drivers, and so on. (The process was described in the April 12 House Call story.)
One of the issues Helene reported was slow startups and shutdowns, something I saw for myself during the initial cleanup/tune-up process. Shutdown, in particular, seemed very slow, with long periods of intense disk activity followed by periods with no visible system activity at all.
I suspected the long burst of disk activity was related to her system’s relatively large amount (6GB) of RAM. In many setups, Windows is configured to wipe the pagefile at shutdown as a security measure, and a typical 6GB system has a 6–9GB pagefile. Wiping this much disk space can cause a very noticeable and annoying shutdown delay.
That type of delay might be worthwhile if wiping the pagefile actually improved security, but for most of us, it doesn’t. (See the June 13 LangaList Plus item, “Is Windows’ pagefile a security risk?”)
If pagefile-wipes are enabled on your system — as they were on Helene’s — disabling them can dramatically reduce shutdown time while not materially increasing security risks.
Here’s how it’s easily done in Win7. (See Microsoft Support article 314834 for other Windows versions and for alternative methods.)
- Open Windows’ built-in Registry Editor by entering regedit in the Start menu’s text-entry box.
- Navigate to \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management.
- Click on ClearPageFileAtShutdown and change the value from 1 (enabled) to 0 (disabled), as shown in Figure 2. That’s all there is to it!
That simple change eliminated the intensive disk activity at shutdown. But the shutdown process still contained long pauses where nothing seemed to be happening.
This is usually caused by poorly written, third-party drivers (or services or other running software) that are slow or unresponsive to the operating system’s shutdown command. Win7 normally gives each running software component up to 12,000 milliseconds — an extremely cautious 12 seconds! — to respond before timing it out and proceeding with shutdown.
Vista and XP are even slower, waiting up to 20,000 milliseconds — 20 seconds! — per running component.
It doesn’t take many 12,000–20,000-millisecond dead spots during shutdown to really gum up the works.
The best fix for unresponsive software is to install better software. But the apps and third-party drivers on Helene’s system were current. Some software just isn’t coded well, leaving end users holding the bag.
Fortunately, Windows offers a workaround for this problem: You can adjust the WaitToKillServiceTimeout Registry setting to a shorter time.
Here’s how in Win7 and Vista. (For XP, see MS Support article 146092.)
- Open RegEdit.
- Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\.
- Select WaitToKillServiceTimeout and set the value from the default setting to a lower value. (Note: Enter numeric digits only, as shown in Figure 3. Do not use comma separators.) On Helene’s Win7 system, we initially reduced the timeout from 12000 milliseconds (12 seconds) to a more aggressive 8000 milliseconds (8 seconds). I suggested to Helene that she could later adjust the amount up or down, as experience dictated.
Combined, these two Registry edits cut her shutdown time roughly in half!
Using Soluto to streamline the startup
Next, we tackled the slow startup.
In many cases, software engineers design their programs to quietly launch as soon as the PC is booted. With all or part of the code in memory, the app will seem more responsive when the user actually opens it.
But you pay the price for that convenience at startup. When lots of software preloads that way (whether you want it to or not), you get needlessly long boot times.
We used Soluto (site), a free, automated tool that works on all current Windows versions, to streamline Helene’s startup. Once installed, Soluto monitors the startup and figures out which background apps really need to load — what’s essential and what’s not. It displays its findings in a graphical interface that tells you what should be left alone, what’s known to be removable from the boot process, and what is potentially removable (as illustrated in Figure 4).
Soluto lets you remove an item from the boot process (called a “pause” because you can still launch the software normally later on) or delay selected items, which still lets the software load itself — just not during the initial boot.
This article isn’t a review of Soluto, which actually has many additional functions and features. There’s plenty of information available on the Soluto site, and Lincoln Spector covered an earlier iteration of Soluto in his Jan. 6, 2011, Top Story, “Four free programs to help control Windows 7.”
After we’d finished running Soluto, Helene’s system-startup time was reduced by 25 percent.
With Helene’s Win7 system cleaned and running well, I moved on to the other machines.
The Vista PC: packed to the gills
Helene’s son’s Vista laptop was indeed jam-packed with files: its 100GB hard drive showed 97.9GB used. When hard drives get very full, system performance can suffer because there’s so little elbow room for the pagefile and other file-moving operations. Tasks such as defragging might not work at all, if a drive has less than about 15 percent free space.
Helene’s son wasn’t available, so I wasn’t able to ask him about uninstalling unneeded and low-priority software. But a thorough cleanup (as described earlier) found and removed about 9GB of junk files — recovering almost 10 percent of his disk space!
In space-constrained systems, it’s a good idea to check the size of browser caches, the Recycle Bin, and the System Restore cache. Most of this is easy to do. For example, in Win7 and XP, you can adjust the amount of space reserved for System Restore by means of a simple graphical slider interface (MS info).
But for reasons known only to Microsoft, Vista handles System Restore sizing the hard way, via a command line. I opened a Command window (using Run as administrator) and typed the following command:
vssadmin Resize ShadowStorage /For=C: /On=C: /Maxsize=3GB
That command tells vssadmin (the Volume ShadowStorage administrator tool) to resize the ShadowStorage area (which holds restore points and previous file versions) for the C: drive, on the C: drive, to a maximum size of 3GB. (You might want to use a larger or smaller value, depending on your system configuration.)
Ultimately, we increased the free space on the system to 11GB — still not all that much in absolute terms, but a fivefold increase from where we started!
I left two recommendations for further increasing free space on the system: first, uninstall unneeded and low-priority apps; second, use disk compression on some or all of the C: drive. (See Figure 5.)
The Vista PC was still showing Helene as the registered owner, but that was easy to change. Here’s how:
- Open RegEdit.
- Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion.
- Click RegisteredOwner and enter the correct information.
You can also use the same process to alter the RegisteredOrganization information, if you wish.
Final steps: the XP machines and the wrap-up
Tuning up the two XP systems was the most straightforward task of the lot: full, standard cleanups on both greatly increased their responsiveness.
One of the XP boxes was exhibiting a problem with extreme delays when opening Word. A simple uninstall/reinstall cycle for Word corrected this.
And with that, I was done.
I gathered my things and found Helene at her Win7 PC, going about her daily online tasks. As I entered the room, I heard her say, “Wow!”
“What’s going on?” I asked.
She said, “It’s not just startup and shutdown — everything seems faster!”
Now, that’s what I like to hear!
Thanks, Helene, for letting us all learn from your systems. Stay tuned for the next House Call installment!