Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1999-11-10
2003-10-07
Beausoliel, Robert (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
Reexamination Certificate
active
06631480
ABSTRACT:
BACKGROUND
1. Field of the Invention
The invention relates generally to computer systems that concurrently execute plural application programs on a preemptive multitasking basis.
The invention is directed more specifically to multitasking systems wherein a given application program may crash and for which it is desirable to limit the ability of a crashed application program to permanently alter data. The invention is directed even more specifically to saving data before it is damaged or destroyed by a crashed program.
2. Description of Related Art
Multitasking computer systems allow multiple application programs to execute in overlapping fashion so that it appears to a user that the programs run simultaneously.
Preemptive multitasking systems are those in which an operating system has supervisory control over the concurrently executing programs. The operating system limits the length of time that each given application program has for using system resources such as a CPU (central processing unit) or other data processing means.
Examples of preemptive multitasking operating systems include Microsoft Windows95™, Microsoft Windows98™, and Microsoft Windows NT™, all of which are available from Microsoft Corporation of Redmond, Wash. These operating systems also permit multi-threaded execution of programs. In multi-threaded execution, a program begins executing as a first, main thread and optionally generates ancillary threads that run concurrently and interact with one another through exchanges of semaphores and other methods.
During execution, a given application program may encounter an unexpected problem which halts normal execution either in a main thread or an ancillary thread. Such problems are caused by: (a) a program attempting to access restricted (privileged) or unavailable areas of memory, (b) a program making calls to unavailable system functions or services without the ability to handle such unavailability, (c) a program jumping into a nonsense stream of execution code, (d) a program invoking a no-time-out wait for an event that never occurs, (e) a program entering into a deadlock embrace, and so forth. This is a nonexhaustive list of possible causes.
When such execution-halting events occur, artisans sometimes refer to the halted program as being “stuck,” “frozen,” “crashed,” or as having encountered a “fatal error.” Different flavors of these terms are sometimes associated to one class of cause as opposed to another. In this application, “crashed program” will be generically applied to any and all situations in which a program encounters an unexpected problem halting normal execution, irrespective of the exact cause and irrespective of whether the unexpected halt is permanent.
The user (e.g., novice user) of a computer system typically does not care what has caused a program to crash. Such a user instead generally recognizes the “crashed” condition as an apparently sudden refusal by the given application program to respond appropriately to keyboard strokes, mouse clicks, or other user interface interactions such as voice commands or hand gestures. The user may also be notified by the operating system that a crash has occurred.
The presence of a crashed program does not generally pose a major problem to the overall operations of a preemptive multitasking system. In such systems, other concurrently-executing application programs can continue to run in normal fashion even though a given application has actually crashed (as opposed to situations where the program is fine and the user merely believes it has crashed). The user continues to have access to operating system services and to the resources of other non-crashed application programs running on the computer. For example, in a Windows95/98™ environment the user may hit the Alt-Tab key combination to switch to another task. The user may choose to simply end the tasking of the crashed program and thereafter restart the program afresh from its basic start-up state.
Sometimes, this close-and-restart-afresh option is not an attractive one for the user. The user may have failed (or the user may merely believe that the user has failed) to save a segment of work performed with the crashed program to nonvolatile memory (e.g., to hard disk) before the crash occurred. Closing-and-restarting the crashed program afresh may mean that the unsaved work will be lost forever. Many hours of work may have to be painfully redone to reconstruct the state of the program just before it crashed. In some instances, the pre-crash state of the application may represent non-replicatable work product such as data that had just been captured and/or transformed in real-time.
To remedy this predicament, various unfreezing techniques have been developed. These techniques attempt to revive the crashed program at least to a sufficient level such that unsaved work product may be accessed and saved either wholly or partially. Examples of such unfreezing techniques include those disclosed in the above-cited patents and patent applications.
No currently known revival technique is one hundred percent effective for all possible forms of application programs. One may make an analogy to attempts to revive a human patient by CPR (cardio-pulmonary resuscitation) after the patient suffers a cardiac arrest. In some cases, the patient is fully revived. In other cases, the patient is revived but still suffers from serious complications. And in yet further cases, even heroic attempts to revive the patient regretfully prove unsuccessful. In so far as reviving a crashed application program is concerned, the end goal is not to keep the application program alive and working as long as possible, but rather to keep it alive long enough so that vital, but still unsaved, work product can be saved.
Various “unfreezing programs” are known in the prior art to monitor the execution of applications running on a computer and detect possible crashes of those applications. When a crash is detected, various unfreezing techniques are employed by such unfreezing programs to return crashed programs to at least partial, or full operation. One such commercially available unfreezing program is CrashGuard™ available from Symantec Corporation of Cupertino, Calif.
After an unfreezing program attempts to revive a crashed application program, the crashed program may resume operation having complete, limited, or no functionality. In addition, the crashed program may perform operations improperly, despite the appearance of proper functionality. The following discussion refers to a crashed application program subject to an attempted revival by an unfreezing program as a “crashed program”, regardless of whether the crashed application program is successfully revived to any extent.
The degree of functionality present in a crashed program is particularly important with respect to data modification, storage, and retrieval. If aspects of a crashed program's user interface are corrupted, then the user may be unable to reliably perform important data manipulation operations. This may prevent the user from saving valuable work product. Alternatively, the data storage functions of the crashed program may not return to their normal pre-crash operation, despite the appearance of a fully functional user interface.
This second situation is particularly dangerous since commands, however initiated, to perform simple data manipulations may inadvertently corrupt or overwrite valuable data due to the abnormal operation of the crashed program. For example, a command to save a newly edited copy of a file may cause the crashed program to overwrite the previous version of the file with erroneous, useless data. Thus, there is a need to protect against data loss caused by the operations of a crashed program revived to less than complete functionality.
As mentioned above, various unfreezing programs exist in the prior art. However, the methods utilized by these prior art programs do not necessarily protect a user's original pre-crash data from damage caused by file changing operations attempted by a crashed p
Elliott Scott
Zeigler Art
Beausoliel Robert
Bonzo Bryce P.
Fliesler Dubb Meyer & Lovejoy LLP
Symantec Corporation
LandOfFree
Methods and systems for protecting data from potential... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Methods and systems for protecting data from potential..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Methods and systems for protecting data from potential... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3173633