Microsoft Technology Licensing, LLC

Gregory Bernard Miskelly

Tae Hyung Kim

Michael C Fanning

Timothy Scott Rice

Akrosh Gandhi

Jackson Michael Davis

Patrick Nelson

Andrew R Sterland

Isadora Sophia Garcia Rodopoulos

Stephen Harris Toub

Mark Alistair Wilson-Thomas

David Ellis Pugh

Del Myers

Gustavo Araujo Soares

Arjun Radhakrishna

German David Obando Chacon

Tomas Matousek

Dmitry Lomov

Eric H Feiveson

Peter Groenewegen

Azeemullah Khan

Oleg Izmerly

Piyush Arora

Daniel Joshua Taylor

Mark Anthony Jelf Downie

Daniel Demetris George Moth

Cagri Aslan

Andrew Brian Hall

Aaron Chak Hei Yim

William Xie

Joseph Mark Schmitt

Maciej Piotr Foks

Justin Michael Anderson

Claudiu-Constantin Guiman

Charles Joseph Ries

Karl Melder

Zhaoqing Wu

Ian W J Halliday

Kayle K Hinkle, Iii

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

A change to a first version of source code of an application that is running with a debugger attached is identified, resulting in a second version of the source code. It is determined whether the change occurred with corresponding software suspended or not. The change is applied to the software without restarting the software, based on applying the change using edit and continue (EnC) when the change occurred with the software suspended, or applying the change using hot reload when the change occurred with the software not suspended. Subsequently, the software is suspended, and debug state is presented. The presentation includes presenting the second version of the source code after EnC, or after hot reload and when the software is suspended in an updated memory entity; or presenting the first version of the source code after hot reload and when the software is suspended in a stale memory entity.

Source code editing combining edit and continue with hot reload

Embodiments automate surfacing of underutilized development tool features, thereby enhancing the discoverability of subtools, commands, shortcuts, settings, visualizers, and other tool features. After spotting an inefficiency in the user's interaction with one or more tools, the feature surfacing functionality offers the user an interaction optimization suggestion. A mapping structure correlates detected interaction patterns with objectively better interaction optimizations. Several examples of mappings are discussed. The user can accept a suggestion, have the suggested optimization applied by an enhanced tool, and thereby reduce the number of user gestures utilized to accomplish a desired result, reduce the number of tools utilized, increase security, reduce risk of error, or get to the desired result faster, for example. Interaction optimizations also help the user stay focused, by reducing or avoiding departures from the user's current primary workflow. Other aspects of tool feature surfacing functionality are also described herein.

Surfacing underutilized tool features

To set data breakpoints on properties and certain other functions, constituent data locations (CDLs) that can contribute to computation of the property value or other function result are identified, and respective constituent data breakpoints are added at one or more CDLs by data breakpoint adder code. Each constituent data breakpoint will suspend execution of an inspectable software in response to occurrence of a CDL data entry. The CDLs are identified by CDL identifier code using static data flow analysis, enhanced interpretation, or disassembly, with recursion as appropriate. Kernel or runtime routines, and other routines designated as known, can be excluded from the CDL search. Data locations marked read-only, or that are effectively read-only because they will not be written, can also be excluded. The resulting data breakpoint functionality makes internal program state information available, thus facilitating computing system accuracy, flexibility, security, speed, memory usage efficiency, and other functional characteristics.

Data breakpoints on certain kinds of functions

Debugging without reliance on source code includes obtaining a disassembly of a portion of an executable code. The disassembly includes a sequence of assembly instructions including an instruction Y at which an exception or other event of interest occurred and at least five assembly instructions that precede Y. An assembly instruction X is located for which a mapping is known between a storage location accessed in instruction X and a symbolic name SYM_X for that storage location, where data flow and/or control flow leads from instruction X to instruction Y. A symbolic name SYM_Y that pertains to instruction Y is built from SYM_X while interpreting the assembly instructions between X and Y, and SYM_Y is reported to the user. Some variations include tools and techniques for locating the instruction X, and tools and techniques for determining a flow relationship between instruction X and instruction Y.

Storage access debugging with disassembly and symbol entries

Assistance is given to aid in optimizing a program's performance during initial development while the program's features are still being implemented and/or debugged, without interfering with that development, by providing easy-to-ignore yet accurate tips about a program's performance inside a debugger. Raw performance information for a software program which is being debugged in a debugger is adjusted by removing from it a measured debug overhead or other diagnostic overhead. Some factors considered when measuring overhead include pauses, context switches, debug versus release build presence, bounds checking, funceval, and call stack analyses. The debugger is enhanced to display the adjusted program performance measure in a graphical user interface, next to the corresponding source code. The enhanced debugger updates the adjusted program performance measure value and keeps its screen location current as the developer moves through the source code, providing more detailed performance information upon request.

Performance optimization tip presentation during debugging

Systems, methods and computer program products are described that enable a diagnostic tool, such as a debugger, to evaluate an expression based on the state of a target program process where the expression to be evaluated includes a call to a first function that exists in the target program process but where evaluation of such first function requires evaluation of a second function that does not exist in the target program process. For an expression such as this, the diagnostic tool emulates execution of the first function within a process other than the target program process, such as within the diagnostic tool process. In other embodiments, the emulation capability of the diagnostic tool is leveraged to enable a user thereof to simulate a modification of the target program process without making actual changes to the target program process.

Emulation-based expression evaluation for diagnostic tools

Aspects of the subject matter described herein relate to imperative attribution. In aspects, metadata of a managed runtime environment may be set by imperative statements included in code of a program executing in the managed runtime environment. The metadata may be associated with lookup data that identifies the metadata. The lookup data may be formed from an identifier supplied by an imperative statement and an identifier of a logical element which may be explicitly or implicitly supplied. The metadata may be computed at parse time, run time, or another time and may be computed based on state available to a managed runtime environment at the time the metadata is computed.

Imperative attribution for elements in managed runtimes

Aspects of the subject matter described herein relate to imperative attribution. In aspects, metadata of a managed runtime environment may be set by imperative statements included in code of a program executing in the managed runtime environment. A metadata consumer may request the metadata. A metadata identifier of the metadata requested may be provided implicitly or explicitly. A parameter that indicates how to obtain the metadata may also be provided. In response, the metadata may be obtained and provided. The metadata may be computed at parse time, run time, or another time and may be computed based on state available to a managed runtime environment at the time the metadata is computed.

Obtaining metadata set by imperative statement

Aspects of the subject matter described herein relate to assisting development tools. In aspects, statements that influence runtime behavior may be inserted into code of a program. For example, a statement inserted into a function may set a property of a runtime object to indicate that a debugger is to be notified for exceptions that are encountered within the scope of the function. When a runtime environment encounters an exception, the runtime environment may determine whether the property applies to the currently-executing scope. If so, the runtime environment may notify or not notify a development tool of the exception based on the value of the property.

Assisting development tools through inserted code statements

A debugger can step through target code in a computer program. The debugger can identify a coroutine yield point in the target code, and can obtain identifying information to identify continued processing of a coroutine instance triggered by the operator. The debugger can set a breakpoint at a location for continued stepping after the coroutine yield point. The breakpoint can have a condition of matching the identifying information with runtime information. The debugger can perform the coroutine instance and resume execution of the target code after the coroutine yield point. The debugger can also encounter the breakpoint in the target code, and can determine whether the condition of the breakpoint is met. If so, the debugger can pause execution of the target code at the breakpoint. If not, the debugger can continue execution of the target code past the breakpoint without pausing at the breakpoint.

Debugger-set identifying breakpoints after coroutine yield points

Growing community of inventors

Seattle, WA, United States of America

Gregory Bernard Miskelly