Microsoft Technology Licensing, LLC

Workman Nydegger

Del Myers

Jackson Michael Davis

Thomas Lai

Jordi Mola

Patrick Nelson

Andrew R Sterland

Leslie Yvette Richardson

Juan Carlos Arevalo Baeza

James M Pinkerton

Deborah Chen

Kenneth W Sykes

Stephen Harris Toub

Henry Gabryjelski

Gregory Bernard Miskelly

Mark Marron

Mark Anthony Jelf Downie

William Xie

Andrew Joseph Luhrs

Joseph Mark Schmitt

Timothy Gardner Misiak

Justin Michael Anderson

Claudiu-Constantin Guiman

Noah Falk

Patrick Lothian Nelson

Methods, systems, and computer program products for using a confidence measure to automatically identify a diagnostic analyzer that applies to a diagnostic artifact. A plurality of diagnostic analyzers are each configured to analyze diagnostic artifacts relating to prior executions of software entities. A confidence measure is calculated for each diagnostic analyzer. Each confidence measure indicates a likelihood that the diagnostic analyzer applies to a particular diagnostic artifact. Calculating each confidence measure comprises applying one or more heuristics specific to the diagnostic analyzer against the particular diagnostic artifact, with an outcome of application of each heuristic contributing to the confidence measure for the respective diagnostic analyzer. Based at least on calculating the confidence measure for each diagnostic analyzer, and based on one or more determined thresholds, it is determined whether to include each diagnostic analyzers in a set of diagnostic analyzers with which to analyze the particular diagnostic artifact.

Automatically identifying a diagnostic analyzer applicable to a diagnostic artifact

Automatic identification of execution behavior(s) of software. This automatic identification is based on analysis of historical execution records using machine learning to identify a particular pattern that corresponds to an execution behavior. In order to automatically identify an execution behavior present within particular software, an execution record of that particular software is accessed. The execution record includes an execution trace that reproducibly represents the execution of the software within a particular execution environment, such that the execution record is usable to rerun the execution of the software precisely as the software previously run. Based on finding the particular pattern within the execution record, the computing system automatically identifies that the execution behavior is present within the software.

Automatic software behavior identification using execution record

Based on replay of a thread, one implementation observes an influx of a value of a memory cell comprising an interaction between the thread and the value of the memory cell at an execution time point in the replaying, and determines whether the value of the memory cell observed from the influx is inconsistent with a prior value of the memory cell as known by the thread at the execution time point. If so, this implementation initiates an indication of a data inconsistency. Based on replay of a plurality of threads, another implementation identifies a memory cell that was accessed by a first thread while a thread synchronization mechanism was active on the first thread. Then, if there was another access to the memory cell by a second thread without use of the thread synchronization mechanism, this implementation initiates an indication of a potential data contention.

Identifying data inconsistencies and data contention based on historic debugging traces

Expressly turning tracing on and off at each juncture between code that a developer wants to have traced and other code may reduce trace file size but adds computational cost. Described technologies support selectively tracing a process's execution, with some extra tracing done beyond the code the developer wanted traced, but with significantly reduced computational cost, by reducing the number of trace enablement and disablement operations. A trace controller uses a tracing disablement distance variable whose values indicate the computational distance from trace disablement. A distance variable modifier automatically moves the distance variable closer to a stop-tracing value as the process executes. The amount of extra tracing is balanced against the reduction in trace enablement/disablement operations by tuning thresholds, based on information about routine size and computational cost. Operation of the trace controller is illustrated by sample APIs, a tracing state diagram, and a side-by-side comparison, among other items.

Selectively tracing portions of computer process execution

Identifying and reporting potential data inconsistencies and/or potential data contentions based on historic debugging traces. Based on replay of a thread, some implementations observe an influx of a value to a memory cell, and determine whether the value of the memory cell observed from the influx is inconsistent with a prior value of the memory cell as known by the thread. If so, these implementations can initiate an indication of a data inconsistency. Based on replay of a plurality of threads, other implementations identify a memory cell that was accessed by a first thread while a thread synchronization mechanism was active on the first thread. Then, if there was another access to the memory cell by a second thread without use of the thread synchronization mechanism, these implementations might initiate an indication of a potential data contention.

This disclosure relates to identifying and presenting differences between a plurality of recorded executions of an executable entity. One or more models are created over the plurality of recorded prior executions of at least a portion of an executable entity. These models include at least one of (i) a control flow model, or (ii) a data model. An anomalous model data point is identified within these models, and a first location in at least one of the plurality of recorded executions that corresponds to the anomalous model data point is identified. A second location in the at least one of the plurality of recorded executions is also identified. This second location is causal to the anomalous model data point at the first location. The identity of the first and/or second locations in the least one of the plurality of recorded executions is presented.

Automatically identifying and highlighting differences between historic traces

Performing reverse execution debugging of an application. The method includes identifying a snapshot of application state for an application in an application framework. The method further includes emulating execution of the application, using bytecode, in a forward direction from the snapshot to an end point, causing generation of historical execution state at various points along the emulation of the application. The method further includes collecting the historical execution state. The method further includes using the collected historical execution state, emulating reverse execution of the application by substituting collected historical execution state, when needed, to restore previous state needed as a result of emulation of reverse execution of the application.

Reversible debugging in a runtime environment

Collecting runtime virtual machine external state for an application running in an application runtime virtual machine, for use in emulation of the application. A method includes identifying application bytecode for which runtime virtual machine external state is to be collected. The method further includes executing machine code generated from the bytecode to generate the runtime virtual machine external state. The method further includes collecting the runtime virtual machine external state. The method further includes storing the runtime virtual machine external state for use in emulating the application.

Collecting application state in a runtime environment for reversible debugging

Dynamically instrumenting code that executes based on a historic execution of a subject executable entity. Historic execution information for a subject executable entity is accessed. The historic execution information includes execution state information for at least one point in time in the historic execution the executable entity. Diagnostic code instruction(s) are identified, for instrumenting subject code instruction(s) of the executable entity. The subject code instruction(s) are virtually executed based at least on supplying the subject code instruction(s) with data from the historic execution information. While virtually executing the identified executable code instruction(s), the diagnostic code instruction(s) are also executed. The diagnostic code instruction(s) collecting diagnostic data regarding the virtual execution of the subject code instruction(s), or override at least one of a value or an execution behavior of the subject code instruction(s).

Dynamic diagnostic code instrumentation over a historic program execution

The automatic identification of execution behavior(s) of software. This automatic identification is based on a historical analysis of execution records to identify a particular pattern that represents an execution behavior. In order to automatically identify an execution behavior present within particular software, an execution record (or perhaps multiple execution records) representing the execution of that particular software may be accessed. Based on finding the particular pattern within the execution record (or one, some, or all of the multiple execution records) representing the execution of that particular software, the computing system may automatically identify that the execution behavior is present within the software. This may dramatically assist in modifying that execution behavior.

Techniques are provided to use historic execution state information to visualize tracepoint data. For example, historic execution state information corresponding to an application's previous execution is accessed. This historic execution state information was collected while the application was executing. After correlating the historic execution state information to the application's code, a tracepoint is associated with a portion of the code. Consequently, when the code is replayed based on the historic execution state information, the tracepoint causes a behavior of that code portion to be logged while the code is replayed uninterrupted. The code is then actually replayed based on the historic execution state information. During the replay, the tracepoint causes the behavior of the code portion to be logged. The logged behavior is visualized on a user interface.

Using historic execution data to visualize tracepoints

Described technologies support selectively tracing a process's execution, with some extra tracing done beyond the code the developer wanted traced, but with significantly reduced computational cost, by reducing the number of trace enablement and disablement operations. A trace controller uses a tracing disablement distance variable whose values indicate the computational distance from trace disablement. A distance variable modifier automatically moves the distance variable closer to a stop-tracing value as the process executes. A create task function is modified to include the setting of an indicator that a newly created task is to be traced if a current task or thread is being traced. An execute task function is modified to request the tracing of the newly created task when it is executed based on the indicator, thereby enabling selective tracing that operates across process boundaries and traces asynchronous code execution.

Described technologies aid execution control during replays of traced program behavior. Cross-level mapping correlates source code, an intermediate representation, and native instructions in a trace. The trace includes a record of native code instructions which were executed by a runtime-managed program. The trace does not include any executing instance of the runtime. Breakpoints are set to align trace locations with source code expressions or statements, and to skip over garbage collection and other code unlikely to interest a developer. A live debugging environment is adapted to support trace-based reverse execution. An execution controller in a debugger or other tool may utilize breakpoint ranges, cross-level mappings, backward step-out support, and other items to control a replay execution of the trace. Aspects of familiar compilers or familiar runtimes may be re-purposed for innovative execution control which replays previously generated native code, as opposed to their established purpose of generating native code.

Execution control with cross-level trace mapping

Presenting historical state associated with prior execution of an entity. Based on replaying segment(s) of execution of an entity based on a trace, embodiments could present an indication of whether a value of a code element is, at a first execution time point, unknown, known, previously known, and/or known in the future. Additionally, or alternatively, embodiments could present an indication of a value relied upon by simulated execution of a function at a second execution time point, along with an indication of a timing of knowledge of the value in relation to the second execution time point. Additionally, or alternatively, embodiments could present an indication that a return value of a function would be known if the function had executed at a third execution time point, or an indication that the return value would be unknown if the function had executed at the third execution time point.

Growing community of inventors

Seattle, WA, United States of America

Del Myers