Abstract: A profiler may be detached from an actively running application by first sealing communications between the application and profiler, then evacuating the profiler by waiting for any profiler-modified or instrumented code to complete execution, profiler runtime code to complete execution, cleaning up any residual items from the profiler, and shutting down the profiler. The profiler may be operational in many different environments, including a managed environment such as a virtual machine and those environments having just in time compiling of executable code.

Abstract: A runtime activation system uses a set of policies designed to provide a balance between backwards compatibility and ease of migrating existing (non side-by-side aware) applications to new runtime versions. The system chooses the runtime version to activate when an application runs or when a runtime application programming interface is invoked based on the set of policies. The system implements these policies by consulting compatibility data associated with the application indicating the intent of the author and level of side-by-side support provided by the application and/or global configuration data. Based on the compatibility data, the system chooses policies that are right in the most common cases, and easy to modify in less common cases. Thus, the runtime activation system allows applications to be flexibly configured to handle new runtime versions in a manner determined by the application author, a system administrator, or others.

Abstract: A profiler manager may attach and detach profilers from a running application. A profiler may be detached through a two step process where the profiler is sealed from communicating with the running application, then an evacuation step where the application is able to complete any responses that are pending. While the profiler is in the evacuation phase, another profiler may be attached to the application. Messages to the evacuating profiler may be captured and directed to the proper profiler.

Abstract: A runtime activation system uses a set of policies designed to provide a balance between backwards compatibility and ease of migrating existing (non side-by-side aware) applications to new runtime versions. The system chooses the runtime version to activate when an application runs or when a runtime application programming interface is invoked based on the set of policies. The system implements these policies by consulting compatibility data associated with the application indicating the intent of the author and level of side-by-side support provided by the application and/or global configuration data. Based on the compatibility data, the system chooses policies that are right in the most common cases, and easy to modify in less common cases. Thus, the runtime activation system allows applications to be flexibly configured to handle new runtime versions in a manner determined by the application author, a system administrator, or others.

Abstract: A call stack includes at least one frame of managed code and at least one frame of unmanaged code. In a multithreaded environment, a request from a diagnostic tool to a tracing function for the call stack is made on a thread that is not associated with the call stack. The tracing function preserves a context for a thread associated with the call stack until the call stack tracing function ends. In a particular embodiment, a method grants access to a stackwalking function, such that when a point on the call stack is designated in a request for the stackwalking function, the stackwalking function commences at the point on the call stack. When no point on the call stack is designated in the request for the stackwalking function, a default position on the call stack is determined based on a last managed frame pushed onto the call stack and the stackwalking function commences at the default position on the call stack.

Abstract: The techniques and mechanisms described herein are directed to a method for virtually catching an exception. A debugger receives a notification identifying information about an exception that occurred during execution of an application. The debugger then selectively chooses a location on a call stack where execution of the application resumes after the stack is unwound up to the selected location. The location being between a statement on the stack causing the exception and a handler on the stack. The handler being identified during a search phase for exception processing. The mechanism being operative for both handled exceptions and unhandled exceptions.

Abstract: A profiler may be detached from an actively running application by first sealing communications between the application and profiler, then evacuating the profiler by waiting for any profiler-modified or instrumented code to complete execution, profiler runtime code to complete execution, cleaning up any residual items from the profiler, and shutting down the profiler. The profiler may be operational in many different environments, including a managed environment such as a virtual machine and those environments having just in time compiling of executable code.

Abstract: A profiler manager may attach and detach profilers from a running application. A profiler may be detached through a two step process where the profiler is sealed from communicating with the running application, then an evacuation step where the application is able to complete any responses that are pending. While the profiler is in the evacuation phase, another profiler may be attached to the application. Messages to the evacuating profiler may be captured and directed to the proper profiler.

Abstract: A system and method are provided for encoding data in accordance with the present invention. The system includes a first subsystem for encoding a second data protocol within a formatted data protocol without disrupting display operations associated with the first data protocol. An encapsulation sequence is provided to isolate the second data protocol from the formatted data protocol, wherein a monitoring subsystem receives status from the first subsystem via the second data protocol.

Abstract: Stackwalking functionality in a managed execution environment may be exposed to a profiler in another execution environment, which may be either an unmanaged or managed execution environment.

Abstract: The techniques and mechanisms described herein are directed to a method for virtually catching an exception. A debugger receives a notification identifying information about an exception that occurred during execution of an application. The debugger then selectively chooses a location on a call stack where execution of the application resumes after the stack is unwound up to the selected location. The location being between a statement on the stack causing the exception and a handler on the stack. The handler being identified during a search phase for exception processing. The mechanism being operative for both handled exceptions and unhandled exceptions.

Abstract: A system and method are provided for encoding data in accordance with the present invention. The system includes a first subsystem for encoding a second data protocol within a formatted data protocol without disrupting display operations associated with the first data protocol. An encapsulation sequence is provided to isolate the second data protocol from the formatted data protocol, wherein a monitoring subsystem receives status from the first subsystem via the second data protocol.

Abstract: A system and method are provided for encoding data in accordance with the present invention. The system includes a first subsystem for encoding a second data protocol within a formatted data protocol without disrupting display operations associated with the first data protocol. An encapsulation sequence is provided to isolate the second data protocol from the formatted data protocol, wherein a monitoring subsystem receives status from the first subsystem via the second data protocol.

Abstract: Methods and systems for recognizing a client computer as a replacement for a previous client computer or as being new to a computer network. When a client computer is connected to a server in a computer network, the client computer sends its unique identifier to the server. The server compares the unique identifier against a list of known unique identifiers. If the server determines that the unique identifier is unknown, the client computer prompts the user to select one of a list of user options, which include, for example, a replacement computer option and a new computer option. If the user selects the replacement computer option, the user also identifies the previous computer that has been replaced. The server then replaces the previous computer's unique identifier with the replacement computer's unique identifier, and assigns the replacement computer to an appropriate server computer.

Abstract: Methods and systems for adjusting an operating system configuration according to changes in hardware components of a client computer. The adjusted operating system can boot on the client computer regardless of changes in the hardware configuration of the client computer since it was last connected to a network server. Before the operating system boots, a preliminary connection is established between the client computer and the server. During the preliminary connection, the system identifies hardware components that are new and that must be supported by the operating system for bootup to occur. In particular, the server sends information relating to the previous client hardware configuration to the client computer. The client computer compares its current hardware configuration to the previous hardware configuration information, thereby identifying its new hardware components. Information identifying the new hardware components is sent to the server.