In my line of work, we see a lot of support tickets that go along the lines of “some application stopped working.” These can be frustrating, because the user is often more familiar with the application than you are. Fortunately, there are often some easy steps that you can take initially. Many applications store user-specific configuration information in what are known as “dot-files” — files or directories that begin with a . and live in the user’s home directory. If the application produces a dot-file, the first step you might try is to have the user rename the dot-file. For example:
mv .matlab .matlab-old
When the user launches the application again, the application will see that the dot-file doesn’t exist and create a new one.

What happens frequently is that a person reaches their quota, and the next time the application tries to write to the dot-file, it can’t and the file ends up getting corrupted. In some cases, you can recover some data from the old dot-file into the new dot-file (for example, Firefox bookmarks) by copying the appropriate file from the old to new directory. OpenOffice.org has a particular file that can get corrupted, but it can be fixed easily enough:
find ~ -name "Common.xcu"
This will give you a listing of all the files named Common.xcu in your home directory. To my knowledge, that particular filename is specific to OpenOffice.org, so you can generally do the finding and deleting in one fell swoop:
find ~ -name "Common.xcu" -exec rm {}\;
Another common problem is when environment variable aren’t set correctly. Many applications use environment variables to indicate the location of configuration and data files, and sometimes even executables. If you think an environment variable might be the cause, you can run the `printenv` command. This will give an output of the names and setting for all environment variables. Sometimes it is fairly obvious where an error is. For example, PGI might have been set to /opt/pig instead of /opt/pgi. Other times, a variable just is not set. The documentation for a particular piece of software will often list variables that need to be set.

Sometimes, the problem is that the software is being used on a platform it wasn’t designed for. Most of the computers these days have 32-bit processors, but a few have 64-bit. Sometimes, the 64-bit machines do not have the 32-bit libraries needed to run 32-bit programs (these are available through your particular package manager, like up2date or yum, but you may have to force it to use the 32-bit (a.k.a. i386) architecture). Or a person could be pointing to the wrong path. Some packages have both an i386 and an x64 (or other similarly named) directory, so it is important that the right one is specified.