Posted by: Ed Tittel
achieving stable production PC status on Windows 7, fixing Windows 7 driver problems, Windows 7 stability index, Windows Reliability Monitor
Anybody who’s followed this blog for any length of time knows that I’ve fought my battles with both Vista and Windows 7, in terms of making my production PC stable and reliable. Today, I’m very happy to report that my production machine has finally achieved and held a 10.0 Stability Index for at least three days at a time, and that the latest hiccup in my reliability and problem history is my own fault: I neglected to hook up my USB keyboard after swapping in some new system components recently, and was forced to shut Windows down as a result (on 12/10/2009 as shown in the following screenshot):
Here’s what I had to do to get myself into this situation of relative calm and proper operation:
- Troubleshoot the Dell AIO 968 printer’s default behavior to install itself as an XPS print device rather than as a native print device (this forces all print documents to be reformatted into an XML format, which the printer can output, but which also caused the Print Filter Pipeline Service, aka printfilterpiplineservice.exe, to crash regularly and repeatedly).
- Switch from Spyware Doctor with Antivirus to Norton Internet Security 2010 (to quell repeated daily crashes of the pctsSvc.exe notification tray program for the former program, after trying unsuccessfully to get the nice folks at PC Tools to help me solve the problem over a period of 30 days).
- Clean up my MS Office 2007 installation (which involved replacing an older PPT Viewer application with a newer version at Secunia PSI’s recommendation, then applying nearly a dozen Windows Update files that appeared in response to this change). This solved some repeated issues with Word and Outlook that had been entirely mysterious up to that point.
- Avoid installing toy or test progams on my production PC. As somebody who writes about software and utilities a lot, I’ve had to learn to resist the temptation to install them on a production PC, and to install them on a test machine instead — preferably within a VM so that they can’t mess up my test machine’s runtime environment, either.
- Groom the drivers on the production PC to make sure they’re all current, correct, and working well with Windows 7. For that purpose, I’ve used Phoenix Technologies’ DriverAgent Web site and my own ever-increasing understanding of how to fiddle with Windows device drivers. It usually takes me a month or so following a new OS install or system build to get everything working to my complete satisfaction.
To see what I was dealing with, here’s the Windows 7 Reliability Monitor’s graph from the day I installed Windows 7 RTM on my production PC (8/9/09) to today (12/22/09) where you can see my many and literal “ups and downs” in getting this system working properly:
I thought I had things licked the week of August 30, but found out the next week that I needed to alter the default configuration from installing the Dell AIO 968 printer drivers, then had to canoodle my way through the other issues mentioned in the preceding list until mid November. Everything else since then has been self-inflicted, and is part of my normal pattern of Windows system behavior: keep things running, make the occasional mistake or a change that alters stability for the worse, diagnose it, fix it, and keep on keeping on.
[Note: For the benefit of the sharp-eyed and incurably curious, the glitch that appears on 12/9/09 in the first screencap in this blog resulted from cancelling a hung Windows Explorer operation when I attempted to perform a search while the indexer was active. Rather than wait for the indexer conclude its operation and then complete the search I used Task Manager to shut the running instance down. This cost me a trivial 0.02 stability index points, but still shows up as an application failure glitch even though it makes no visible impact on the stability graph.]