Microsoft Technology Licensing, LLC

Michael Ronn Marcelais

Brian T Hill

Matthew James Ruhlen

Eric A LeVine

Steven Miles Greenberg

Rob M Mensching

Marcin D Szuster

Christopher M White

Eric B Fox

James E Walsh

Kevin Joseph Fischer

Jeffrey E Larsson

Kirk A Glerum

Thomas Scott Coon

James Coryell Hilke

Jeff David Mitchell

Shawn Thomas Sullivan

Concepts and technologies are described herein for hash-based file comparison. In accordance with the concepts and technologies disclosed herein, a comparison tool is configured to compare hash values in a first hash list associated with a first file to hash values in a second hash list corresponding to a second file. The hash values are computed for functional blocks of the respective files and therefore can be compared to indicate if the functional blocks of the two files match one another. If the hash values match, the functional blocks associated with the respective hash values can be determined to match, while hash values that do not match can indicate that the corresponding functional blocks do not match one another.

Hash-based file comparison

Applications are protected from being exposed to exploits and instabilities due to memory operations involving zero byte allocations. Memory operations involving a zero byte allocation are handled by a zero byte memory manager. When an application requests a zero byte allocation, a pointer to a protected part of memory is returned such that when the application attempts to read and/or write to the location the program flow is interrupted.

Protecting memory operations involving zero byte allocations

A system and methods for sharing configuration information with multiple services, or processes, via shared memory. The configuration information, typically, comprises runtime information utilized by processes during operation, including without limitation, information describing data communication connections between the local computer and other computing resources (i.e., port and wire information), and information defining numeric values or character string values (i.e., genre and record information). The system architecture includes a plurality of APIs which: reside at the local computer; populate, manage, and control access to a shared memory containing the configuration information; and, are executable only by processes executing at the local computer, thereby limiting access to the shared memory. Access to the configuration information is further limited to only those processes identified as having appropriate permission. The methods enable the configuration information of the shared memory to be modified during local computer operation and without impeding access to the configuration information.

System and methods for sharing configuration information with multiple processes via shared memory

A system and method for handling the generation of an unexpected exception by an application. When the application generates an unexpected exception (i.e., crashes), the application's exception filter launches an outside exception handling program (EHP) that is separate and distinct from the application. Through a special protocol, the application and the EHP collaborate in responding to the unexpected exception. In this protocol, the application and the EHP communicate through kernel objects accessible by handles in a shared memory structure that the application creates before launching of the exception handling program and then shares with the EHP. Through this shared memory, the application also provides the EHP with information about the types of recovery options to offer the user. Through a graphical user interface, the EHP is then responsible for notifying the user of the application that an unexpected exception has occurred. Through the graphical user interface, the EHP also provides the user with the ability to specify various courses of action in response to the unexpected exception.

Method and system for handling an unexpected exception generated by an application

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

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

Systems and methods for pre-processing an initializer prior to creation of a final version of a binary image and excluding the initializer from the computer code that comprises the binary image. Prior to creation of the final version of the binary image, an attempt is made to pre-process the initializer as if it were being processed during execution of the binary image. The initializer may be pre-processed during one or more of three stages involved in the creation of a binary image: prior to operation of the linker; during operation of the linker; and after operation of the linker. If the initializer is successfully pre-processed, an initialized value for a variable is determined. This initialized value is written into the binary image and all references and calls to the initializer are excluded from the binary image. Thus, during all subsequent start-ups of the binary image, no initialization of the variable will be performed.

Growing community of inventors

Redmond, WA, United States of America

Michael Ronn Marcelais