Program Failures and Crashing

Mark Baines examines some of the reasons why programs don't work as they should and what you can do about it.

There are so many reasons why programs crash that I cannot describe them all here nor provide you with a panacea for all ills. What I can do is try to start you off thinking about what might be happening and what to do about it.
Reasons for failure

1. Corrupted program. If the program crashes at the same place every time it could be a bug but before complaining to the programmer use a backup program or make another copy from the master disk to work with.
2. Virus attack. Very unlikely on an Atari but see elsewhere in this issue.
3. Incorrect installation. If the program had an installer program and copied most of the files onto work disks or the hard disk for you, you may have made some incorrect assumptions when asked about your set up and the wrong files have been copied over. This can happen with programming language packages, word processors and DTP programs. Delete all the files and re-install the application.
4. Missing configuration files. Many programs need configuration files to store your default working parameters. Missing ones may cause the file selector to use the wrong path, for instance. Reconfigure the program and save the parameters.
5. TOS incompatibility. If the program is old it may not have been written with newer TOS versions in mind. See if a more up-to-date version is available. If you are using an old TOS, especially 1.0 and 1.2, then it is advisable anyway to upgrade to version 1.4 or preferably 2.06.
6. Hardware incompatibility. Some programs won't work with the BLiTTER chip switched on in a Mega ST or the processor chip cache on a Mega STe, for instance. If you have fitted any hardware modifications, such as a processor accelerator, monitor OverScan or serial port modification then switch them off and see what happens. If these hardware modifications use AUTO folder programs you may have to juggle them around in the AUTO folder. See below.
7. Incompatibilities with other programs. This is perhaps the biggest cause of program failure besides bugs. It is also one of the hardest to solve because it involves thinking about programs not immediately apparent, such as AUTO folder programs. There can be many AUTO folder programs and accessories in memory in various states of activity, some just waiting for an event to trigger them into further action.

   Installing AUTO folder programs is often problematic with crashes before the Desktop appears (an incompatibility between two AUTO programs) or during the loading or running of an application (partial incompatibility between two AUTO programs triggered when a particular event occurs in that application). Most AUTO folder programs are TSRs (Terminate and Stay Resident), that is, they run at bootup and stay in memory periodically performing some task or waiting for a triggering event. Several of these may be waiting for the same event or trying to access the same part of memory or TOS and may then come into conflict with each other.
   There is a proper way to write these programs and many earlier ones didn't do that and these tend to cause problems with more modern AUTO programs.
   Try to stick with modern software if you can.
   There are several ways to deal with these problems.
   

   • If the crash occurs before the Desktop appears then run a series of bootups starting with an empty AUTO folder and each time installing an additional AUTO folder program until the crash occurs.
   • The last program to be installed before the crash is the culprit, or one of them.
   
   This procedure is very tiresome unless you have a bootup manager like Superboot or XBoot.
   Otherwise, you will have to rename all the *.PRG file name extenders to *.PRX and rename one *.PRX to *.PRG before each reset!
   Another way to solve many of these AUTO folder incompatibilities is to change the order in which they load. This isn't the file name or date order but the order in which they physically appear on the disk. TOS 2, 3 and 4 show this order with their `View... No Sort' menu option.

   
   Later TOS versions include a `No Sort' viewing option but don't allow that order to be changed unlike NeoDesk and some other desktop replacements.

   Many replacement desktops, such as NeoDesk, also have this option as do most replacement file selectors. However, TOS and these file selectors do not allow you to change this order but the desktop replacements often can.
   AutoSort (from your favourite PD library) allows you to change the order that a program loads in the AUTO folder.

   
   AutoSort can reorder your files for you in your AUTO folder although it displays a limited number of files.

   
   Once you know which program is the culprit move it so that it loads before other programs or after them.
   Don't give up, it matter when system extensions such as NVDI, GDOS, file selectors, HSMODEM load.

   
   NVDI sometimes finds fault with some programs especially after quitting them. Just hit `Tolerate' or turn on 'TOS compatibility' in its configuration CPX or accessory if it happens too often.

   It takes time and a lot of booting up and often some compromises but do persevere.

   
   Accessories can also cause similar problems but these incompatibilities are quite rare. If you are still getting crashes with no AUTO programs then load each accessory file one at a time to find the culprit. Again, try changing its order of loading.
8. Bugs. The biggest culprit will always be bugs in the program code, something you have no control over and the hardest to track down.
   • Load the program into an empty computer (again a bootup program helps here), that is, one without any accessories or AUTOs.
   • If in doubt put a blank disk into the drive when you bootup.
   • Now test the program.
   • Does it crash at the same place or when you do the same actions?
   • If it does then you have probably found a bug.
   • Write down exactly what you did to create the problem and include this information together with your computer details in a letter or e-mail to the programmer.
   • Don't assume that no one else has reported it.
     A while back I became involved in a project near completion and reported a fundamental error which beta testers over the previous two years hadn't reported - I guess they all thought it was so obvious everyone else had done it!

PROFILE2 can give a full analysis of your computer - useful for programmers when trying to sort out your bug report. Floppyshop include PROFILE LITE on their catalogue disks to help them with client's software problems.

Bombs

• Most crashes result in the infamous series of bomb icons across the screen and are called processor exception errors.
• These are used by the processor and TOS to tell you that a serious error has occurred and which has most probably corrupted important parts of memory.
• The best thing to do it to switch off for no less than ten seconds and reboot.
• A reset isn't always ideal as it doesn't carry out a complete initialisation of the memory.
• Some programs will capture the crash and report some information to aid diagnosis of the problem.
• Again, this information may help the programmer when you report the problem.