Abstract: Driver shimming techniques are described. In one or more implementations, an identification is made as to which interfaces and callbacks are utilized by a shim obtained for a driver of a computing device. The identified interfaces and callbacks are wrapped by the shim of the computing device such that calls to the wrapped interfaces and callbacks are intercepted by the shim.

Abstract: Device flag techniques are described. In one or more implementations, responsive to detection by a computing device that a device has been communicatively coupled to bus of the computing device, a database is queried by the computing device to determine whether one or more flags have been set for the device. Responsive to a determination made as a result of the querying that the one or more flags have been set for the device identifier, information associated with the one or more flags is communicated to software that is associated with the device to configure the software.

Abstract: Device flag techniques are described. In one or more implementations, responsive to detection by a computing device that a device has been communicatively coupled to bus of the computing device, a database is queried by the computing device to determine whether one or more flags have been set for the device. Responsive to a determination made as a result of the querying that the one or more flags have been set for the device identifier, information associated with the one or more flags is communicated to software that is associated with the device to configure the software.

Abstract: Techniques for determining similarity between error reports received by an error reporting service. An error report may be compared to other previously-received error reports to determine similarity and facilitate diagnosing and resolving an error that generated the error report. In some implementations, the similarity may be determined by comparing frames included in a callstack of an error report to frames included in callstacks in other error reports to determine an edit distance between the callstacks, which may be based on the number and type of frame differences between callstacks. Each type of change may be weighted differently when determining the edit distance. Additionally or alternatively, the comparison may be performed by comparing a type of error, process names, and/or exception codes for the errors contained in the error reports. The similarity may be expressed as a probability that two error reports were generated as a result of a same error.

Abstract: A mitigation enablement module for a computer that improves application reliability. When performing memory management operations, the mitigation enablement module and associated memory manager selectively use mitigations that are intended to prevent an application bug from cause an application error. The memory manager may selectively apply mitigations for each of one or more applications based on the likelihood that such mitigations are successful at preventing bugs from causing application errors. The likelihood is determined from historical information on whether the mitigations, when applied, prevented bugs from causing memory operations that could cause application errors. This historical information can be gathered on a single computer over multiple invocations of the application or may be aggregated from multiple computers, each invoking the application.

Abstract: In embodiments of a software operability service, activities of software can be monitored to collect software activity data. A software operability signature for the software can then be generated from the software activity data, and the software operability signature indicates an operability of the software. The software operability signature and associated contextual data can then be communicated to a network service that analyzes the software operability signature. In an embodiment, the network service compares the software operability signature to a baseline operability signature to determine whether the software is operating consistent or inconsistent with the baseline operability signature.

Abstract: Device flag techniques are described. In one or more implementations, responsive to detection by a computing device that a device has been communicatively coupled to bus of the computing device, a database is queried by the computing device to determine whether one or more flags have been set for the device. Responsive to a determination made as a result of the querying that the one or more flags have been set for the device identifier, information associated with the one or more flags is communicated to software that is associated with the device to configure the software.

Abstract: Driver shimming techniques are described. In one or more implementations, an identification is made as to which interfaces and callbacks are utilized by a shim obtained for a driver of a computing device. The identified interfaces and callbacks are wrapped by the shim of the computing device such that calls to the wrapped interfaces and callbacks are intercepted by the shim.

Abstract: Techniques for performing memory management to mitigate memory errors. In accordance with the principles described herein, a memory management module may be implemented that acts in different modes of operation for each of one or more software modules that are instances of applications. In one mode of operation, memory operations may be performed in accordance with one or more mitigation actions, and in another mode of operation, the memory management module performs memory operations as requested, without performing mitigation actions. A memory management module may maintain a record in a data store associated with the memory management module that may be used to determine whether to enable the mitigations. In some implementations, records maintained by each of a plurality of computing devices may be aggregated at a central server and this aggregated information may be used to adjust the entries on each of the computing devices.

Abstract: A mitigation enablement module for a computer that improves application reliability. When performing memory management operations, the mitigation enablement module and associated memory manager selectively use mitigations that are intended to prevent an application bug from cause an application error. The memory manager may selectively apply mitigations for each of one or more applications based on the likelihood that such mitigations are successful at preventing bugs from causing application errors. The likelihood is determined from historical information on whether the mitigations, when applied, prevented bugs from causing memory operations that could cause application errors. This historical information can be gathered on a single computer over multiple invocations of the application or may be aggregated from multiple computers, each invoking the application.

Abstract: Techniques for performing memory management to mitigate memory errors. In accordance with the principles described herein, a memory management module may be implemented that acts in different modes of operation for each of one or more software modules issuing requests for performance of memory operations to the memory management module. In one mode of operation, one or more mitigation actions may be performed by the memory management module in addition to or instead of the memory operation requested by the calling software module, such that the memory operations are performed in accordance with the mitigation actions. These mitigation actions may serve to reduce a likelihood of a memory error negatively affecting the calling software module. In another mode of operation, the memory management module performs memory operations as requested, without performing mitigation actions.

Abstract: A mitigation enablement module for a computer that improves application reliability. When performing memory management operations, the mitigation enablement module and associated memory manager selectively use mitigations that are intended to prevent an application bug from cause an application error. The memory manager may selectively apply mitigations for each of one or more applications based on the likelihood that such mitigations are successful at preventing bugs from causing application errors. The likelihood is determined from historical information on whether the mitigations, when applied, prevented bugs from causing memory operations that could cause application errors. This historical information can be gathered on a single computer over multiple invocations of the application or may be aggregated from multiple computers, each invoking the application.

Abstract: Techniques for determining similarity between error reports received by an error reporting service. An error report may be compared to other previously-received error reports to determine similarity and facilitate diagnosing and resolving an error that generated the error report. In some implementations, the similarity may be determined by comparing frames included in a callstack of an error report to frames included in callstacks in other error reports to determine an edit distance between the callstacks, which may be based on the number and type of frame differences between callstacks. Each type of change may be weighted differently when determining the edit distance. Additionally or alternatively, the comparison may be performed by comparing a type of error, process names, and/or exception codes for the errors contained in the error reports. The similarity may be expressed as a probability that two error reports were generated as a result of a same error.

Abstract: A mitigation enablement module for a computer that improves application reliability. When performing memory management operations, the mitigation enablement module and associated memory manager selectively use mitigations that are intended to prevent an application bug from cause an application error. The memory manager may selectively apply mitigations for each of one or more applications based on the likelihood that such mitigations are successful at preventing bugs from causing application errors. The likelihood is determined from historical information on whether the mitigations, when applied, prevented bugs from causing memory operations that could cause application errors. This historical information can be gathered on a single computer over multiple invocations of the application or may be aggregated from multiple computers, each invoking the application.

Abstract: Techniques for performing memory management to mitigate memory errors. In accordance with the principles described herein, a memory management module may be implemented that acts in different modes of operation for each of one or more software modules issuing requests for performance of memory operations to the memory management module. In one mode of operation, one or more mitigation actions may be performed by the memory management module in addition to or instead of the memory operation requested by the calling software module, such that the memory operations are performed in accordance with the mitigation actions. These mitigation actions may serve to reduce a likelihood of a memory error negatively affecting the calling software module. In another mode of operation, the memory management module performs memory operations as requested, without performing mitigation actions.

Abstract: Techniques for performing memory management to mitigate memory errors. In accordance with the principles described herein, a memory management module may be implemented that acts in different modes of operation for each of one or more software modules that are instances of applications. In one mode of operation, memory operations may be performed in accordance with one or more mitigation actions, and in another mode of operation, the memory management module performs memory operations as requested, without performing mitigation actions. A memory management module may maintain a record in a data store associated with the memory management module that may be used to determine whether to enable the mitigations. In some implementations, records maintained by each of a plurality of computing devices may be aggregated at a central server and this aggregated information may be used to adjust the entries on each of the computing devices.