Diagnostic Workflow for Production Debugging

Abstract

A diagnostic workflow file can be used to control the diagnostic actions that the debugger will perform in the future when there is no user interaction with the debugger while the debugger is executing. Diagnostic workflow files are used by the debugger during a debugging session. The debugger performs the actions directed by the diagnostic workflow file to simulate an interactive live debugging session. Diagnostic workflow files can include conditional diagnostic actions whose execution depends on the state of program variables, diagnostic variables, and diagnostic primitives in the debugging session.

Description

[0001] This application is a divisional application of the invention patent application with application number 201580056568.8, application date October 26, 2015, and invention name “Diagnostic Workflow for Production Debugging”. Technical Field

[0002] This application relates to diagnostic workflows for production commissioning. Background Art

[0003] Conventional software diagnostic tools usually operate on a process running in real time (live) or a saved process state. For example, a real-time debugger runs on a process being executed. A debugger executed on a saved process state is not attached to the process being executed, and runs by processing a historical log file or process dump file collected when the process being debugged executes. This type of debugger is executed separately from the process being debugged, usually at a certain time after the process being debugged has completed execution. Debugging a real-time process provides little or no historical context about how the process reached its current state. Debugging process dump files and / or log files is usually time-consuming and iterative. Summary of the invention

[0004] The diagnostic tool can perform active type debugging on the process guided by the diagnostic workflow product without stopping the process. The diagnostic tool can perform conditional or unconditional breakpoint processing and conditional or unconditional exception processing in a manner similar to that used for real-time debugging, but does not have the performance impact of real-time debugging on the process. As used herein, "production" or "production environment" refers to an environment in which the software used has exited from the development and / or testing stage and is "in production", that is, for performing actual work rather than development and / or testing. The instructions provided in the diagnostic workflow file can be used to automatically control the future diagnostic operations of the debugger (when the debugger is executed, the user does not have to interact with the debugger). The diagnostic operations specified in the diagnostic workflow file can be conditionally executed based on the current state of the application being executed. "Current state" can include the state of the diagnostic primitive. The diagnostic primitive is any operation that affects the state of the diagnostic tool, such as but not limited to creating breakpoints, removing breakpoints, disabling breakpoints, changing the conditions of breakpoints, enabling exceptions based on the type of exceptions, disabling exceptions based on the type of exceptions, adjusting exceptions based on the call stack associated with the exception, stepping operations (such as stepping into the code, skipping instructions, etc., and stepping out of the code). The "current state" may include the state of various variables, including but not limited to program variables and diagnostic variables. Program variables are those variables used by the debugger. Diagnostic variables (e.g., the value of a variable that holds the number of times a particular breakpoint has been hit or whether an exception of a specified type has been thrown, or whether an exception has been thrown in a specified call stack) are those variables used by the debugger for debugging.

[0005] A diagnostic workflow file may be generated from an integrated development environment (IDE) or other development environment. A diagnostic workflow may enable diagnostic actions to be automatically performed (without human intervention) while a program is executing. Diagnostic actions include, but are not limited to, the following: breakpoints may be enabled when a specified event occurs, breakpoints may be disabled when a specified event occurs, breakpoints or dump generation may be enabled in program processing when an exception of a specified type is first thrown, breakpoints or dump generation may be enabled in program processing when an exception is first thrown in a specific call stack or on a specific line, the type of exception may be used as a secondary condition for break or dump generation, diagnostic logging may be enabled when one of the above conditions occurs, and / or diagnostic logging may be disabled when one of the following occurs: stepping may be performed, variables may be evaluated, variables may be written to a log, etc. That is, any action supported by the diagnostic tool that a user would be able to directly perform when the user controls the debugger may be automatically driven by a workflow file.

[0006] A diagnostic workflow file can be provided to a debugging session in a production or non-production environment. A diagnostic workflow can be applied to a live debugging session in a production environment. The actions described in the workflow can dynamically control a debugger or other diagnostic tool without user interaction. The status of the conditions specified in the diagnostic workflow can be visible in each generated diagnostic artifact. Diagnostic artifacts can include a live debugging session, a lightweight process snapshot, or a process dump generated from a live process or a lightweight process snapshot.

[0007] This Summary is provided to introduce some concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In the attached picture:

[0009] Figure 1 An example of a system 100 for generating and / or executing a diagnostic workflow in accordance with aspects of the subject matter described herein is shown;

[0010] Figure 2 An example of a method 200 including an example of a method of generating a diagnostic workflow and / or executing a diagnostic workflow according to aspects of the subject matter disclosed herein is shown;

[0011] Figure 3 is a block diagram of an example of a computing environment in accordance with aspects of the subject matter disclosed herein; and

[0012] Figure 4 is a block diagram of an example of an integrated development environment in accordance with aspects of the subject matter disclosed herein. DETAILED DESCRIPTION

[0013] Overview

[0014] Because the user interacts directly with the debugger (controls the actions of the debugger), a real-time debugger can provide the user with fine-grained control over debugging actions. For example, in real-time debugging, the user can insert breakpoints in the source code. When a breakpoint is encountered during the execution of the program, the target process is usually stopped and control of the process is handed over to the user. The user can then perform various debugging operations, including enabling or disabling breakpoints, checking variable values, checking call stacks, etc. When the user has completed his debugging actions, he can instruct the processor to resume the execution of the application. When debugging an application that is unreasonably stopped due to the impact on the user (for example, an application running in a production environment), the user must guess what information he or she will need to collect and put log statements into the application in order to collect the information. Typically, this historical information is evaluated offline.

[0015] According to some aspects of the subject matter described herein, while a debugger is being executed, instructions provided in a diagnostic workflow file can be used to control future diagnostic operations of the debugger without user interaction with the debugger. Instructions in a diagnostic workflow file can be conditionally executed. Instructions in a diagnostic workflow file can be conditionally executed based on any combination of the following states: one or more program variables, one or more diagnostic primitives, and / or one or more diagnostic variables. Program variables are variables required by a program. Diagnostic variables are variables required by a diagnostic tool. Conditions for determining whether an instruction in a diagnostic workflow file is executed can include the value of a specified program variable (e.g., "if the integer variable 'i' in the program has a value of 13, then perform an action"). Conditions can also be based on states, such as "if the execution thread is named 'squid', or the name of the process is 'clam', then perform an action". The condition can be based on the state of one or more diagnostic primitives. A diagnostic primitive may be any operation that affects the state of the debugger, including, but not limited to, creating, removing, enabling, or disabling a breakpoint, changing the condition of a breakpoint (e.g., changing a breakpoint from enabled to disabled, or changing the condition on which a breakpoint is executed), enabling or disabling exceptions by type, moderating exceptions by call stack, or a debugger operation (e.g., invoking a stepping operation (step into, step over, step out)). The condition may be based on the state of a diagnostic variable, such as, but not limited to, for example, the value of a variable specifying the number of times a particular breakpoint has been hit, or if an exception of a specified type has been thrown, or if an exception has been thrown in a specified call stack.

[0016] Conditional diagnostic instructions can be dynamically inserted into the running application in any suitable manner. According to some aspects of the subject matter described herein, conditional diagnostic instructions can be dynamically inserted into the running application by, for example, injecting a function call into the snapshot runtime. Each instance of the injected breakpoint can be assigned an identifier unique at runtime. When a breakpoint is hit, the unique identifier can be passed to the diagnostic runtime. The workflow execution environment can then find a specific breakpoint in the diagnostic workflow file and apply the action specified there.

[0017] Conditional or unconditional breakpoints and / or conditional or unconditional exception handling inserted into an executing application may be non-stopping. When instrumented code is executed and a non-stopping breakpoint is encountered, instead of stopping the process and transferring control to the user, additional processing directed by the contents of the diagnostic workflow file may be performed without user interaction. Diagnostic information may be collected. The collected diagnostic information may include a lightweight snapshot of the process state.

[0018] Diagnostic Workflow for Production Debugging

[0019] A diagnostic workflow file can be created that includes diagnostic instructions that can be conditionally or unconditionally executed in a running application. The diagnostic workflow file can be used to specify conditional or unconditional breakpoint processing to be inserted into the executing code, as well as conditional or unconditional exception processing performed in a manner similar to that used for live debugging. Instead of starting live debugging, a list of breakpoint binding locations, exception states, and compiled versions of conditions can be exported to a diagnostic workflow file. The diagnostic workflow file can be applied to a running application (e.g., using code injection techniques, code rewriting mechanisms, etc.). The application can be executed in a production or non-production (e.g., development, testing, staging, etc.) environment.

[0020] A workflow including one or more instructions for one or more uniquely identified breakpoints can be specified in a diagnostic workflow file. A workflow including one or more instructions for one or more types of exceptions can be specified in a diagnostic workflow file. The exception can be identified by, for example, the exception type (or integer code, depending on the type of exception), the call stack from which the exception was thrown, the catch block that is catching the exception, and the like. After the processing to occur in the diagnostic session has been specified, the diagnostic workflow file can be compiled according to some aspects of the subject matter described herein. The diagnostic workflow file can be consumed by the diagnostic workflow engine when the target application is executed.

[0021] The diagnostic workflow engine can perform debugging operations in accordance with the guidance of the diagnostic workflow file. The diagnostic workflow engine can initialize the state (e.g., enabled or disabled) for each production diagnostic event according to the description in the workflow. For example, if a breakpoint (e.g., breakpoint 1) is enabled when another event occurs, breakpoint 1 can be initialized to a "disabled" state. Breakpoints and exception handlers can be injected into the process using a runtime profiler such as a regular language runtime (CLR) intermediate language (IL) rewrite profiler or any other suitable code rewriting technology. This allows diagnostic tools to capture various events, evaluate execution conditions, and ultimately trigger event handlers. The specified processing can include creating snapshots. The snapshot can be a lightweight process snapshot. The snapshot can reside in memory and can be accessed by diagnostic tools such as debuggers. The snapshot can be serialized to a memory dump. The memory dump can be used offline by the diagnostic tool. At runtime, as each event specified in the diagnostic workflow file occurs on the computing device, the instrumentation injected by the instrumentation engine can call the workflow engine to perform the actions described in the diagnostic workflow file, such as enabling or disabling one or more different breakpoints, walking the call stack, type checking exceptions, and can perform one or more actions based on the results of the specified processing.

[0022] Figure 1An example of a system 100 that can perform debugging based on a diagnostic workflow file according to aspects of the subject matter described herein is shown. All or part of the system 100 can reside on one or more computers or computing devices, such as those described below. Figure 3 The computer described herein. System 100 or portions thereof may be provided as a standalone system or as a plug-in or plugin. System 100 may be executed in whole or in part in an IDE such as IDE 104, or may be executed in whole or in part outside of an IDE. IDE 104 may be a computer such as reference Figure 4 The IDE described may be an IDE of IDE 100, or may be any other IDE. All or part of system 100 may be implemented as a plug-in or add-on.

[0023] System 100 or portions thereof may include information obtained from a service (e.g., in the cloud), or may operate in a cloud computing environment. A cloud computing environment may be an environment in which computing services are not owned but provided on demand. For example, information may reside on multiple devices in a networked cloud and / or data may be stored on multiple devices within the cloud.

[0024] System 100 may include one or more computing devices, such as computing device 102. Contemplated computing devices include, but are not limited to, desktop computers, tablet computers, laptop computers, notebook computers, personal digital assistants, smart phones, laptop computers, laptop computers, cellular phones, mobile phones, servers, virtual machines, devices including databases, firewalls, etc. A computing device such as computing device 102 may include one or more processors such as processor 142 and memory such as memory 144 in communication with the one or more processors.

[0025] System 100 may include any one or any combination of program modules, including: an instrumentation engine, such as instrumentation engine 114, a diagnostic workflow engine, such as workflow engine 116, and / or a debugger or diagnostic tool, such as debugger 124. An instrumentation engine (such as instrumentation engine 114) may include a diagnostic workflow engine such as workflow engine 116. The diagnostic workflow engine may be external to the instrumentation engine. System 100 may include an execution environment such as production runtime environment 106. Alternatively, the execution environment may be a development, staging, or test environment. System 100 may include a second environment, such as, but not limited to, Figure 1 A development environment represented by IDE 104 in .

[0026] According to some aspects of the subject matter described herein, a diagnostic workflow file, such as diagnostic workflow file 120, may be created by a debugger 124 in response to receiving input such as source code 128. The diagnostic workflow file may be used to control future diagnostic operations of the debugger when the debugger is executed without user interaction with the debugger. The diagnostic operations specified in the diagnostic workflow file may be conditionally executed based on the current state of the application being executed. The "current state" may include the state of diagnostic primitives (e.g., whether a breakpoint has been hit, whether an exception has been thrown) and the state of various variables (e.g., a variable value that holds the number of times a specific breakpoint has been hit, or whether an exception of a specified type has been thrown, or whether an exception has been thrown in a specified call stack) or a combination thereof. The diagnostic primitive may be any operation that affects the state of the debugger, including but not limited to creating, removing, or disabling a breakpoint, changing the condition of a breakpoint (e.g., from enabled to disabled or from disabled to enabled), enabling or disabling exceptions by type, adjusting exceptions based on the call stack where the exception was thrown, or debugger operations, such as call step operations (step into, step over, step out), etc.

[0027] The diagnostic workflow file 120 may be compiled. The diagnostic workflow file 120 or the compiled diagnostic workflow file may be provided to the instrumentation engine 114. The instrumentation engine 114 may dynamically instrument the original function 110 to create the instrumented function 112 without canceling or stopping the execution process 108. The next time the function is called, the instrumented function 112 may be executed instead of the original function 110. According to some aspects of the subject matter described herein, the original function 110 is rewritten to create the instrumented function 112 using a code rewrite mechanism. According to some aspects of the subject matter described herein, the original function 110 is rewritten to create the instrumented function 112 by the instrumentation engine 114.

[0028] A diagnostic workflow engine such as workflow engine 116 can perform the processing specified in the diagnostic workflow file 120. For example, if the first breakpoint (breakpoint A) has been encountered, the diagnostic workflow engine can enable the second breakpoint (breakpoint B). If an exception of a specified type is thrown, the diagnostic workflow engine can enable a specific breakpoint. If an exception of a specified type is thrown in a specified call stack, the diagnostic workflow engine can enable a specific breakpoint. If the first conditional breakpoint (breakpoint A) is not hit (because, for example, the conditions required by the first conditional breakpoint are not met), the diagnostic workflow engine can enable the second conditional breakpoint (breakpoint B). If an exception of a specified type is thrown, the diagnostic workflow engine can disable a specific breakpoint. If a second breakpoint is encountered in a session or process different from the first breakpoint (e.g., breakpoint A), the diagnostic workflow engine can disable the second breakpoint (e.g., breakpoint B). If a code segment takes longer than a threshold to execute (e.g., a code segment can depend on an event that affects performance), the diagnostic workflow engine can enable a specific breakpoint. If the specified breakpoint has been hit, the diagnostic workflow engine can enable the creation of a dump at a first chance exception of a specified type. If a specific specified breakpoint has been hit, the diagnostic workflow engine can disable the creation of a dump at a first chance exception of a specific type. If an exception is encountered on the same thread as the second identified breakpoint, the diagnostic workflow engine can enable the specific breakpoint. A diagnostic workflow engine such as diagnostic workflow engine 116 can collect and maintain and / or save debug information (debug artifacts) such as debug information 118.

[0029] Figure 2 An example of a method 200 for creating and executing a diagnostic workflow file in accordance with aspects of the subject matter described herein is shown. Figure 2 The system shown in can be composed of, for example, but not limited to, Figure 2 The system described in the present invention is implemented. Although method 200 describes a series of steps or operations performed in a sequence, it should be understood that method 200 is not limited by the order of the sequence described. For example, some operations can occur in an order different from the described order. In addition, an operation can occur simultaneously with another operation. In some cases, not all operations described are performed.

[0030] In operation 206, a diagnostic workflow file as more fully described above may be created. The diagnostic workflow file may be compiled. In operation 208, the diagnostic workflow file may be sent to a debugging environment. The diagnostic workflow file may be received from a development, test, or staging computing machine. The diagnostic workflow file may be received by a production runtime environment on the same computing device or another computing device.

[0031] In operation 210, the function can be instrumented to produce an instrumented function that is executed the next time the function is called. The function can be instrumented by one or more program modules loaded into a memory connected to a processor of a computing machine. In operation 212, the instrumented function can be executed. The instrumented function can be executed by a processor of a computing device. The instrumented function can be processed by a diagnostic workflow engine that determines the state, and the diagnostic operations specified in the diagnostic workflow file can be performed, as described more fully above. In operation 214, debugging information (e.g., diagnostic artifacts) can be collected. In operation 216, a workflow state can be provided. The workflow state can be provided as a display, a report, written to a storage medium, or by any means known to those skilled in the art.

[0032] According to various aspects of the subject matter described herein, a computer system may include one or more processors, a memory connected to one or more processors, and a diagnostic tool. The diagnostic tool may include one or more program modules that may cause one or more processors to create a diagnostic workflow file when loaded into the memory. The diagnostic workflow file may automatically control future diagnostic operations of a debugger (when the debugger is executed without a user interacting with the debugger). The diagnostic workflow file may include one or more diagnostic operations. The diagnostic workflow file may specify that the diagnostic operation is conditional based on the current state of the program being executed. The current state may include the state of one or more diagnostic primitives. The current state may include the state of one or more diagnostic variables. The current state may include the state of one or more program variables. The execution of a conditional diagnostic operation may depend on a combination of the state of one or more diagnostic primitives, one or more program variables, and one or more diagnostic variables.

[0033] A method of using a system such as the above system may include operations such as receiving a diagnostic workflow file by a processor of a computing device. The diagnostic workflow file may include one or more conditional diagnostic operations to be performed, wherein the conditional diagnostic operations are performed depending on the current state of one or more of a program variable, a diagnostic primitive, and a diagnostic variable. The current state of one or more program variables, diagnostic primitives, and / or diagnostic variables may be determined. In response to determining that a condition is satisfied, diagnostic information may be collected. The diagnostic information may be collected by making a snapshot of process data. The state of the diagnostic information may be displayed (e.g., to a user). The diagnostic primitive may be an instruction for: creating a breakpoint, deleting a breakpoint, enabling a breakpoint, disabling a breakpoint, changing a breakpoint condition, enabling an exception according to an exception type, disabling an instruction exception according to a type, adjusting an exception according to a call stack from which the exception is thrown, and performing a debugging operation (such as a step operation). The state of a diagnostic variable may be determined. The diagnostic variable may be a variable used in a debugging operation in a diagnostic workflow file.

[0034] The computer-readable storage medium may include computer-readable instructions that, when executed, cause one or more processors of a computing device to automatically control diagnostic operations (process debugging) of an instrumented executable in a target process using instructions provided in a diagnostic workflow file. The instructions may cause the processor to collect diagnostic information. The computer-readable storage medium may include other computer-readable instructions that collect diagnostic information to be provided to a diagnostic tool such as a debugger. The computer-readable storage medium may include other computer-readable instructions that, when executed, insert instrumented code into a function to generate an instrumented function when the target process is executed. The computer-readable storage medium may include other computer-readable instructions that, when executed, determine the state of a diagnostic primitive. The diagnostic primitive may be the following operations: create a breakpoint, delete a breakpoint, enable a breakpoint, disable a breakpoint, change the condition of a breakpoint, enable an exception if it is a specified type, disable an exception if it is a specified type, and adjust the exception according to whether the exception is thrown in a specified call stack performing a stepping operation. The computer-readable storage medium may include other computer-readable instructions that, when executed, determine the state of a diagnostic variable used to perform a debugging operation. The computer-readable storage medium may include other computer-readable instructions that, when executed, determine the current state of a diagnostic primitive. The computer-readable storage medium may include other computer-readable instructions that, when executed, determine a state of a diagnostic variable referenced in a diagnostic workflow file.

[0035] Examples of suitable computing environments

[0036] To provide context for various aspects of the subject matter disclosed herein, Figure 3 The following discussion is intended to provide a brief general description of a suitable computing environment 510 in which various embodiments of the subject matter disclosed herein may be implemented. Although the subject matter disclosed herein is described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other computing devices, those skilled in the art will recognize that portions of the subject matter disclosed herein may also be implemented in conjunction with other program modules and / or combinations of hardware and software. Typically, program modules include routines, programs, objects, physical artifacts, data structures, etc. that perform specific tasks or implement specific data types. Typically, in various embodiments, the functionality of program modules may be combined or distributed as desired. The computing environment 510 is only one example of a suitable operating environment and is not intended to limit the scope of use or functionality of the subject matter disclosed herein.

[0037] refer to Figure 3, describes a computing device in the form of a computer 512. The computer 512 may include at least one processing unit 514, a system memory 516, and a system bus 518. The at least one processing unit 514 may execute instructions stored in a memory such as, but not limited to, the system memory 516. The processing unit 514 may be any of a variety of available processors. For example, the processing unit 514 may be a graphics processing unit (GPU). The instructions may be instructions for implementing the functions performed by one or more of the above components or modules or instructions for implementing one or more of the above methods. Dual microprocessors and other multi-processor architectures may also be used as the processing unit 514. The computer 512 may be used in a system that supports rendering graphics on a display screen. In another example, at least a portion of the computing device may be used in a system that includes a graphics processing unit. The system memory 516 may include a volatile memory 520 and a non-volatile memory 522. The non-volatile memory 522 may include a read-only memory (ROM), a programmable ROM (PROM), an electrically programmable ROM (EPROM), or flash memory. The volatile memory 520 may include a random access memory (RAM) that may be used as an external cache memory. The system bus 518 couples the system physical article including the system memory 516 to the processing unit 514. The system bus 518 may be any of several types, including a memory bus, a memory controller, a peripheral bus, an external bus, or a local bus, and may use any of a variety of available bus architectures. The computer 512 may include data storage accessible by the processing unit 514 through the system bus 518. The data storage may include executable instructions for graphics rendering, 3D models, materials, textures, etc.

[0038] The computer 512 typically includes various computer readable media, such as volatile and non-volatile media, removable and non-removable media. Computer readable media can be implemented in any method or technology for storing information such as computer readable instructions, data structures, program modules or other data. Computer readable media include computer readable storage media (also called computer storage media) and communication media. Computer storage media include physical (tangible) media such as but not limited to RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disk (DVD) or other optical disk storage, cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices that can store the desired data and can be accessed by the computer 512. Communication media include media such as but not limited to communication signals, modulated carrier waves or any other intangible media that can be used to transmit the desired information and can be accessed by the computer 512.

[0039] It should be understood that Figure 3Software that can act as an intermediary between a user and computer resources is described. The software may include an operating system 528 that can be stored on disk storage 524 and can allocate resources of computer 512. Disk storage 524 may be a hard drive that is connected to system bus 518 through a non-removable memory interface such as interface 526. System applications 530 utilize operating system 528 to manage resources through program modules 532 and program data 534 stored in system memory 516 or disk storage 524. It should be understood that the computer can utilize various operating systems or combinations of operating systems.

[0040] A user may enter commands or information into the computer 512 via input devices 536. Input devices 536 include, but are not limited to, pointing devices such as a mouse, trackball, stylus, touchpad, keyboard, microphone, voice recognition and gesture recognition systems, and the like. These and other input devices are connected to the processing unit 514 via interface ports 538 through the system bus 518. Interface ports 538 may represent serial ports, parallel ports, universal serial bus (USB), and the like. Output devices 540 may use the same type of ports as input devices. Output adapters 542 are provided to illustrate that there are some output devices 540, such as monitors, speakers, and printers that require specific adapters. Output adapters 542 include, but are not limited to, video and sound cards that provide connections between output devices 540 and the system bus 518. Other devices and / or systems or devices (e.g., remote computers 544) may provide input and output capabilities.

[0041] Computer 512 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer 544. Remote computer 544 can be a personal computer, server, router, network PC, peer device or other conventional network node, and typically includes many or all of the elements described above with respect to computer 512, although in Figure 1 Only memory storage 546 is shown. Remote computers 544 may be logically connected via communication connection 550. Network interface 548 includes communication networks such as local area networks (LAN) and wide area networks (WAN), but may also include other networks. Communication connection 550 refers to the hardware / software used to connect network interface 548 to system bus 518. Communication connection 550 may be internal or external to computer 512 and include internal and external technologies such as modems (telephone, cable, DSL and wireless) and ISDN adapters, Ethernet cards, etc.

[0042] It should be understood that the network connection shown is only an example, and other means of establishing a communication link between computers can be used. It will be appreciated by those of ordinary skill in the art that computer 512 or other client devices can be deployed as a part of a computer network. In this regard, the subject matter disclosed herein can be related to any computer system with any number of memories or storage units and any number of applications and processes that occur on any number of storage units or volumes. The various aspects of the subject matter disclosed herein can be applied to an environment having a server computer and a client computer deployed in a network environment, with remote or local storage. The various aspects of the subject matter disclosed herein can also be applied to an independent computing device with programming language functions, interpretation and execution capabilities.

[0043] The various techniques described herein may be implemented in combination with hardware or software or with a combination of both when appropriate. Therefore, the methods and devices described herein or some aspects or parts thereof may be implemented in a program code (i.e., instructions) embodied in a tangible medium such as a floppy disk, a CD-ROM, a hard disk drive, or any other machine-readable medium, wherein when the program code is loaded into a machine such as a computer and executed by the machine, the machine becomes a device for practicing various aspects of the subject matter disclosed herein. As used herein, the term "machine-readable storage medium" will be understood to exclude any mechanism for providing (i.e., storing and / or transmitting) any form of propagation signal. In the case of executing program code on a programmable computer, the computing device will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. One or more programs that can be created and / or implemented using domain-specific programming models, such as by using a data processing API, etc., can be implemented in a high-level process or object-oriented programming language for communicating with a computer system. However, if necessary, the program can be implemented in assembly or machine language. In any case, the language can be a compiled or interpreted language and combined with a hardware implementation.

[0044] Figure 4An integrated development environment (IDE) 600 and a conventional language runtime environment 602 are shown. IDE 600 can allow a user (e.g., developer, programmer, designer, coder, etc.) to design, code, compile, test, run, edit, debug or build programs, assemblies, websites, web applications and web services in a computer system. Software programs can include one or more source code languages ​​(e.g., Visual Basic, Visual J#, C++, C#, J#, JavaScript, APL, COBOL, Pascal, Eiffel, Haskell, ML, Oberon, Perl, Python, Scheme, Smalltalk, etc.). IDE 600 can provide a native code development environment, or can provide managed code development running on a virtual machine, or can provide a combination thereof. IDE 600 can provide a managed code development environment using the .NET framework. An intermediate language component 650 may be created from source code component 610 and native code component 611 using a language specific source compiler 620, and native code component 611 (e.g., machine executable instructions) may be created from intermediate language component 650 using an intermediate language compiler 660 (e.g., a just-in-time (JIT) compiler) when the application is executed. That is, when the IL application is executed, it is compiled and executed into the appropriate machine language for the platform being executed, thereby making the code portable across multiple platforms. Alternatively, in other embodiments, the program may be compiled into a native machine language suitable for its intended platform (not shown).

[0045] A user may create and / or edit source code components according to known software programming techniques and specific logic and grammatical rules associated with a particular source language via a user interface 640 and a source code editor 651 in IDE 600. Thereafter, source code components 610 may be compiled via source compiler 620, thereby creating an intermediate language representation of the program, such as component 630. Component 630 may include intermediate language component 650 and metadata 642. The application design may be validated before deployment.

[0046] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A method for collecting diagnostic information, comprising: receiving, by a processor of a computing device, a diagnostic workflow file including instructions for controlling future diagnostic operations of the debugger when executed by the debugger without user interaction with the debugger, the instructions including at least one conditional diagnostic operation, the at least one conditional diagnostic operation being performed based on a value of a program variable; determining the value of the program variable; and Collect diagnostic information.

2. The method according to claim 1, further comprising: The diagnostic information is collected by taking snapshots of process data.

3. The method according to claim 1, further comprising: Displays the status of the diagnostic information.

4. The method of claim 1 , wherein determining the value of the program variable further comprises: Based on the value of the program variable, the at least one conditional diagnostic operation is applied.

5. The method according to claim 1, wherein said at least one conditional diagnostic operation is performed based on a combination of said value of said program variable and a current state of a diagnostic primitive or a current state of a diagnostic variable; and Wherein determining the value of the program variable further comprises: A current state of the diagnostic primitive or a current state of the diagnostic variable is determined.

6. The method according to claim 5, wherein collecting the diagnostic information further comprises: The diagnostic information is collected based on the determination of the value of the program variable, the determination of the current state of the diagnostic primitive, or the determination of the current state of the diagnostic variable.

7. A system for collecting diagnostic information, comprising: at least one processor and memory; wherein the at least one processor is configured to: obtaining a diagnostic workflow file, the diagnostic workflow file comprising one or more conditional diagnostic instructions, the one or more conditional diagnostic instructions comprising one or more future diagnostic operations of the debugger to be performed based on the occurrence of one or more conditions without user interaction with the debugger; dynamically inserting the conditional diagnostic instruction into the executing program without stopping the executing program; based on the occurrence of the one or more conditions in the execution of the program, applying at least one future diagnostic operation associated with the occurrence of the condition without stopping the execution of the program; as well as Collect diagnostic information.

8. The system of claim 7, wherein the one or more conditions are based on values ​​of program variables, diagnostic primitives and / or diagnostic variables.

9. The system of claim 7, wherein the inserted conditional diagnostic instruction performs a call to a debug workflow engine that applies at least one future diagnostic operation of the one or more future diagnostic operations.

10. The system of claim 7, wherein the inserted conditional diagnostic instruction comprises at least one of: enabling a breakpoint, disabling a breakpoint, walking a call stack, or a type check exception.

11. The system of claim 7, wherein the at least one processor is further configured to provide the diagnostic information to the debugger.

12. The system of claim 7, wherein the at least one processor is further configured to inject a breakpoint handler into the process of executing the program.

13. The system of claim 7, wherein the inserted conditional diagnostic instructions include a non-stop breakpoint that enables at least one of the one or more future diagnostic operations to be performed without user intervention.

14. The system of claim 7, wherein the diagnostic information comprises a lightweight snapshot of the state of the process of executing the program.

15. A device for generating diagnostic information, comprising: at least one processor and memory; a debugger that receives diagnostic information from program execution; a diagnostic workflow file comprising instructions for controlling future diagnostic operations of the debugger when executed by the debugger without user interaction with the debugger, the instructions comprising at least one conditional diagnostic operation performed based on a value of a program variable, a state of a diagnostic variable, and / or a state of a diagnostic primitive; as well as A diagnostic workflow engine is provided to generate the diagnostic information during execution of the program without stopping the program, the diagnostic workflow engine generating the diagnostic information based on the values ​​of the program variables, the states of the diagnostic variables and / or the occurrence of the states of diagnostic primitives.

16. The apparatus according to claim 15, further comprising: An instrumentation engine inserts instructions into a function of the program, the inserted instructions being configured to call the diagnostic workflow engine to perform the at least one conditional diagnostic operation without stopping the program.

17. The apparatus of claim 15, wherein the diagnostic variables include: A variable indicating the number of times a breakpoint has been hit, a variable indicating whether an exception of a specified type has occurred, and a variable indicating whether an exception has occurred up the call stack.

18. The apparatus of claim 15, wherein the diagnostic primitives include: Create breakpoints, remove breakpoints, disable breakpoints, enable breakpoints, change the condition of a breakpoint, enable exceptions based on their type, disable exceptions based on their type, adjust exceptions based on the call stack, and step operations.

19. The apparatus of claim 15, further comprising: A runtime profiler inserts one or more breakpoint handlers and / or one or more exception handlers into the process of executing the program.

20. The apparatus of claim 15, wherein the debugger receives the diagnostic information during a debugging session.

Images