I hate installing printer drivers. For one thing, there is no standardization, each one seems to present a new option, question or issue. Then, there is all that extra software that comes with printer drivers, installing just the driver can be quite a battle.
So, when I had to print something recently and the only available printer was a Canon Bubble Jet model i320 that my laptop hadn't seen before, I cringed. Sure enough, it didn't go well.
At Canon's website, finding the Support section with drivers and downloads was easy, as was clicking on "Americas" and then "Canon U.S.A". But then nothing. My click was ignored. Click again. Still nothing. Click, click, click. Nothing, nothing nothing. Check the Internet connection, it's fine.
It turns out that Canon does not support Firefox, something they don't bother mentioning anywhere. Using Internet Explorer 6, the same click trail resulted in a new browser window opening for the U.S. support site. Firefox must have blocked the creation of the new browser window as part of it's anti-popup protection.
If Canon doesn't want to support Firefox, fine. But they should detect the browser (it's easy to do) and warn their customers to only use Internet Explorer.
The download instructions from Canon are:
1. Click the link, select "Save," specify "Save As," then click "Save" to download the file.
2. The downloaded file will be saved in the specified place in the self-extracting form (.exe format).
3. Double-click the downloaded EXE file to decompress it, then installation will start automatically.
Not hard. Not completely true either, as it turns out.
I saved the file (i320xp190usz.exe) to the root of the C disk and ran it from there. The resulting error is shown below.
In the screen shot it looks like I first clicked on the Unzip button, but that's not the case. As the instructions above say, the installation started automatically. The first step is an unzip to the folder that Canon pre-defined, in this case, folder dot-slash. The unzip operation found no folder named dot (or period if you prefer), tried to create it and failed.
After a few emotional moments (I really wanted to print something), I guessed at the problem. DOS and Linux users may know that ".." is a reference to a higher level directory. I guessed that the dot-slash was somehow related to this dot-dot, so I moved the i320xp190usz.exe file to a temporary subfolder and it ran fine from there.
Not that it mattered in the end, the printer only printed every other letter. The next day, I went out and bought a new printer. Canon was not on my shopping list. Three strikes and you're out.
See a summary of all my Defensive Computing postings.
The first part of this posting on dealing with software crashes covered preventing the leakage of personal information, portable applications, and controlling the programs that run automatically when Windows starts up. Here we look at dumps, event logs, and disk checking, but first, we pick up on the topic of drivers.
Driver Verifier
In Windows, the term "driver" refers to software used by the operating system to control the hardware in the computer. Each piece of hardware (sound, video, printer) has an associated driver program.
The last topic in the previous posting was an airplane analogy to illustrate the potential for problems with Windows drivers. They run alongside the most critical parts of Windows itself and a bug in the driver can crash Windows.
Considering this, it should come as no surprise that Microsoft has a utility program designed to weed out bugs in drivers. The program is called Driver Verifier, and it is included in all recent versions of Windows (Windows 2000 and later).
Driver Verifier does extra checking on the actions of drivers, while they are running, looking for potential problems. Think of it as super-debugging mode. Quoting Microsoft: "Driver Verifier monitors kernel-mode drivers and graphics drivers to detect illegal function calls or actions that might corrupt the system. It can subject the drivers to a variety of stresses and tests to find improper behavior."
I bring this up because it can be a useful thing for debugging. When working with a tech-support person, ask them if drivers are a possible cause of the software problem you are experiencing (video drivers were a suspect in the problem described in The Wall Street Journal story). If so, then ask if Drive Verifier would be helpful. If nothing else, use Driver Verifier to gauge the reaction of the person assisting you.
There is a performance cost to the extra error checking Windows does on the drivers being verified. If verification is turned on for all drivers, Windows may be noticeably slower. Hopefully, the tech-support person can limit the verifying to a small number of drivers.
But, every PC has a different set of drivers. Fortunately, Driver Verifier can list the installed drivers, their version number, and the company that produced them. To run it, open a Command Prompt window (aka DOS window) and type "verifier" without the quotes. You can then close the Command Prompt window. In Vista, a security dialog will ask for permission.
I suggest starting with the radio button that displays existing settings. If this is the first time Driver Verifier has been used, there should be no drivers listed in the right side of the resulting window.
This window also shows different types of tests that will all be set to "No" initially. Windows XP offers eight types of verification tests; Vista has a few more.
Click the back button, turn on the radio button to create standard settings, and then click the Next button. If you "Select driver names from a list," you can see all the installed drivers.
Unless you are a serious Windows techie, driver verifier does not produce any output that is of use to you. It is best used when working with assistance from professional tech support.
Minidumps
Another thing to look for when Windows software crashes is a minidump--a snapshot of the state of the system at the time of the failure.
Dumps can be invaluable to a tech-support person. I spent many years doing technical support and can attest that verbal descriptions of a problem over the phone are not much to go on. Dumps and event logs (the next topic) give a picture of the problem that no person can.
Windows dumps are only useful to someone familiar with the internal working of the operating system. Normal users can't even look at the contents of a dump, Windows does not include the necessary program (Dumpchk.exe) to format it.
Minidumps are small (88K) so sending them to tech support should not be a problem. If you're not asked to look for, or provide, a dump, it would make me wonder how capable the support person is.
By default, Windows XP writes dumps to folder C:\WINDOWS\Minidump. If this folder is empty on your computer, consider yourself lucky.
You can control a number of dump-related options. To do so in Windows XP, start at the Control Panel, then System, then the Advanced tab, and finally click on the Settings button in the start-up and recovery section.
In the system failure section (the bottom half of the resulting window, shown above), I suggest enabling the option to write an event to the system log and turning off the option of automatic restart.
In the write debugging information section, "small memory dump 64K" is the default and should be fine. Only if a tech-support person says this small/minidump doesn't provide enough information, would I chose one of the other options.
The small dump directory defaults to %SystemRoot%\Minidump, which normally translates to C:\WINDOWS\Minidump. There is no need to change it.
Minidumps have a file type of .DMP. The format of the filename is MiniMMDDYY-99 where the last two numbers are a sequence number. For example, Mini110407-01.dmp is the first dump taken on November 4, 2007.
Event Logs
Event logs provide a history of problems and thus can be very helpful in debugging software problems.
To look at the event logs in Windows XP, start at the Control Panel, select Administrative Tools, then Event Viewer. There are at least three different logs: Application, Security, and System. Each log is separate file. To determine the filename and location, right-click on the name of the log, get the Properties, and look for the "Log name." By default, the Application, Security, and System log files are respectively:
C:\WINDOWS\system32\config\AppEvent.Evt
C:\WINDOWS\System32\config\SecEvent.Evt
C:\WINDOWS\system32\config\SysEvent.Evt
A tech-support person should be interested in some, if not all of these files. Event logs shouldn't be that big; in XP they max out at 512K by default.
Check Disk
A corrupted file system may play a part in any software failure. One of the first steps to take when dealing with a software crash should be to run the Windows Check Disk utility.
To do so, open My Computer and get the properties of the C disk. Then go to the Tools tab and click on the Check Now button. This opens a windows with two Check Disk options; I suggest turning on both options. When you click the Start button, Windows will say it can't check a disk that's in use and ask if you want to schedule the checking for the next restart. Say yes and then restart Windows.
Checking a disk can take a long time and Windows does not stop when it's done to let you view any messages. But there is no need to watch the thing run since a summary of the disk checking is written to the Application log. Just after Windows starts up, look at the top of the Application log (where the most recent events should be) for an event with a source of "Winlogon" and a type of "Information." Double-click on it to see the results of the disk check. In my experience, minor inconsistencies are the rule rather than the exception.
May your Minidump folder be forever empty.
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, AbiWord word 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 the Editor's review gave it only three stars, I would have rated it higher. Voters there agree, it is rated 4.5 stars (out of 5) by 229 CNET users.
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.
- prev
- 1
- next
