Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
2000-05-15
2003-09-30
Beausoliel, Robert (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S026000, C714S046000, C714S057000
Reexamination Certificate
active
06629267
ABSTRACT:
TECHNICAL FIELD
This invention relates to software program modules. More particularly, this invention relates to a method and system for detecting a failure in a program module and reporting the failure to a central repository for storage and analysis.
BACKGROUND OF THE INVENTION
Despite the best efforts of software developers, software programs inevitably fail at one time or another. One type of failure is a crash. A crash occurs while a program module is running and results in the suspension of operation of the program module. Crashes are frustrating to users and, in some cases, may cause the user to lose work. Another type of software program failure is a set-up failure. Set-up failures occur during installation of a program module onto a user's computer. Set-up failures may prevent certain aspects of the program module, or even the entire program module, from being installed on a user's computer.
Crashes and set-up failures create a significant amount of work for product support personnel. Product support personnel, typically contacted via telephone, are often limited in their ability to diagnose problems due to the limited amount of information they can receive from the user. For example, the product support personnel may only know what the user was doing when the crash occurred or at what point of the installation the set-up failure occurred. There may be a significant amount of information on the user's computer that may be useful to the product support personnel or to the software developers to diagnose the failures. However, because product support personnel and the software developers are not physically present at the user's computer, this information can not be extracted and analyzed.
To gather more information about a crash, different approaches have been taken. For example, America Online has the ability to determine the location of a crash of Microsoft's “INTERNET EXPLORER” web browser and report this information to Microsoft. However, other information regarding the state of a user's machine at the time of the crash is not known and it is difficult to distinguish between different crashes. Without this valuable information, not much can be done to determine whether there is a bug and, if so, correct the bug. Other approaches have been taken to tackle the problems of failures. For example, Netscape's “COMMUNICATOR” web browser includes a quality feedback agent to report a crash to Netscape, although it is not known what information is reported to Netscape. Moreover, both of these approaches apply to fatal crashes, i.e., when the operating system has decided to kill the application. Thus, there is a need for a method and system for reporting non-fatal crashes, such as when the operating system continues executing the application's code.
Thus, there is a need for a method and system for extracting from a computer relevant information regarding a failure of a program module, including the location of the failure, and transmitting this information to a software manufacturer so that the failure may be diagnosed and corrected. There is also a need for a method and system for requesting information from a failed program module, in addition to the location of the failure, and transmitting this additional information to a central repository for storage and analysis.
SUMMARY OF THE INVENTION
The present invention satisfies the above described needs by providing a method and system for reporting program failures. A failure may be a crash of the program module or a set-up failure during installation of the program module. Additionally, the failure may be a problem encountered during in-house testing of the program module. Once detected, the program failures may be reported directly to a repository, such as a server operated by the manufacturer of the program that failed. The repository may also be a local file server operated by a corporation. For example, the corporate file server repository may be used to store the failures encountered by users in a corporate environment until these failures may be reported to the software manufacturer's server.
After a failure is reported to the repository, such as a manufacturer's server or a local corporate file server, additional data may be requested regarding the state of the user's computer and the program module that failed. This additional data may be used to develop a fix to the failure to improve the performance of the program module.
In one aspect, the invention comprises a computer-implemented method and system for dealing with a failure of a program module. After the failure is detected, the user is presented with a dialog box asking whether the user wants to report the problem to the manufacturer of the program module. If the user chooses to report the problem, then a failure reporting executable sends the location, or other identifying information, of the failure to a repository. If necessary, the failure reporting executable may also report additional information about the failed application program module to the repository. The repository may then provide a fix to the failure if one is available.
In another aspect, the invention determines there is a failure in an application program module. In response to a determination that there is a failure in the application program module, a location of the failure is determined. The location of the failure is sent to a repository. The location of the failure is compared to a number of prior reported failures stored in the repository. If the location of the failure matches at least one of prior reported failures, then it is determined whether there is a request for additional data stored in association with the matching prior reported failure. If so, then the requested additional data is located in the application program module and transmitted to the repository for storage. This additional data may then be used by developers to diagnose the failure and provide a fix to the failure in the future. If the location of the failure does not match any prior reported failures, then the failure has been unreported and a new entry is created in the repository for the failure.
These and other features, advantages, and aspects of the present invention may be more clearly understood and appreciated from a review of the following detailed description of the disclosed embodiments and by reference to the appended drawings and claims.
REFERENCES:
patent: 5193178 (1993-03-01), Chillarege et al.
patent: 5790780 (1998-08-01), Brichta et al.
patent: 5928369 (1999-07-01), Keyser et al.
patent: 5944839 (1999-08-01), Isenberg
patent: 5948112 (1999-09-01), Shimada et al.
patent: 5974568 (1999-10-01), McQueen
patent: 6029258 (2000-02-01), Ahmad
patent: 6357019 (2002-03-01), Blaisdell et al.
patent: 6381711 (2002-04-01), Chiang et al.
patent: 6412082 (2002-06-01), Matsuura
Glerum Kirk A.
LeVine Eric A.
Oosterhof E. Peter
Ruhlen Matthew J.
Beausoliel Robert
Merchant & Gould
Wilson Yolanda L.
LandOfFree
Method and system for reporting a program failure does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for reporting a program failure, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for reporting a program failure will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3057112