Microsoft Technology Licensing, LLC

Kirk A Glerum

Matthew James Ruhlen

Eric A LeVine

David Gray

Maithreyi Lakshmi Ratan

Jeff David Mitchell

Steven Miles Greenberg

Rob M Mensching

Jeffrey E Larsson

Charles Scott Walker

William Kennedy

Kevin Joseph Fischer

Michael Ronn Marcelais

Meredith Anne McClurg

Joel Wayne Downer

E Peter Oosterhof

In a software development environment, a system and method for associating an assert with a unique identifier ('assert tag'), and using the unique identifier to store information associated with the assert in a database. Based on the unique identifier, information associated with the assert can be stored in a database or repository that contains assert information. This information can be updated, as well as displayed to the developer or tester. Information for the bugs associated with the assert can be retrieved from a database containing bug information and displayed to the developer or tester. Once the developer or tester has been presented with the information concerning the bugs associated with the assert, or other information associated with-the assert, the developer or tester can choose to enter or log-in a new bug into the database containing bug information.

System and method for storing and reporting information associated with asserts

Information is retrieved from the registry by creating a registry interface database containing information regarding registry data and uniquely identifying every registry entry for a registry interface. Source header files are generated using information about a program module, such as an application, contained in the registry interface database. The source header files are compiled with the application to generate the application's executable file. During run-time of the application, the registry interface is called by the application to retrieve registry data. If available, the registry interface retrieves the registry data and forwards this information to the application. In the event that the registry data is not available, the registry interface retrieves a default value in place of the registry data and forwards that default data to the application. A policy may be implemented by checking a policy area of the registry for the registry data and invoking the policy.

System and method for retrieving registry data

A computer-implemented method and system for reporting failures in an application program module to a corporate file server. The failure may be a crash or a set-up failure. Once detected, the program failures are categorized, i.e. bucketed, and reported directly to a local file server operated by a corporation. The corporate file server may be used to store the failures encountered by users in a corporate environment until these failures are reported to a server operated by the manufacturer of the program module (a destination server). Once the failures are reported to the destination server, developers or programmers may examine the data and determine what is causing the failures in the program module. A failure reporting executable on the user's computer provides communications between the failed application program module and the local file server. An administrative reporting executable (typically operated at the corporate file server) provides communications between the failure reporting executable and the corporate file server and between the corporate file server and the destination server. A cab tree, a counts tree and a status tree stores bucket information for a failure at the corporate file server. The bucket information for a crash may comprise an AppName, an AppVer, a ModuleName, a ModuleVer, and an offset into that module. The bucket information in the corporate file server may be uploaded to a destination server by a corporate system administrator thus preventing sensitive information from being disclosed by the corporation's users.

Method and system for reporting failures of a program module in a corporate environment

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

The invention provides a method and computer-readable medium for generically reporting the occurrence of an event occurring within a computer system. When an event occurs, parameter values corresponding to one or more predefined parameters that describe the event are identified. The parameter values are then stored in a normalized database configured for storing event parameters corresponding to the occurrence of an unlimited number of event types.

Method and system for generically reporting events occurring within a computer system

In a software development environment, a system and method for associating an assert with a unique identifier ('assert tag'), and using the unique identifier to store information associated with the assert in a database. Based on the unique identifier, information associated with the assert can be stored in a database or repository that contains assert information. This information can be updated, as well as displayed to the developer or tester. Information for the bugs associated with the assert can be retrieved from a database containing bug information and displayed to the developer or tester. Once the developer or tester has been presented with the information concerning the bugs associated with the assert, or other information associated with the assert, the developer or tester can choose to enter or log-in a new bug into the database containing bug information.

Retrieving information form from the registry include by creating a registry interface database containing information regarding registry data and uniquely identifying every registry entry for a registry interface. Source header files are generated using information about a program module, such as an application, contained in the registry interface database. The source header files are compiled with the application to generate the application's executable file. During run-time of the application, the registry interface is called by the application to retrieve registry data. If available, the registry interface retrieves the registry data and forwards this information to the application. In the event that the registry data is not available, the registry interface retrieves a default value in place of the registry data and forwards that default data to the application. A policy may be implemented by checking a policy area of the registry for the registry data and invoking the policy.

The invention is a software module configured for handling failure information from a large base of clients. The invention is configured for a four-stage network conversation between a client and a server. In the first stage, the module collects failure information and creates a string address. The string address is sent to the server, where the string address is compared to predefined string addresses. In the second stage, the client creates a record query with the failure information for the server. The record query is sent to the server and compared to predefined failure records. In the third stage, the client transfers additional failure information to the server, and the server acknowledges information transfer. In the fourth stage, the client sends a confirmation message to the server. When necessary, a predefined string address corresponding to the particular failure information is created on the server for subsequent reference by a stage one network conversation.

System and method for handling a failure reporting conversation

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

Applying a system policy for a program module to binary-formatted data within registry of a computer system operating within an administered computer network environment. At program launch, a program can search a particular location in registry to locate certain registry values maintained at that registry location. The program enumerates the name/value pairs maintained at that registry location. These registry values typically have a format that describes an offset defining a location within a global data structure and the number of binary bits that can be processed at that data structure location. In this manner, registry data values maintained within a predetermined location of the registry can be encoded to include content that supports the application of a system policy to the binary values maintained in the global data structure. Although the application of system policy will change the original value stored at the specified location within the global data structure, this original value can be recorded prior to translating the policy value into a bit mask that can be applied to the data structure. At the conclusion of the program session, any changes applied to the global data structure can be rolled back to the original values to enable these original values to persist for subsequent use during another program session.

Growing community of inventors

Redmond, WA, United States of America

Kirk A Glerum