An experimental design study was done to investigate three research questions: (1) Can a software system be developed that will provide recovery from a system failure? (2) What problems exist in achieving a software-only recovery system? (3) What is the degradation in application program performance when utilizing a software recovery system?;A software was developed for recovering data that was in memory before a catastrophic failure. It allows for memory retrieval after unfortunate incidents such as keyboard lock-up, software failures, and power outages. The software, named CRAM, (Constant Random Access Memory) operates by using Undocumented DOS functions, memory management tools, disk management, context switching and the timely backup of the system to the hard disk. The main task of CRAM is to operate in the background of the computer, transferring the computer system's memory to disk at specified intervals of time, with limited interruption of the foreground process;Most of the coding was done in the high-level language "C". Some codes were done in assembly language to access low level interface to DOS that were either not available in "C" or provided better data access speed. The most interesting and challenging part of the project was context switching during restoration of the system's memory. Restoration was accomplished through the ingenious use of the information stored in each program's PSP and data in the DOS swappable Data Area. Saving and restoring of data was accomplished by utilizing DOS hardware and software interrupts and replacing some of these routines with new code that do some operations that are specific to CRAM while also allowing other programs to have access to the original routines. The major interrupts used by CRAM are the keyboard interrupt (9h), the clock interrupt (1Ch), and the DOS idle interrupt (28h);The software was tested and analyzed for conflict by executing nine commercial programs. It was noted that about 75% of the time the system was restored and 33% were full restoration. Another analysis was done for the speed degradation. A degradation of 3.3% for the sieve numerical calculation, 1.3% for the random number generation, 5.2% for the disk I/O write operation, and 10.6% for the video display operation was observed. Less than 1% change was noted for most of the other operation except for times when CRAM's presence may delay the clock interrupt by 0.05 seconds.