Primary Troubleshooting Questions

Good troubleshooting relies upon on a reductive approachisolating the source of the problem by eliminating its possible causes. This is done step-by-step, working from the most likely to the least likely cause.

Like any good detective, your first job is to ensure that you actually have a problem by eliminating any outside or unrelated factors that might have influenced your computer at the time the unexpected behavior occurred.

Before you begin methodical troubleshooting, there are three primary questions to ask: did it work before, did you check the documentation, and can you repeat the problem?

"Did It Work Before?" or "What Has Changed?"

Perhaps the most important question to ask is whether the issue existed in the past or if this is a new issue.

If, for example, you are using a new feature you've never used before, that's a likely source of error. The fastest way to correct it is to check the user's manual to make sure that you are using the feature properly.

If you are using a feature that you have used in the past, then you have a frame of reference. Ask yourself if anything has changed since using the feature last. In particular, have you added, changed, or removed any software or hardware?

If everything seems to be completely in order, perhaps something less obvious has changed. There are many circumstances to consider in any workflow. You might be working with higher- or lower-resolution media (DV as opposed to HD, for example). Perhaps previously you were working on very short projects with minimal hard drive requirements, but now you are working with hour-long sequences and larger amounts of media. Perhaps you have never worked with Photoshop multi-layer images before. There are always differences between any two given projects, and careful consideration of those differences will often clarify where the new problem developed.

Note

It's a common-sense rule that you should try to avoid upgrading critical software or hardware while in the midst of a project. Innocent-looking software updates that appear a week before you deliver a big project can upset your entire system. It's safest to wait until you are between projects to upgrade any hardware or software in your system.

Similarly, avoid any unrelated software installations. If you must install other software, then keep good records, so that at a glance you can see the correlation between installs and problems. For instance, your list may show that you installed a new anti-virus utility last week, and now FCP will not autosave. It's important to keep good records in any situation where more than one person is an administrator on a single station.

"Did You Check the Documentation?"

The Final Cut Pro user's manual contains a wealth of documentation that thoroughly cover how the application works. Nobody likes to read software manuals, but doing so will make it far easier to use FCP effectively, avoid known issues, and adapt your workflow early in the game when you encounter unexpected problems.

Final Cut Pro Help provides quick access to FCP documentation, including the user's manual, late breaking news, and new features.

Other great resources are the Apple Final Cut Pro Support page (www.apple.com/support/finalcutpro/) and Apple's Weekly Knowledge Base changes email list (www.lists.apple.com/mailman/listinfo/weekly-kbase-changes). Both resources make it easy to stay up to date on the latest technical information about your products.

Checking any or all of these resources for reports of identical error messages or symptoms is often the fastest way to your solution.

"Can You Reproduce the Problem?"

In the rare event that you uncover inexplicable behavior that's not described in the manual or online support documents, your next step is to make sure that the behavior you're encountering is consistent and repeatable.

As you attempt to repeat the behavior, write down each step you take. Try not to add variables to the process as you test the behavior, because it's important to demonstrate repeatability when determining the causes of your problem.

It's an unfortunate reality that some issues occur intermittently, and so are hard to reproduce. This can certainly be frustrating, and can indicate that what appears to be a small issue is larger in scope. But the repeatability rules still apply, and you need to be able to demonstrate what elements were in play when you encountered the behavior.

Document Your Investigation

This is the other side of documentation: the documentation that you keep as you troubleshoot. In order to keep yourself and any other troubleshooter on a logical path to solving problems, you have to document your investigation.

When troubleshooting, it's easy to become confused and repeat irrelevant steps or miss an important factor that would have been obvious had you been looking at it on paper rather than simply trying everything you can think of. If anyone else is working with you, your notes help to eliminate redundant troubleshooting.