Troubleshooting

Scott L. Barber first posted this to Quadlist. It is reprinted with his permission.

This is a long post but it is relevant to many of the problems we have discussed recently. I would also be interested to know if people agree with what this [Apple] tech has to say.

You've posted quite a little gem - I'm not being sarcastic. There are addendums, or ways that I normally operate, that work a bit against this exact strategy, but in the end I'm assuming the very path this tech describes. I'll include my comments within the document, and summarize at the end.

Extensions troubleshooting worked 56% of the times tried.

Clean installs worked 28% of the times tried.

Disconnecting SCSI Devices worked 21% of the times tried.

This is certainly the correct method, which is one of the reasons I require the use of Conflict Catcher on client machines. Extension elimination can be a tricky process, and Conflict Catcher often finds "order of loading" issues or simple conflicts that I can not intuitively guess. When I'm on site and have used my intuition with no avail, I run conflict test. It's something I always end up learning from. I will note however that while Conflict Catcher is an excellent troubleshooter, it has a tendency to isolate the wrong problem. (The problem being with QuickTime VR, or something, but really QuickTime, since Conflict catcher disabled QuickTime loading but left VR running. Extension management is an excellent tool, and extensions are usually the problem. A clean install is another matter. If several problems are occurring frequently, then linear troubleshooting through Conflict Catcher may not be the answer. A manual clean install, with insertions of extensions until a problem occurs can in these cases be faster than fighting through Conflict Catcher to get the answers.

Disconnecting SCSI devices works only if there are problems that might be SCSI related. It is a wonderful place to start, to address driver conflicts right up front, so that you are completely sure that there isn't a hardware issue that wouldn't be immediately noticeable while searching for a software solution.

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.

I agree for the most part. Which is why I operate in just the opposite manner. Very rarely these problems rear their ugly heads - it's much better to have a step by step program that eliminates these questions right away, so that you know these rare issues are not the mystery problem. I'll go into this later in the summary.

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.

Until recently, this has been true. But there are specific problems in the current OS line concerning stuck monitor/sound settings, and issues with the Apple Shared Library Manager, that have been popping up lately on the list. Those issues are almost always problems with preference file corruption or redirection.

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.

Summary

For years, Apple has been rebuilding desktops and zapping PRAMs needlessly. More to get people off of the phone and hopefully get another tech the next time around (IMHO). It's usually the bane of last resort when the technician has no other options, is frustrated with the customer, and just wants to go home that night (again IMHO). Because of this policy, I've adopted a different attitude with my clients. Of course, this has changed over the years and with some clients in some ways, but generally it's a good rule of thumb. Bear with me.

Preparing for a problem that has no simple solution is like diagnosing a car problem over a mobile phone. The technician has little knowledge of your system, how you use it, what programs are on it, and other crucial pieces of information. When I get a call that I know that I'll have to dedicate 20 or 30 minutes of phone time to, I routinely have a preparation checklist before even moving into the diagnostic steps - i.e., I tell the client that we're going to do some preliminary checks of the hardware to make sure that the problem is not a hardware issue that cannot be solved in software.

First, there are simple checks that you can make with PRAM to tell whether the PRAM is "stuck" or corrupt so that it cannot be changed without a wipe. I have the client go into their memory control panel and change the cache setting one level, either up or down, and reboot. If the value sticks, then the PRAM is usually fine.

Second, address any external SCSI devices. Are the problems occurring on a single external device, or are the problems with the internal drive. If internal, I simply have the client shut down the machine and remove the SCSI connector from the back of the machine, just to be sure there isn't ground fault with the external devices, or any errant termination issues we'll have to consider later. Third, and this is becoming more common with my clients, bad modems/printers, shorted LocalTalk connectors, etc., can cause a port failure condition that affects both ports. Unless the connection is necessary to recreate the problem, I have them remove these as well. With these devices removed, I then have the client check to see if the problem still exists. If so, then Disk Tools is used to check the drives quickly and easily.

Third, given the chances of misdirection and preference issues, I have the client rebuild the desktop through a restart-Command-Option combination. This rebuild can take some time, usually not more than 5 minutes, which gives the user ample time to absorb the steps that I'm about to take to start diagnosing the potential software problem that we're narrowing down to. I've had no complaints about this process - it's well explained - and can avoid hours of painful phone diagnostics if the problem is hardware.

Now, for the first step of software diagnostics. The view that I take is that after assuring that hardware conflicts aren't the answer, determining whether the machine has OS problems, or simply applications problems, is the next step.

Step 1: Delete specific preferences that are known to corrupt and affect the System software specifically. Our attempt is to discover whether the symptoms can be narrowed down to a single program, or simply that the damaged OS might only be showing up in this particular software at this moment, but will expand to other programs down the line if not addressed. The following preference files are examples of preferences that can routinely be wiped without any real adverse affect on system performance. Perhaps a few settings might need to be reset when the diagnosis is finished, but these are easily done through control panel settings, and do not necessarily have to be done immediately. Additionally, this helps to insure the client has a stable and working OS when future problems might arise, so that they can concentrate on application specific problems in the future. Examples of the files I routinely dump are as follows.

AppleShare Prep - this file can easily be corrupted, or mispointed, when a person locks startup access to a machine that no longer exists in the office. Problems such as these cannot easily be fixed without a preference dump, since to change the locked startup volumes you must be able to reconnect to the missing server to turn the options off.

AppleTalk Prefs - this file determines whether ARA, Ethernet, Printer,or Modem port is used for networking, and can sometimes be locked in a specific position. Additionally, if the machine exists on a network of more than five machines, it may not be able to choose a new node number from an unused set. Throwing this away, and resetting the preferences is another good purge for networking issues.

ASLM preferences - this file is the most common file I trash, and it always assists in diagnosing conflicts within the system software. The Apple Shared Library Manager keeps a list of loaded and unloaded libs in this file, and can sometimes due to improper shutdown or powerloss be corrupted, so that libs are reported in use when not necessary, or older libs that are no longer available to the system are suddenly flagged active. Removing this file resets the ASLMs, and allows them to re-catalogue the libraries on the next reboot in a clean format.

Connectix folder/Speed/RAM Doubler preferences -- depending on the version of SD or RD you use, you may have one or all of these files in your preference folder. It is very possible during reboots while extensions are loading for the SD cache file to become corrupted and work improperly. Additionally, this file can become fragmented as Speed Doubler settings are changed. Deleting this folder/file combination allows SD to restart cleanly. RD also has a cache file (sometimes) which serves as it's VM file. This file has the same problems as mentioned, and can easily be removed without issue. Oh, perhaps you'll have to reset your memory bar in RD, or turn on/off features in SD, but that nuisance is minimal compared to the security of knowing that SD and RD are working correctly.

Display/Sound preferences, and the Monitors & Sound Preference folder - This has been a long standing bug in Apple's display software, just finally patched in v1.6, which 68k users cannot install. Therefore, it's a good idea when dealing with stuck video settings, or unchangeable sound settings, to remove this entire combination of files and folders, and restart from new. The old method of setting these things lie in the Display Preferences and Sound Preferences files. When Apple switched over to the Monitors & Sound control panel, they relocated to a folder of the same name in the Preference folder. The problem was that default tags within the OS itself searched for the two files - Display and Sound preferences - when booting up, and used them as default settings. If they existed, and were different than the M&S settings, they still stayed default. This allowed a user to change their M&S settings, and work through a session, but upon reboot the settings would return to the defaults in Display and Sound preference files. Apple worked with this problem for years, and decided to have M&S write to both are as as a solution, but if M&S cannot write new prefs to either the Display or Sound file for some reason (locked, damaged, etc.) you will still not be able to make changes.

Embedding Preferences - this file is used to help Microsoft software find helper applications, such as MS Graph and word converters in the system folder. Deleting this file forces the Microsoft software to rebuild the pointers on reboot, taking the information on location and use from the newly rebuilt desktop database (see, I'm thinking ahead). If you have trouble with Microsoft Office or IE problems, this can be a quick assurance that the system software isn't involved in your particular problem.

Expansion Manager prefs - this file just came around in the 8.x or 7.6x revisions, and is used by the system software. Anything that calls itself an Expansion manager sounds suspiciously like it could be damaged during different types of OS crashes. Since it isn't an installed preferences with the system software, but is created on the first bootup, I have no problem with trashing it and forcing an OS build of it. If we're going to clean up the OS, we might as well do all of it.

File Sharing (Folder) - this folder keeps all of the file sharing information about volumes that have been mounted and shared, including CD ROMs. If you have file sharing on, every disk you've ever inserted with FS active will be listed in this folder. This can increase the time that file sharing takes to load up, since it polls for each of these drives when starting up because they're registered with FS. Eliminating this folder and allOwning arebuild on startup can not only help stabilize network startups, but also reduces the "cache" effect of this folder - if it gets too large, the chances of directory corruption become higher. And we don't like directory corruption and fragmentation within the system folder.

Finder preferences - Finder prefs are the second most damaged preference file, especially in OS 8. Since the finder has really been reduced to an application instead of an interface, it's much more susceptible to wierd memory conditions causing it to crash. Unfortunately, when it crashes, it often lives in a reload cycle, constantly reloading and crashing. Removing the finder preferences allows the finder to adapt to the environment that it might be crashing in. A common problem exists with Adobe software that installs Type Manager and Type Reunion, as well as all of the other extensions that a program might add, which radically changes the system size and heap on the next reboot. Since there are parameters of working memory sizes within the finder preferences file, it's common that the installation of all of these extensions suddenly can cause the finder to be unstable with it's default settings. Removing this file helps the finder adapt to the new normal system requirements. Finder preferences isn't always the problem, but is often helps stabilize the eventual solution.

Mac OS Easy Open Preferences/PC Exchange preferences - this program, combined with the listings in the Desktop DB, helps child files find their parent applications, or find other foster parents to open them with - an example is copying a Word document to a machine with only ClarisWorks. Mac OS Easy Open helps find ClarisWorks and determine that it MAY be able to open this type of file. Usually this gives a popup window asking the user to choose a program from a list to open the file with. But often a simple click of the wrong line sets Mac OS Easy Open to always default that file type to the chosen program, which may not be wanted. The only way to reset this directional mechanism is to remove the preferences. (Oh, you could use the control panel and hit the delete button, but who trusts that thing?)

Netscape Prefs, the following files - (Netscape Registry, Pop State,Global History, MagicCookie, Cache folder) - these files can wreak all kinds of havoc when Netscape crashes hard. In fact, most type 2 and type 11 errors while Netscape is active are due to corruption or improper settings within these files. Dumping them forces a rebuild, but barely affects the user. It does not lose their Netscape settings, only previous links in pages, any cached pages in the cache folder, etc.

PPC Registration Database/Registration Database -- another cleanup like Expansion preferences . . .

Translated Documents - any file converted via most of the conversion software - QT, QD, Easy Open, PC Exchange, etc. . . . uses this folder as a temporary copy of the file. Unfortunately, this folder can get huge, but is never dumped by the system software (just in case you need a copy of the converted file later on?). Big stupid waste of space. Dump it.

Web Sharing Folder - very rarely is it used, but it has the same tendencies as the File Sharing folder -- lots of files leading to corruption.

This has a sincere tendency to clean a considerable amount of the OS up, and helps assure that the OS is stable. from this point, you know you're dealing with extension conflicts or application problems. The worst case scenario when doing these types of diagnostics is that a wealth of extensions or applications might be better solved by doing a clean system install and copying resources into the system folder until the problems are reproduced. This final method also insures that the Finder System, and other Apple extensions haven't been damaged.

Scott L. Barber <serker@earthling.net>

Pres/CEO, SERKER Worldwide, Inc.

Providing Hardware/Networking/Telecomm for 13 years

Quadlist, the listserv for users of 68040-based Macs. FAQ at <http://lowendmac.com/lists/quadlist.shtml>