Subject: troubleshooting methodologies
and their effectiveness
Date: Sat, 21 Mar 98
This is a message forwarded from an Apple System
Engineer to ATE's of which I am a member. I had
to removed the sender's email address because it
is not from a public forum.
Hope that you find it usefull.
--------------------------------------------------------------------------------------
Friends,
We have recently done an in-depth report of
troubleshooting methodologies and their
effectiveness. We would like to share the
results with you. This sample covers cases with
repeat (more than four) calls on the same issue
during an 8-week period, where the issue was
crashing and freezing.
Extensions troubleshooting worked 56% of the
times it was tried.
Clean Installs worked 28% of the time they
were tried.
Disconnecting SCSI Devices worked 21% of the
time that it was tried.
These are all valid troubleshooting steps
(they have a higher percentage of fixing a
customer's issue) To further clarify:
Extensions troubleshooting is the most widely
applicable troubleshooting step. It is
appropriate for any error type 1, 2, 3, 10, 11,
25 or freezing in addition to miscellaneous
wierd behavior. If the issue occurs on startup
or in multiple applications, this is the best
bet. If you're going to guess anything, guess
this. The corollary of this is: Don't ever
guess. If you don't know, troubleshoot. :-)
Clean Install: When all third-party hardware
and software have been eliminated and the issue
persists on startup or in multiple applications.
Reinstalling system software may be appropriate.
A clean install is not necessary if a
custom-install or easy install will fix it. If
you have narrowed down the issue to a certain
file or the issue seems only to affect a certain
component of the system software, you should be
able to quickly custom-install that item and fix
the issue. A custom-remove is also not, strictly
speaking, necessary before a custom-install.
There is a lot of recovery required after a
clean install. Many customers do not understand
how to recover from a clean install and this can
cause multiple callbacks. It's good to avoid
unless simpler steps don't fix it. At times it
is appropriate, but other times, it's overkill.
You can save a lot of time here by doing the
quickest thing to solve the customer's issue,
not the easiest. This will be easier to judge as
you gain experience.
Disconnecting SCSI devices. This step is
appropriate when a computer starts with a gray
screen and a pointer only and goes no further.
Random, hard freezes and recurring directory
corruption can also be signs of SCSI chain
problems. Many customers do not realize that ALL
SCSI devices must ALWAYS powered on BEFORE the
computer is started and then left on at all
times while the computer is being used. There
are no exceptions to this rule. This is
explicitly stated in every CPU manual put out
for the last two years. Customers often miss
this point and have chronic problems because of
it.
In contrast, the following troubleshooting
steps were shown to be tried way TOO OFTEN.
Rebuilding the Desktop worked 0% of the time
that it was tried. It was tried 54% of the
time.
Deleting Preferences worked 3% of the time
that it was tried. It was tried 38% of the
time.
Zapping the PRAM worked 5% of the time that
it was tried. It was tried 77% of the time.
From this we conclude that time spent
telling/helping customers to do these things is,
for the most part, wasted. In an effort to
provide relevant troubleshooting to customers,
please try to limit the use of these steps to
the following situations:
Rebuilding the Desktop should only be tried
to resolve generic file icons (but not the
generic chooser icon in Mac OS 8.1). A single
generic icon is often a file level problem (such
as a bundle bit), that rebuilding the desktop
won't fix. In rare cases, application/document
connection problems can be fixed by rebuilding
the desktop. (For example, you double-click on a
document and it opens the wrong application.
However, this Mac OS Easy Open does this same
thing by design.). This can easily waste several
minutes on a call, especially on the large
drives in newer computers.
Moving Preferences should only be tried when
an issue is isolated to a specific item (Finder,
control panel, application). Usually, the
program will crash on startup or the
application-specific settings fail to "stick"
when you quit the application. It is not
necessary to actually delete the preferences,
just move them.
Resetting the PRAM should only be tried in
cases where PRAM-resident settings are not
"sticking". These settings include startup disk,
keyboard control panel settings (repeat rate,
delay until repeat), sound level, memory control
panel settings (RAM Disk, Virtual Memory, Disk
Cache, 32-bit Addressing), mouse control panel
settings (double-click speed, tracking speed),
selected AppleTalk port, highlight color,
default printer, Date & Time Control Panel
(Time Zone, Daylight Savings Time ONLY), General
Controls (Folder Protection, Insert Blink, Menu
Bar blink ONLY), plus undocumented features.
Keep in mind that resetting the PRAM resets ALL
of those settings to their defaults and causes
the customer to have to reset any that he
customized. The following control panels are not
affected by zapping PRAM: Energy Saver, File
Sharing, Text, Numbers, Speech, PPP, TCP/IP and
many others.
Resetting PRAM can affect ADB and serial port
issues and little else.
As a reminder (and as I mentioned previously)
reformatting the hard drive should never even be
attempted unless Disk First Aid reports problems
that it cannot fix. Unless a bad hard drive is
suspected, a low-level format should also NEVER
be tried. Zeroing all data should also NEVER be
tried if the customer doesn't specifically ask
how to totally prevent data recovery.
You may feel free to forward this to your
agents. Hopefully increased awareness of the
futility of these things will reduce the amount
of time wasted on irrelevant troubleshooting and
decrease call durations. Limiting the disruption
to the customer's computer is also a goal. Do
only what it takes to fix the call, not
everything that it could possibly be. If logical
troubleshooting fails, it is probably better to
consult with a senior technician, rather than
spending that same time trying steps that are
statistically unlikely to work. :-)
I will be working on adding this to the
Golden Web, Mac OS section called "Good
Troubleshooting Style" which I may rename "How
(Not) to Troubleshoot" if I get enough
votes.
. . . . . . . . . . . . . . . . . . . . . . .
. .
