Microsoft Technology Licensing, LLC

Eric A LeVine

Matthew James Ruhlen

Kirk A Glerum

Steven Miles Greenberg

Michael Ronn Marcelais

Rob M Mensching

Charles Scott Walker

Brian T Hill

Eric B Fox

Reiner Fink

Kevin Lane Brown

Andrew L Bliss

Kevin Joseph Fischer

Jeffrey E Larsson

Benjamin E Canning

Ronald A Fein

Yi Meng

Thomas Scott Coon

Andre F Vachon

Gerald Francis Maffeo

William Hunter Hudson

Thomas W Saxton

Christopher Cameron White

Aaron Everett Erlandson

Jeff David Mitchell

Kshitiz K Sharma

Geoff Pease

Jing Shan

E Peter Oosterhof

A method and apparatus are provided for providing custom product support for a computer program based on levels of execution instability. The execution of a software program is monitored over a period of time to determine the execution stability of the program. Based upon the monitoring and upon one or more threshold levels of instability, the execution stability of the program is categorized. Based upon the categorization, custom program support may be provided for a user of the computer system executing the program. For instance, based on the categorization free or reduced fee product support may be provided.

Method, system, and apparatus for providing custom product support for a software program based upon states of program execution instability

A method for categorizing information regarding a failure in an application program module. The failure may be a crash, a set-up failure or an assert. For a crash, a name of an executable module where the crash occurred in the application program module, a version number of the executable module, a name of a module containing an instruction causing the crash, a version number of the module and an offset into the module with the crashing instruction are determined. This bucket information is then transmitted to a repository for storage in a database. The database may be examined to determine fixes for the bug that caused the crash.

Method and system for categorizing failures of a program module

A large portion of software bugs are related to hangs. Analyzing and diagnosing hang-related bugs involves capturing data from a hung program and extracting attributes from the captured data. Extracting attributes from the capture data provides a scheme to determine relevant characteristics of the hang. Moreover, the extracted attributes may be compared to known issues and, based on that comparison, a bug may be classified as known or unknown. Alternatively, triage may be performed on the client computing device in order to determine the potential cause of the hang event. Once the potential cause of the hang event has been determined, troubleshooting steps may be performed on the client computing device to quarantine it. Ultimately, if the hang-inducing bug is known, a user may be provided with a solution to the bug. Alternatively, if the bug is unknown, implementations of the invention send the captured data to be analyzed and fixed by the software's provider.

Automatic root cause analysis and diagnostics engine

Method and system for recovering information from open files during a failure in a program module. Once a failure is detected in the program module, control passes to an exception handler that determines whether the open files have been modified. If so, the open files are verified and stored as recovery versions of the files at the time of the failure. The program module is then terminated and restarted. Upon restarting the program module, the recovery version of the file at the time of the failure is opened and displayed to the user.

Method and system for recovering information during a program failure

Methods and systems for detecting and correcting computer software problems that cause an application program to crash upon startup are provided. Unsafe startup actions that are costly to initiate in terms of processor time and memory are handled by placing an unsafe startup action marker into the system registry prior to attempting startup. If an unsafe program module starts or boots successfully without causing the software application to crash, the unsafe startup action marker is deleted from the system registry. If loading the unsafe program module causes the application to crash, then startup actions, including corrective actions, are written into the unsafe startup action marker and are used on subsequent startup of the crashed application program to instruct the application on how to fix the problem. Other unsafe startup actions that are not costly in terms of processor time and memory are initially handled by an exception handler. If the application crashes as a result of such an unsafe startup action, then an unsafe startup action marker is written to the system registry as described above. Corrective startup actions are written to the marker for use by the application upon reboot.

Method and computer system for detecting and correcting a failure in a computer application program during startup

Method and system for reporting program failures. The system extracts information about a failure in a program module, such as the location of the failure, and establishes communication with a repository, such as a server. The information about the failure may be used to search the repository to determine whether the particular bug that caused the failure has already been fixed. If so, then the system assists the user in downloading the fix (such as by pointing the user to a particular website for downloading a service release). If a particular failure has not been diagnosed and corrected, then additional relevant information from the user's computer may be uploaded to the repository to provide the developers of the program module enough information about the failure to diagnose the bug and fix it (in a service release or in a later version of the program module).

Method and system for reporting a program failure

A method and system for injecting an exception into a hung program module to recover unsaved data. The method and system allows a user to determine that the program module is hung and inject an exception into the hung program module. In response to the injected exception, program code, within the program module, is activated to detect the crash and launch a failure reporting executable program that instructs the hung program module to execute its data recovery program. The file recovery program recovers the unsaved data and notifies the failure reporting executable program when it has completed the data recovery. Once the failure reporting executable program receives the notification, it will instruct the operating system to restart the program module. The restarted program module then displays a user interface with a list of the unsaved data that were recovered. The user interface also provides controls for a user to select, from the list of recovered data, the data that the program module will keep.

Method and system for injecting an exception to recover unsaved data

A method and system for preserving document integrity between potentially partially incompatible versions of a program module by maintaining forwards compatibility and backwards compatibility. Version (n') of the program module is released after version (n). A 'saved by version (n)' bit may be activated any time that version (n) saves a file. The 'saved by version (n)' bit indicates to subsequently-released versions, such as version (n'), that the file has been saved by version (n) and, based upon this information, appropriate action should be taken by the subsequently-released version. A 'warning from future version' bit may be activated to indicate that a feature or features of the subsequently-released version is not supported by version (n). Based upon receiving this bit, version (n) may open the file with these features disabled or may take some other appropriate action.

Method and system for preserving document integrity

Growing community of inventors

Seattle, WA, United States of America

Eric A LeVine