Dealing with software crashes - Part 1
Dealing with software crashes - Part 1. Expanding on a story from the Wall Street Journal.
Software crashes all too often, and since misery loves company, computer users often swap horror stories. Back on Halloween, Lee Gomes did so publicly in the Wall Street Journal. His problem was with the Adobe Premiere Pro, a video editing program and, while I found it interesting, the article didn't offer advice for avoiding or dealing with software crashes. That's what I hope to do here. First though, defending your privacy.
ERROR REPORTING
When applications crash, a window often pops up asking if you want to report the problem to Microsoft. Gomes writes that the Microsoft employees who get these crash reports are "scrupulous ... about respecting user privacy". Perhaps, but the last company I would trust with personal information is Microsoft (just behind Marshalls and TJ Maxx). What's the connection between failed software and personal privacy?
Suppose Word crashes while you are working on a document that you don't want others to see. It's safe to say that pieces of that document are included in the information about the error that's sent to Microsoft. And it is possible, though I don't know how likely, that information from other running programs may also be included.
While just saying no, when asked about reporting the error to Microsoft, is easy enough, it's also easily forgotten. Fortunately, you can configure Windows to never report software failures to Microsoft by turning off the error reporting feature. In Windows XP this is done with:
Control Panel -> System -> Advanced tab -> Error Reporting button
I suggest disabling error reporting but still getting notified of critical errors.
CONFLICTS
The root cause of the problem in the article was all too common, a conflict with other software installed on the computer. Apparently the other software had mis-labeled something and "that slip-up cascaded throughout Windows...".
It doesn't have to be this way. In a perfect world, each application would be isolated from other applications.
Getting to this ideal is one of the reasons for the popularity of virtualization. For example, important applications can be run inside a virtual copy of the operating system and be the only software installed in that instance of the operating system. Virtualization software lets you run multiple operating systems concurrently on a single computer, so if need be a single machine can run multiple applications with no chance of their stepping on each others toes. Another option, often used with servers, is to limit one computer to a single application. Both are non-trivial steps to take, but when the application is important enough it makes sense.
There is also software, such as Thinstall, to virtualize a single application rather than the entire operating system. Here too, the idea is to isolate an application from the proverbial other kids in the sandbox that may not play well together.
The simplest way, however, to get application isolation is to use portable applications.
The name portable derives from the fact that the application can be run in any instance of it's supported operating system(s) without being formally installed. A portable program designed for Windows XP, for example, will run on any copy of Windows XP and from any disk drive letter, but the portability does not, in and of itself, imply that it will also work on Vista or Windows 2000.
The classic use of portable applications is to run them off a USB thumb drive, but they work just as well running off the C disk. I do this all the time. Whenever possible, I prefer to use portable applications (see this about portable Thunderbird).
An excellent source of portable applications is John T. Haller's portableapps.com. The interesting thing about this site is that Mr. Haller converts applications that were not designed to be portable in the first place. Some applications are portable even though they may not be described as such on their web site. For example, I often use the free EditPad Lite text editor from Just Great Software which is not touted as being portable, but is nonetheless. The same is true of the free, open source, AbiWordword processor. (Both are also available at download.com: AbiWord EditPad Lite)
AUTOMATICALLY RUN PROGRAMS
Complexity is at the heart of many software failures and, as the article pointed out, the complexity of Windows is frequently added to by a whole host of programs that insist on automatically running when Windows starts up. Auto-started programs are a long standing problem because:
- They make Windows start up slower
- They make it more likely that Windows will fail to start up
- They consume RAM and processor resources
- The more programs running in the background, the more that can go wrong
Windows XP has a built-in function (MSCONFIG) for controlling the programs that run automatically at startup time, but it's poorly designed. I am a big fan of a free program called Startup Control Panel, by Mike Lin. I install it on every computer I work on, feel lost without it and never had it cause a problem.
Both programs display a checkbox next to each auto-started program and you control if a given program will be auto-started the next time Windows boots by simply checking or unchecking the box. That's where the similarity ends though, Startup Control Panel is easier to use than MSCONFIG and more complete in its reporting.
For one thing, it's easier to find. Whereas MSCONFIG is one of those things you have to know about to run, Startup Control Panel creates a Startup icon in the Control Panel, just where a function like this logically belongs. Also, after modifying the list of auto-started programs it doesn't produce a confusing warning window the next time Windows starts up.
Windows has many different lists of programs to run automatically and Startup Control Panel shows five of those lists, each in its own tab. As for completeness, MSCONFIG shows 11 programs that are auto-started by Windows on the computer I'm writing this on. Startup Control panel shows 36.
There are two versions of Startup Control Panel. The normally installed version creates an icon in the Control Panel, the standalone version does not need to be installed. The advantage of the standalone version is that it's portable, the program is a single EXE file. The advantage of the installed version is that it's easy to find in the Control Panel (except that you have to use Classic View).
At download.com
Startup Control Panel works with Windows 95, 98, ME, NT4, 2000 and XP. According to the author it is not needed in Vista: "Windows Vista, after all these years, finally has a very good startup manager built-in; go to Control Panel > Performance Information and Tools, and then click on Manage Startup Programs on the left."
AUTORUNS
While Startup Control Panel is great for non-techies, us nerds are better served by another free program, Autoruns. Originally developed by Mark Russinovich and Bryce Cogswell of Sysinternals, the program is now available from Microsoft which purchased Sysinternals a while back.
Autoruns is even more complete than Startup Control Panel. According to the author it has "the most comprehensive knowledge of auto-starting locations of any startup monitor..." It's so complete as to be intimidating if you're not familiar with things like Explorer shell extensions, browser helper objects and Winlogon notifications.
There are two types of auto-started programs in Windows and both MSCONFIG and Startup Control Panel only show one type. The other type, services, is included in Autoruns. It's extensive list of auto-started programs can be pared down by opting to Hide Signed Microsoft Entries (under Options on the menu bar).
Autoruns has been helpful to me in tracking down assorted malicious software. The bad guys want their software to run automatically when Windows starts up, so Autoruns is bound to have an entry for it. In addition, it has shown some auto-loaded drivers that make for interesting stories that I'll discuss in future postings.
Autoruns is portable and works with all versions of Windows.
FIRST CLASS
When Windows crashes with the infamous Blue Screen of Death (BSOD) the offending program may not have been written by Microsoft.
Windows is internally structured like an airplane with first class and coach sections. The applications we use on a daily basis sit in, and are restricted to, coach. First class is where the guts of Windows (referred to as the kernel) sits. But anyone with enough money can get a first class ticket.
To illustrate, software from Andrea Electronics, Meetinghouse Data Communications, Atmel Inc, Analog Devices, Conexant Systems, Parallel Technologies and UPEK Inc. is sitting in first class on the computer I'm using to write this. Technically, these companies wrote driver software, as did three other companies that refused to identify themselves at all.
Once you're in first class you can wander around anywhere. Driver programs, from these companies and others, can thus muck up any part of Windows. And many of them have.
How often is Microsoft at fault when Windows crashes? According to Mr. Gomes, they know, but won't say. That tells me two things: 1) it's often their fault and 2) it's nice to be a monopoly.
Part 2 covers Driver Verifier (a utility built into Windows for debugging drivers), dumps, event logs and disk checking.
November 14, 2007: Updated to reflect the topics in Part 2.
November 9, 2007: Updated to reflect the two different versions of Startup Control Panel.