Microsoft Technology Licensing, LLC

Jakob Frederik Lichtenberg

Vladimir A Levin

Hyuk Joon Kwon

Juncao Li

Sebastian Lerner

Vikas Pabreja

Remy L De Weduwe

Andrew Meyer Kluemke

Markus W Mielke

Conal McGarvey

Nathan L Deisinger

Sandeep Repaka

Matthew John Woolman

Andrew D Mikesell

Adam Jonathan Shapiro

Swati Kanchan

Described are examples for tracking memory usage of a driver. A memory allocation request related to the driver to allocate a portion of memory for the driver can be traced in a kernel mode of an operating system. One or more associated allocation parameters can be recorded, and an allocation history of the driver over a period of time can be reported during execution of the driver and based on the one or more allocation parameters indicated by the memory allocation request.

Advanced memory tracking for kernel mode drivers

A system for providing ongoing verification of released software components utilizes feedback from a pool of devices that each locally execute a verification component. The verification component randomly selects one or more locally-executing software components, captures information associated with the randomly-selected software components responsive to detection of events satisfying one or more capture conditions, and communicates the captured information to a software component verification and analysis service. The total number of the randomly-selected software components within the verification pool is set to statistically guarantee that each one of the software components available for random selection is randomly selected on at least one of the plurality of processing devices within the verification pool.

Software component verification using random selection on pooled devices

Interaction between operating system components and device drivers via device driver function call addresses is monitored. Each device driver is configured to interface with at least one hardware component of a computing system. One or more verification functions of an extended device driver verification component are registered for at least one of the device driver function call addresses, each defining a predetermined verification condition. A device driver function call to one of the device driver function call addresses is intercepted and evaluated against the predetermined verification condition of the verification function registered for the device driver function call address of the intercepted device driver function. A result of executing the intercepted device driver function, responsive to satisfaction of the predetermined verification condition or terminated, responsive failure to satisfy the predetermined verification condition of the verification function registered for the device driver function call address of the intercepted device driver function.

Extensible device driver verification

Systems and methods to conduct data-driven, system wide tests are disclosed. Instructions for testing an operating system are associated with one or more modules associated with the computing system. When a failed test is identified, a second set of instructions that accounts for the failed test is generated and executed, in order to efficiently identify and target specific issues. Results from these fully configurable testing methods can be communicated and utilized in further applications.

Configurable system wide tests

Systems and methods are described for verifying functionality of a computing device. A set of rules are sent to a computing device identifying a device driver. Data is received from the one device that is indicative of collected driver data of the computing device. The data is collected by a driver verifier function executing on the computing device. The driver verifier function is configured to capture information associated with the identified device driver identified by the set of rules. The received data is parsed to categorize the data with previously collected driver data of other computing devices. The data is categorized based on attributes of the collected driver data. The categorized data is provided for analysis of the driver health on the computing device.

Device driver verification

Systems and methods are described for verifying functionality of a computing device. Rules are received that are usable to configure a driver verifier function to capture information associated with a device driver identified by the rules. The configured driver verifier function is run on a computing device. The information is captured in response to driver conditions identified by the rules. The computing device is allowed to continue operation when the driver condition includes an error condition of the identified device driver. A communication is initiated to transmit the captured information to a driver verification analysis service.

Device driver telemetry

A stateful rules verification platform is described that support timed state transitions. The verification platform implements a specification language to provide a formal definition for rules used to test target systems having a central module that provides APIs ('API provider') and applications ('API clients') that use the APIs. Rules may be defined in terms of transitions on state elements associated with interactions between API providers and API clients. The rules defined in accordance with the specification language enable run-time verification in which calls may be intercepted and run-time code to implement checks may automatically be generated and injected to test behaviors of the intercepted calls. The same set of rules may also be employed for static verification during compilation. Additionally, the specification language includes constructs to specify timed state transitions for at least some rules that impose time limits on state transitions specified by the rules.

Timed API rules for runtime verification

Various embodiments provide per group verification techniques in which code may be verified against one or more rules on a group by group basis. In one or more embodiments relationships between portions of a module to be verified can be defined. By being aware of relationships between various code portions, various embodiments can divide a module into related groups and perform verification on the basis of the groups. Multiple groups can be derived based at least in part upon the relationships. Each group can then be verified separately for compliance with one or more rules. Verification results can be output for each of the groups.

Growing community of inventors

Redmond, WA, United States of America

Jakob Frederik Lichtenberg