When Bad Things Happen to Good Computers
Why doesn't Apple just FIX THIS THING!!!
(or "When Bad Things Happen to Good Computers.")
by Tracy Valleau
One of the most frustrating things for computer
users is the installation of a new piece of software... that
doesn't work, or worse yet crashes the computer.
The swear words are often enough to embarrass
the most savvy sailor.
These are usually followed by the posting
of letters maligning the software, the publisher, the programmers,
the computer manufacturer; and any other nearby and convenient
"Why doesn't (name) just fix this?"
is the usual plaintive whine.
Well, here's why: because "just"
There are only a few things that can
cause software to misbehave: 1) hardware failure; 2) programmer's
error; 3) software conflicts; 4) input or user error.
Hey: if your hardware is broken, well
- fix it. There's nothing the software is going to do to repair
your broken hard drive.
However, in this category, there is one
insidious hardware/software problem that must be mentioned: the
file tracking done on your hard drive with drivers.
All your software is stored on your hard
drive, just as a collection of short stories is stored in a book.
To find a given story, you consult the
table of contents, and it directs you to the proper location
(page) in the book. You start reading, and when you finish one
page, you assume that turning the page will take you to the next
words in the story.
But suppose that there was a printing
error, and you're 12 pages into "War and Peace" and
turn to page 13, only to discover that page 13 contains the 33rd
page of "Skippy the Bunny!"
In essence, this is what happens when
the computer hard drive's directory gets corrupted.
In fact, it's much more complex than
that, since, instead of each page following one on the other,
a computer has to return to the table of contents (so to speak)
to find out where the next page is, just as if you ripped out
all the pages of "War and Peace," threw them up in
the air and then gathered them back together in totally random
order. (This happens on a drive because you save and delete things
of different sizes, leaving bits of a file scattered in different
If that "trail" of page after
page gets even one page out of order, then the program crashes
because it loaded in the wrong thing, and when it goes to work
on it or to use it, what it expects to be there is something
If you put on a parachute, boarded a
seaplane and jumped out, you'd be in deep trouble if you did
so before it took off, because instead of the air you expected
to be falling through, you'd be in over your head in water.
Same thing with a computer program: if
it expects to find one thing, but finds another because the directory
was wrong, and it loaded in something else - you get "the
How do you prevent directory corruption? Well,
if you crash, or notice anything suspicious, take the time to
run a directory repair program. The longer a corrupted directory
is used, the more corrupted it becomes.
Other problems related to hardware, including
loose cables, failing power supplies, bad RAM, drives on their
last legs and so on, can all cause problems that show up in your
software. (Power supplies and hard drives both have maximum life
of about 5 years, give or take.)
Programmer's errors not only do occur,
but it is an axiom in the trade that there is no such thing as
bug-free software. Why? Simply because you'd have to check at
every single line of code for every single possible contingency
to cover all your bases. That would produce code so bloated that
no machine could run it; so expensive that no publisher could
afford it; and so impossible on the face of it, that it could
never be done (since it would require that once the software
was written, all change in the universe come to a complete halt,
so that no different contingencies would ever arise.)
So, programs are written to cover all
the most common problems and foreseeable errors. But even this
has to be weighed in the light of reality. One recent iteration
of a popular operating system was released with 22,000 known
bugs! (That doesn't include the probable doubling of that number
in unknown bugs once a few million users started mucking about
with it on a few million different machines, either!)
Hey! We're all human, and programmer
errors do happen, although languages such as C++, and the use
of libraries of prebuilt and pre-debugged code have gone a long
way toward cutting that source of errors down.
There are reasonably sophisticated automated
debugging tools which encapsulate each line of code, and can
track down such mysterious things as "dangling pointers",
and "undisposed handles" (ways that programs access
Good code will "TRY" a process,
and if it doesn't work, "CATCH" the error. Problems
caused by programmer error are now WAY down from the early years
of personal computers.
So, software problems come down to true
errors (the programmer used an "add" command when he
should have used "multiply" for example (which no software
debugging tool can detect) and "bullet-proofing" -
trying to keep the unforeseen from totally messing everything
This last is the most common problem,
exacerbated by the fact that there are no two computers alike,
except as they come off the assembly line. We add software, create
documents; hang new hardware off it; add memory; update the operating
system; customize the desktop; and so on. Honestly, the fact
that most software runs as well as it does on 99.9 % of the machines
in the world is nothing short of amazing. (Which is of little
consolation when it's you that is the remaining 0.1%...)
We're about to see what that means when
it is you that's affected.
Software "conflicts" are by
far the greatest single source of problems. In computer speak,
a process (much like in normal speech) is just something that
is going on. Running software starts a process; any software.
Merely starting your machine in the morning starts hundreds of
individual processes - some running the monitor; the keyboard;
the drives; managing the memory and so on.
A conflict is a case where some combination
of processes running on a given machine alters the state of that
machine to the point where one (or more) processes can no longer
Let me give you an example. Process ONE
wants to remember something, so it stores it in memory location
"A". Process TWO wants to remember something, and also
stores it in memory location "A". Process ONE now decides
it needs what it just stored, and so retrieves it from memory
location "A"... but now it's not what ONE stored there,
but what TWO stored there.
ONE then tries to use that retrieved,
and incorrect information, and, like slipping on the parachute,
instead finds itself under water. Crash.
Now, that is a crude and, with modern
systems and coding, unlikely example... but it's a perfectly
From the user's standpoint, his/her machine
ran "just fine" until s/he installed the software that
is Process TWO. Then the machine started crashing.
Must be the new software's fault, right?
Er... why? Maybe process ONE should not have
been using Memory location "A". Maybe process ONE is
the only software in the world that uses memory location "A"
except for process TWO.
You might report the problem to the publisher
of TWO, who might spend days, weeks, months trying to find the
problem, when, in fact, there is absolutely nothing wrong with
Now this example is one of the easier
kinds of problems to find, if you're willing to work with the
publisher to help him find it. You can simply try removing everything
and seeing if TWO continues to crash. (It won't, as long as ONE
isn't running.) When you finally run ONE, and the crash in TWO
happens, you'll have started toward finding the solution.
Where it gets hard is if ONE only uses
Memory location "A" because some other process has
made a change in the machine, requiring "A" to be used
instead of ONE's preferred "B".
Yes - that was supposed to confuse you.
If you're confused, and you're a thinking, adaptable human being,
you'll begin to see how a blind dumb machine following a fixed
set of rules, is prone to errors.
There is no "almost perfect"
in computers; no "nearly right." If things are not
perfectly set up, then bad things happen to good machines.
That is why the first thing a tech-support
person will ask you to do is to restart the machine in a known
good state, and then run the software to see if the problem still
exists. Starting to diagnose what is going on from any other
place is just plain impossible. (At least that's what happens
with most Macintosh diagnosis; with Windows machines, the problem
is multiplied several fold because of the intricacies of INI
and a few dozen other setup files that are modified each time
new software is installed.)
So, on the one hand, there's the possibilities
of an infinite variety of software, and on the other, an infinite
variety of machine configurations. And all it takes is one of
those to not be perfect under all circumstances.
Finally, you may have triggered the error.
Loading up a project incorrectly; telling the software that you're
using 48K sound when you're using 32K, and then saving the project;
switching from 32K to 48K in the middle of a tape; doing a forced
break out of a program when it's writing to disk; restarting
a program after a crash, without restarting the machine first;
and so on.
Finally, there's the one obvious one,
that applies, naturally enough, to everyone in the world except
you - read the instructions! Your expectations of what the program
should do, may not be what it's designed to do. That is not,
my friends, a bug.
The truth be known, of all the tech support
calls and bug reports a company gets, perhaps one in every 800-1000
is actually a problem with the software. Most often, it's "operator
error" followed, at some distance, by software conflicts.
Real life -
However, some bugs are real. Here's an anecdote
about finding one with Final Cut Pro 2.0.
The 2-pop board contained a couple of
references to crashes when logging material. The usual suspects
didn't seem to fix the problem. I noticed the problem myself,
and had logged on to 2-pop to see if I was alone, and discovered
that I was not.
So, as an experienced debugger, I started
off tracking it myself.
First, I restarted with only the recommended
extensions: no luck. (But that's where you should start, too!)
I adjusted the memory: no luck. I trashed the preferences: no
luck. I reinstalled the software: no luck. I looked at 2-pop:
I was intrigued. I next thought about
what was obviously different between 1.25, which worked just
fine, and 2.0, which crashed. The most obvious thing was in my
face: the Audio Metering window (AMW).
So I closed it... ... and the problem
Over the next several hours, I tried
that new-found technique under various system configurations,
and in every single case, closing the AMW fixed the problem,
and in every single case opening it caused the problem. At this
point I was pretty confident that I could post the technique
to the board, and did.
As a developer, I also posted the issue
to Apple's DTS (Developer Technical Services) bug board.
Within 90 minutes I had received a call
Folks, this was to be expected from a
quality software company - any such company, not just Apple,
because we had a reproducible problem, shared by others, with
a symptomatic relief that always worked.
Real problems, reproducible problems,
are something that programmers and publishers want to catch and
fix: it's only good business. It makes them money. No quality
publisher is going to turn down the chance to improve his product,
especially if it's malfunctioning! Really.
Compare that reproducibility with a tech
support call like this : " You sleazy &**$!!!'s! Your
software is worth %$#! I'm never going to buy your @#$! software
"What seems to be the problem?"
The lesson here is this: most people
DON'T have your problem with the software; it's a problem likely
unique to your machine. So, if you want tech support to help
you, don't count on them being mind-reading magicians.
Remain calm. REPRODUCE the problem and
write down the steps. Then, as a team, you and support can find
But I digress...
Apple, as I said, was very concerned
about the problem. We spoke on the phone several times and exchanged
dozens of emails. The folks at Apple were there until well after
closing on a Friday. We tried a several different things. But
no matter how much we tried, it always crashed for me and it
never crashed for them.
When Monday morning rolled around, they
were right back on the case. Between us, we tried reinstalling
the OS; installing as yet unreleased "OSen." I installed
MacsBUG and printed out stdlogs, showing the internals of the
problem. I hooked up different hardware.
All to no avail. Then, at Apple's suggestion,
we tried pulling the RAM, since I had 1.5 gigs installed. The
suggestion was that the RAM, or the new firmware upgrade, might
have caused the problem. (That is, it was beginning to look like
a hardware problem, since nothing I did, from clean system installs
on, seemed to make a whit of difference.)
With the hardware looming larger as a
possibility, I contacted the other person (Mark) who had the
crash, and we exchanged hardware setup information.
There was almost nothing in common: his
was a nice clean setup, while mine was a cluttered mess of things
- yet we both crashed. But I did notice one thing, and it lead
right back to Apple's RAM suggestion: we both had 1.5 gigs of
Mark tried pulling some of his RAM. He
also reset the memory allocations so that FCP would use most
of what was available as he did the RAM changes.
And the problem went away.
So: was it hardware?
The clue came when Mark reported back
that he had reset his RAM allocation (minimum and preferred sizes)
to 500000K and 800000K. Mine were set considerably smaller.
So I reset my sizes to match his... and
the problem went away for me as well.
So, there we were. The problem was related
to hardware, but was, in fact, a software problem, caused (most
likely) by an assumption made somewhere along the line in the
programming that an address in memory was in one memory bank
(one DIMM, as specified by the upper bytes of the address itself)
when, in certain specific circumstances, it was in another. By
resetting the memory allocations, we forced the memory to be
in the same bank, and the addressing error went away.
It took the concerted effort of many
people, at about 72 hours each, to find the problem and provide
enough information so that Apple could reproduce the problem
and eventually fix it.
What's to be learned from this anecdote?
For one thing - Apple IS listening and cares about the product.
They responded almost instantly, and stayed with it until the
problem was identified and fixed. But, without cooperation and
help from the user (me and Mark) the problem could have lingered
for weeks, or forever. Patience and perseverance prevailed.
So, when bad things happen to good computers,
here's what you can do:
Remain calm (not always easy to do, I know).
Try to determine if it's just something
on your machine:
a) is your software / project / document
set up correctly? Was everything just fine until your last effect
was added? If so, did the project file get corrupted somehow?
(Now you can see why backups are important, no?) Is the media
Did you recently add some new software?
Run an installer of any kind? Change your setup? Crash recently
(even when using some other program) possibly corrupting files?
Did you just defragment your drive? (This
is notorious for corrupting files - before you defragment a drive,
back it up!)
Mac users: try trashing the preferences
for your software; try rebuilding the desktop; run Disk First
Aid, or DiskWarrior or TechTool Pro. Restart with only the extensions
you need for the software - if that works, you've got an extension
PC users: try running Norton to verify
the directory structure. Other than that, I'd have to say : call
your IT guy, 'cause I don't know squat about how you'd find it
on a PC, outside of returning the machine to a previously known
good state, or uninstalling whatever you think might be the cause.
The point here, in both cases, is to
try to find the problem yourself first.
Why should you? Well, as we just say,
the odds are about 199 in 200 that it's something particular
to your machine's current state, and finding it and fixing it
yourself will get you up and running faster.
If you take these preliminary steps,
then if you need to call tech support for the product, you'll
be able to tell them that you've already done those steps, since
that's exactly what they'll have you do anyway.
When and if you do call, remember that
the guy or gal on the other end of the phone didn't write the
software, and isn't personally responsible for your particular
Remember that he or she has already be
berated, yelled at, cursed, vilified and threatened 84 times
today alone. So, if your goal is to solve your problem and get
back to work as soon as possible, consider this counterpoint:
be NICE. Overwhelm them with courtesy. Politely explain the problem,
and the steps you've already taken to solve it. Have all the
information at hand (such as your OS version; amount of RAM;
serial number of the product and so on.)
After 84 jerks, you'll be a ray of sunshine
- manna from heaven - such a delightful relief that they will
work with you until hell freezes over to resolve your issue.
This works for me every time.
However, if you do get someone who has
had one too many jerks, and is being rude to you, simply hang
up and try again. If it's a big company, you'll get someone else
on the second try. If you don't, then ask for a different tech,
explaining that you're being civil, and expect the same in return.
Finally, there's this - try some preventative
You don't expect your car to run forever
without oil-changes, refilling the tank and tune-ups; treat your
computer the same way. Don't load on every extension; utility;
enhancement; gosh-O, golly-gee-whiz doodad that comes your way.
Rebuild the directory every so often - not just when trouble
appears. Stay up to date with your OS - use the most recent version
(because it's likely to have fewer known bugs) as well as the
most recent version of your software (for the same reason).
Mac users can run their software updater
control panel; PC users - check the MS website for the latest
DLLs and system updates.
Be aware that this maintenance is an
ongoing process, and take the time to do it. Remember that software
(such as Final Cut Pro) is developed to take advantage of the
latest changes in the OS; and the OS evolves to provide bug fixes
and new features. In short, these happen in parallel, so don't
get out of sync here. Don't expect to run the latest software
on an old OS, nor a new OS with old software. If you do, you're
asking for trouble.
This is hardly an exhaustive treatment
of what can go wrong - there's 6 year old hard drives; bad removable
media; faulty cables; and a few zillion other things.
But with patience and logic and perseverance,
you'll be able to solve 90% of the problems yourself, and be
back up and running, even when bad things happen to good computers.
Copyright 2001 Tracy Valleau
About the author
programming computers in 1978, and is credited with one of the
earliest multimedia / hypertext programs (1988). He is currently
the CEO of Digital Light Studios, Inc., a multimedia and consulting
firm whose clients have included McGraw-Hill, Sony, Apple, Silicon
Graphics and others. Mr. Valleau can be reached at tracy@DigitalLightStudios.com.