Coordination of error reporting among multiple managed runtimes in the same process

Systems and methods are described for coordinating error reporting among a plurality of managed runtimes that are concurrently executing in the same process. In accordance with various embodiments, an error reporting manager that executes concurrently in the same process as the managed runtimes coordinates error reporting among the managed runtimes in a manner that does not require the managed runtimes to be aware of each other or to communicate directly with each other.

BACKGROUND

As used herein, the term native application refers to an application that is designed to run natively (i.e., without translators or other intermediary mechanisms) on an operating system executing on a processor-based computer system. In contrast, a managed application refers to an application that is not capable of running natively on the operating system, but is instead designed to run in an environment provided by a managed runtime executing on top of the operating system. The managed runtime manages the execution of the managed application and provides services thereto. Among other features, the managed runtime may provide a just-in-time compiler that converts the code of a managed application into code native to the operating system at runtime. By using managed runtimes, applications that have been compiled for a single architecture can be run on many different machines. Examples of managed runtimes include the Common Language Runtime published by Microsoft Corporation of Redmond, Wash., and the Java Runtime Environment published by Sun Microsystems of Santa Clara, Calif.

When the execution of a managed application is initiated on a processor-based computer system, the operating system is prompted to load the appropriate managed runtime to facilitate execution of the managed application. In certain computing environments, it is now possible to concurrently run more than one managed runtime in a single process. This feature enables a native or managed application to invoke the features of one or more additional managed applications, wherein each managed application is supported by its own managed runtime. One advantage of the ability to concurrently run multiple managed runtimes in a single process is that managed applications written for different versions of the same managed runtime can be concurrently executed within the same process without concerns about compatibility. For example, managed applications written for different versions of the Common Language Runtime may be executed concurrently within the same process by loading the appropriate version of the Common Language Runtime to support each managed application.

Certain challenges arise when attempting to operate a computing environment in which more than one managed runtime can run concurrently in the same process. For example, when two or more managed runtimes are running concurrently in the same process and one of the managed runtimes fails unexpectedly, each managed runtime may independently attempt to report an application error even when the managed runtime did not itself cause the failure. This results in the generation of multiple error reports, with only one of the reports coming from the failing managed runtime, which has the context of the original failure to be used to generate a useful error report. The generation of multiple error reports in this manner provides a poor user experience. Furthermore, the generation of multiple error reports in this manner could mislead subsequent investigations into the cause of the failure since only the error report generated by the failing managed runtime is useful for investigation.

In order to provide a reasonable error reporting user experience, it would appear that some sort of cooperation is required between the different managed runtimes running in the same process. For example, let it be assumed that a failure occurs due to an unhandled exception thrown by a first managed runtime executing on a thread and that a second managed runtime owns the base of the thread. In this case, only the first managed runtime will have the information necessary to produce a useful error report. However, due to the way exceptions are managed in some computing environments, only the second managed runtime may have the information necessary to determine whether the exception is fatal and that an error report should be triggered. Since the first and second managed runtimes are designed to be unaware of each other and do not communicate directly, the result may be that only the second managed runtime produces an error report, but the error report is not useful. Other possible results due to this lack of cooperation between the managed runtimes is that no error reports are generated or that multiple error reports are generated, but at best only one of the error reports is useful.

Commonly-owned co-pending U.S. patent application Ser. No. 12/358,708, filed on Jan. 23, 2009, describes a customized error reporting system that can be used to coordinate error reporting among multiple managed runtimes concurrently running in the same process. However, the error reporting facilities described in this application are provided as part of an operating system. As such, the approach to coordinating error reporting described in that application will only work in a system in which the operating system has been built or modified to include the described facilities. Otherwise, the concurrent execution of multiple runtimes in the same process will lead to the various problems described above.

What is needed then is a system and method for coordinating error reporting among multiple runtimes that are concurrently executing in the same process. The desired system and method should address one or more of the problems described above, including but not limited to the generation of error reports that are not useful and/or the generation of multiple error reports by the managed runtimes. The desired system and method should also address the problem(s) in a manner that is not dependent on facilities built or added into a particular operating system.

SUMMARY

Systems and methods are described herein for coordinating error reporting among a plurality of managed runtimes that are concurrently executing in the same process. In accordance with various embodiments, an error reporting manager that executes concurrently in the same process as the managed runtimes coordinates error reporting among the managed runtimes in a manner that does not require the managed runtimes to be aware of each other or to communicate directly with each other. By performing such coordination, the error reporting manager operates to ensure that if the process crashes, at most one error report will be generated by the managed runtime that caused the failure or the first managed runtime that encounters an error that does not come from any of the managed runtimes in the process. By performing such coordination, the error reporting manager also operates to ensure that the managed runtime that caused the failure will claim the error and will generate the error reporting information. Because the error reporting manager performs this coordination in-process, it provides an approach to managing error reporting among multiple managed runtimes concurrently running in the same process in a manner that is not dependent on facilities built or added into a particular operating system. Thus, this approach to managing error reporting can conceivably be implemented on different systems running different versions of the same operating system, or different operating systems entirely.

DETAILED DESCRIPTION

II. Example Systems and Methods for Coordinating Error Reporting Among Multiple Managed Runtimes Concurrently Running in the Same Process

FIG. 1is a block diagram of a system that coordinates error reporting among multiple managed runtimes concurrently running in the same process in accordance with one example embodiment. As shown inFIG. 1, the system is implemented on a user machine100, which is intended to broadly represent any processor-based computer system or platform upon which software may be executed for the benefit or a user. For example and without limitation, user machine100may comprise a desktop computer, a laptop computer, a tablet computer, a video game console, a personal digital assistant, a smart phone, or a portable media player. A specific example of a user machine upon which the system ofFIG. 1may be implemented will be described subsequently herein in reference toFIG. 5.

As shown inFIG. 1, an operating system110is installed on user machine110and is executed thereon. Operating system110acts as a host for software applications running on user machine110. For example, operating system110manages and coordinates the sharing of the resources of user machine110by various applications running thereon. Operating system110also interfaces with various hardware elements of user machine110on behalf of applications, thereby relieving the applications from having to manage details of hardware operations and making the applications easier to write. Operating system110may offer a number of services to applications and users. Applications access these services through application programming interfaces (APIs) or system calls. By invoking these interfaces, an application can request a service from operating system110, pass parameters thereto, and receive results therefrom. Depending upon the implementation, users may interact with operating system110via a software user interface (SUI) such as a command line interface (CLI) or a graphical user interface (GUI). For handheld and desktop computers, the user interface is generally considered part of operating system110. On larger multi-user systems, the user interface is generally implemented as an application program that runs on top of operating system110.

In one embodiment, operating system110comprises a WINDOWS® XP, WINDOWS® VISTA® or WINDOWS® 7 operating system published by Microsoft Corporation of Redmond, Wash. However, this example is not intended to be limiting, and operating system110may comprise any conventional or subsequently-developed operating system that is designed to perform at least one or more of the aforementioned functions.

As shown inFIG. 1, a process120is running on top of operating system110. A process includes an instance of computer code, such as an application, that is being executed by user machine100. To accommodate the fact that some applications are programmed to call or invoke other applications, a single process may include multiple concurrently-executing applications. Applications may be native or managed. A native application is an application that is designed to run natively (i.e., without translators or other intermediary mechanisms) on an operating system while a managed application refers to an application that is not capable of running natively on the operating system, but is instead designed to run in an environment provided by a managed runtime executing on top of the operating system. When the execution of a managed application is initiated on a processor-based computer system, the operating system is prompted to load the appropriate managed runtime to facilitate execution of the managed application.

In certain computing environments, it is possible to concurrently run more than one managed runtime in a single process. The system ofFIG. 1represents an example of such a computing environment. As shown in that figure, process120includes multiple concurrently-executing managed runtimes1301through130N. Each of the managed runtimes has been loaded by operating system110to support the execution of one or more managed applications in process120. For example, managed runtime1301has been loaded to support the execution of one or more managed applications1401and managed runtime130Nhas been loaded to support the execution of one or more managed applications140N. In one embodiment, each managed runtime comprises a version of the Common Language Runtime published by Microsoft Corporation of Redmond, Wash. However, this is only one example, and the managed runtimes may include other managed runtimes including but not limited to the Java Runtime Environment published by Sun Microsystems of Santa Clara, Calif., the ADOBE® FLASH® Player published by Adobe Systems of San Jose, Calif., a Ruby programming language runtime environment, a Python programming language environment, or the like.

One advantage of the ability to concurrently run multiple managed runtimes in a single process is that managed applications written for different versions of the same managed runtime can be concurrently executed within the same process without concerns about compatibility. For example, managed applications written for different versions of the Common Language Runtime may be executed concurrently within the same process by loading the appropriate version of the Common Language Runtime to support each managed application.

As further shown inFIG. 1, operating system includes an error reporting service122. Among other features, error reporting service122collects data about native and managed applications running on operating system110that experience failures. Such information may be stored locally on user machine100and/or transmitted to a remote server (not shown inFIG. 1) that aggregates such information so that patterns that reveal the source of failures can be identified. The transmission of the information to the remote server may be carried out, for example, over a local area network or wide area network, such as the Internet. In certain embodiments, the error reporting information stored locally on user machine100, or a subset of such information, may be viewed by a user of user machine100via a GUI provided by operating system110.

Depending upon the implementation, when error reporting service122becomes aware of a failed application, it may cause a dialog box to be presented to a user via a GUI provided by operating system110that asks the user if an error report should be transmitted to a remote server and/or if the user wishes to debug the failed application.

Each of managed runtimes1301-130Nincludes logic for reporting error information on behalf of a failing managed application to error reporting service122. A managed runtime may trigger error reporting, for example, when it determines that a managed application has thrown an unhandled exception. An unhandled exception indicates a problem with an application. Certain problems, such as invalid input, are anticipated by application developers and handlers for certain exceptions may be provided within an application. But, when an exception is not handled by the application, the application is no longer in an operational state (e.g., it has “crashed”). A managed runtime may also trigger error reporting, for example, if a managed application fails to respond for a period of time. This condition is sometimes referred to an “application hang.” An application hang may be caused by a number of conditions, such as encountering an infinite loop in the application code, a deadlock condition, or resource starvation. An application may request the managed runtime that executes the application to trigger error reporting when it detects a logic error, a security risk or corrupted state.

As described in the Background Section above, certain challenges arise when attempting to operate a computing environment in which more than one managed runtime can run concurrently in the same process and each is capable of independently reporting an application error. As described in that section, this may result in the generation of no error reports for a failure, or the generation of multiple error reports where at best only one of the error reports is useful. To address this issue, user machine100includes an in-process component denoted error reporting manager132that coordinates error reporting among managed runtimes1301-130Nin a manner that does not require the managed runtimes to be aware of each other or to communicate directly with each other. By performing such coordination, error reporting manager132operates to ensure that if process120crashes, at most one error report will be generated by the managed runtime that caused the failure or the first managed runtime that encounters an error that does not come from any of managed runtimes in the process. By performing such coordination, error reporting manager132also operates to ensure that the managed runtime that caused the failure will claim the error and will generate the error reporting information if there is no other concurrent and different error being processed in the process. If there are two or more concurrent and different errors being processed in the process, the first managed runtime that is ready to report an error will report an error.

Because error reporting manager132performs this coordination in-process, it provides an approach to managing error reporting among multiple managed runtimes concurrently running in the same process in a manner that is not dependent on facilities built or added into a particular operating system. Thus, this approach to managing error reporting can conceivably be implemented on different systems running different versions of the same operating system, or different operating systems entirely.

FIG. 2is a block diagram of error reporting manager132in accordance with one embodiment. As shown inFIG. 2, error reporting manager132includes a plurality of APIs by which each managed runtime that is running concurrently in a process along with error reporting manager132can communicate with error reporting manager132. These APIs include a RegisterErrorClaimingCallback API202, an UnregisterErrorClaimingCallback API204, a HasErrorReportingBeenTriggered API206, an IsErrorClaimed API208, an IsCurrentRuntimeAllowedtoReportError API210, a WaitForErrorReportingCompletionEvent API212, and a SignalErrorReportingCompletionEvent API214. A brief description of each of these APIs will now be provided.

RegisterErrorClaimingCallback API202may be invoked by a managed runtime to register an error claiming callback with error reporting manager132. In an embodiment, each managed runtime in a process will invoke RegisterErrorClaimingCallback API202to register an error claiming callback with error reporting manager132during startup of the managed runtime.

UnregisterErrorClaimingCallback API204may be invoked by a managed runtime to unregister an error claiming callback that was previously registered with error reporting manager132. In an embodiment, each managed runtime in a process will invoke UnregisterErrorClaimingCallback API204during shutdown of the managed runtime to unregister an error claiming callback that was previously registered with error reporting manager132.

HasErrorReportingBeenTriggered API206may be invoked by a managed runtime to determine whether error reporting has already been initiated for the process in which the managed runtime is running In one embodiment, responsive to the invocation of HasErrorReportingBeenTriggered API206by a managed runtime, error reporting manager132will return TRUE to the managed runtime if error reporting has already been initiated for the process and will return FALSE to the managed runtime if error reporting has not already been initiated for the process.

IsErrorClaimed API208may be invoked by a managed runtime to determine if an error that has been encountered by the managed runtime has been claimed by any other managed runtime concurrently running in the same process. In one embodiment, in response to invocation of this API by a managed runtime, error reporting manager132will iterate through all registered exception claiming callbacks, invoking a callback to each registered managed runtime. In response to the callback, each registered managed application will either return TRUE if it claims the error or FALSE if it does not claim the error. If any managed application returns TRUE, then error reporting manager will return TRUE to the managed runtime that invoked IsErrorClaimed API208. However, if no managed application returns TRUE, then error reporting manager132will return FALSE to the managed runtime that invoked IsErrorClaimed API208.

IsCurrentRuntimeAllowedToReportError API210may be invoked by a managed runtime to determine if the managed runtime is permitted to initiate the reporting of information about an error encountered and/or claimed by the managed runtime. In an embodiment, in response to the invocation of IsCurrentRuntimeAllowedToReportError API210by a managed runtime, error reporting manager132will return FALSE to the managed runtime if error reporting has already been initiated for the process. If error reporting has not yet been initiated for the process, but two or more managed runtimes have concurrently called IsCurrentRuntimeAllowedtoReportError API210, then error reporting manager132will return TRUE to one of the calling managed runtimes and return FALSE to all of the other calling managed runtimes. If error reporting has not yet been initiated for the process, and only one managed runtime has called IsCurrentRuntimeAllowedtoReportError API210, then error reporting manager132will return TRUE to the calling managed runtime.

WaitForErrorReportingCompletionEvent API212may be invoked by a managed runtime to cause the managed runtime to suspend execution while waiting for the completion of error reporting for the process. In an embodiment, a managed runtime will invoke WaitForErrorReportingCompletionEvent API212in response to calling HasErrorReportingBeenTriggered API206and receiving TRUE from error reporting manager132or in response to calling IsCurrentRuntimeAllowedToReportError API210and receiving FALSE from error reporting manager132. The suspension of execution of the managed runtime ensures that the managed runtime cannot initiate shutdown of the process in which it is running prior to the completion of error reporting. Error reporting manager132will only respond to this call when it has determined that error reporting has been completed for the process.

SignalErrorReportingCompletionEvent API214may be invoked by a managed runtime that has been allowed to perform error reporting when it has completed the error reporting process. In an embodiment, error reporting manager132will respond to all pending calls to WaitForErrorReportingCompletionEvent API212only after SignalErrorReportingCompletionEvent API214is invoked by a managed runtime.

The foregoing APIs have been provided by way of example only. Persons skilled in the relevant art(s) will appreciate that other APIs may be provided to facilitate communication between managed runtimes1301-130Nand error reporting manager132. Furthermore, in other embodiment, means other than APIs may be used to enable communication between managed runtimes1301-130Nand error reporting manager132.

The manner in which error reporting manager132and managed runtimes1301-130Noperate and interact to coordinate error reporting among the managed runtimes will now be further described. In particular,FIGS. 3A and 3Bcollectively depict a flowchart300of a method by which error reporting manager132may operate to coordinate error reporting between managed runtimes1301-130Nconcurrently executing in process120. Although the method of flowchart300is described herein in reference to components of example system100, persons skilled in the relevant art(s) will readily appreciate that the method is not limited to that implementation and may be implemented by other systems or other components.

The steps of flowchart300are shown as being executed sequentially for ease of explanation only. It is to be understood that various steps shown in flowchart300may be executed concurrently. For example, in an embodiment in which user machine100comprises multiple processors or multiple processing cores, two or more steps of flowchart300may be concurrently executed by corresponding processors or processing cores.

As shown inFIG. 3A, the method of flowchart300begins at step302in which startup of error reporting manager132occurs. In an embodiment, startup of error reporting manager132occurs automatically when the first managed runtime to execute within process120is loaded by operating system110. After step302, control then flows to decision step304.

At decision step304, error reporting manager132determines if a managed runtime running within process120is attempting to register an error claiming callback. In one embodiment, a managed runtime running within process120attempts to register an error claiming callback by calling RegisterErrorClaimingCallback API202and including a pointer back to the managed runtime as an argument to the API call. However, this is only an example, and other methods may be used to attempt to register an error claiming callback with error reporting manager132.

If error reporting manager132determines at decision step304that no managed runtime running within process120is attempting to register an error claiming callback, then control flows to decision step308. However, if error reporting manager132determines at decision step304that a managed runtime running within process120is attempting to register an error claiming callback, then error reporting manager132will register the error claiming callback as shown at step306. In one embodiment, registering the error claiming callback comprises storing a pointer provided as an argument to RegisterErrorClaimingCallback API202in a table or other data structure managed by error reporting manager132. However, this is only an example, and other methods may be used to register an error claiming callback provided by a managed runtime. After step306, control then flows to decision step308.

At decision step308, error reporting manager132determines if a managed runtime running within process120is attempting to unregister a previously-registered error claiming callback. In one embodiment, a managed runtime running within process120attempts to unregister a previously-registered error claiming callback by calling UnregisterErrorClaimingCallback API204. However, this is only an example, and other methods may be used to attempt to unregister an error claiming callback that was previously registered with error reporting manager132.

If error reporting manager132determines at decision step308that no managed runtime running within process120is attempting to unregister a previously-registered error claiming callback, then control flows to decision step312. However, if error reporting manager132determines at decision step308that a managed runtime running within process120is attempting to unregister a previously-registered error claiming callback, then error reporting manager132will unregister the previously-registered error claiming callback as shown at step310. In one embodiment, unregistering the error claiming callback comprises removing a pointer to the managed runtime from a table or other data structure managed by error reporting manager132. However, this is only an example, and other methods may be used to unregister a previously-registered error claiming callback. After step310, control then flows to decision step312.

At decision step312, error reporting manager132determines if a managed runtime running within process120is attempting to determine whether or not error reporting has already been triggered for process120. In one embodiment, a managed runtime attempts to determine whether or not error reporting has already been triggered for process120by calling HasErrorReportingBeenTriggered API206. However, this is only an example, and other methods may be used to attempt to determine whether or not error reporting has already been triggered for process120.

If error reporting manager132determines at decision step312that no managed runtime running within process120is attempting to determine whether or not error reporting has already been triggered for process120, then control flows to decision step320. However, if error reporting manager132determines at decision step312that a managed runtime running within process120is attempting to determine whether or not error reporting has already been triggered for process120, then control flows to decision step314.

At decision step314, error reporting manager132determines whether or not error reporting has already been triggered for process120. If error reporting manager132determines that error reporting has already been triggered for process120, then error reporting manager132returns an indicator to that effect (e.g., “TRUE”) to the managed runtime attempting to retrieve such information as shown at step316. If error reporting manager132determines at decision step314that error reporting has not already been triggered for process120, then error reporting manager132returns an indicator to that effect (e.g., “FALSE”) to the managed runtime attempting to retrieve such information as shown at step318. After the performance of step316or step318, control then flows to decision step320.

At decision step320, error reporting manager132determines if a managed runtime running within process120is attempting to determine whether an error has been claimed by any other managed runtime running within process120. In one embodiment, a managed runtime attempts to determine whether an error has been claimed by any other managed runtime running within process120by calling IsErrorClaimed API208. However, this is only an example, and other methods may be used to attempt to determine whether an error has been claimed by any other managed runtime running within process120.

If error reporting manager132determines at decision step320that no managed runtime running within process120is attempting to determine whether an error has been claimed by any other managed runtime running within process120, then control flows to decision step330(shown inFIG. 3B). However, if error reporting manager132determines at decision step320that a managed runtime running within process120is attempting to determine whether an error has been claimed by any other managed runtime running within process120, then control flows to step322.

At step322, error reporting manager132iterates through all registered error claiming callbacks, invoking the callback corresponding to each registered managed runtime. In response to the callback, each registered managed runtime will either return an indicator that indicates that the managed runtime claims ownership of the error (e.g., “TRUE”) or an indicator that indicates that the managed runtime does not claim ownership of the error (e.g., “FALSE”). Control then flows to decision step324. Note that in an embodiment in which different steps of flowchart300may be performed concurrently, when step322is being performed by error reporting manager132, the performance of steps306and310dealing with registering and unregistering error claiming callbacks will be blocked. Similarly, when step306or310is being performed, the performance of step322will be blocked.

At decision step324, error reporting manager132determines whether any of the registered managed runtimes have returned an indicator that indicates that the error has been claimed (e.g., “TRUE”). If error reporting manager132determines that a registered managed runtime has returned an indicator that indicates that the error has been claimed, then error reporting manager132will return an indicator that indicates that the error has been claimed (e.g., “TRUE”) to the managed runtime seeking such information as shown at step326. However, if error reporting manager132determines that no registered managed runtime has returned an indicator that indicates that the error has been claimed, then error reporting manager132will return an indicator that indicates that the error has not been claimed (e.g., “FALSE”) to the managed runtime seeking such information as shown at step328. After the performance of step326or step328, control then flows to decision step330(shown inFIG. 3B).

At decision step330, error reporting manager132determines if a managed runtime running within process120is requesting permission to report an error. In an embodiment, a managed runtime requests permission to report an error by calling IsCurrentRuntimeAllowedToReportError API210. However, this is only an example, and other methods may be used to attempt to determine whether an error has been claimed by any other managed runtime running within process120.

If error reporting manager132determines at decision step330that no managed runtime running within process120is requesting permission to report an error, then control flows to decision step342. However, if error reporting manager132determines at decision step330that a managed runtime running within process120is requesting permission to report an error, then control flows to decision step332.

At decision step332, error reporting manager132determines whether or not error reporting has already been triggered for process120. If error reporting manager132determines that error reporting has already been triggered for process120, then error reporting manager132returns an indicator (e.g., “FALSE”) to the managed runtime requesting permission to report an error that indicates that the managed runtime is not permitted to report the error as shown at step334. If error reporting manager132determines at decision step332that error reporting has not already been triggered for process120, then control flows to decision step336, in which error reporting manager132determines if other managed runtimes running within process120are concurrently requesting permission to report an error. In one embodiment, error reporting manager132performs this function by determining whether multiple concurrent calls to IsCurrentRuntimeAllowedToReportError API210have been received. However, this is only an example, and error reporting manager132may use other methods for determining whether multiple managed runtimes running within process120are concurrently requesting permission to report an error.

If error reporting manager132determines during decision step336that there are no concurrent error reporting requests, then error reporting manager132returns an indicator (e.g., “TRUE”) to the managed runtime requesting permission to report an error that indicates that the managed runtime is permitted to report the error as shown at step338. However, if error reporting manager132determines during decision step336that there are concurrent error reporting requests from different managed runtimes, then error reporting manager132will return an indicator (e.g., “TRUE”) to only one of the managed runtimes requesting permission to report an error that indicates that the managed runtime is permitted to report the error and will return a different indicator (e.g., “FALSE”) to all the other managed runtime(s) requesting permission to report an error that indicates that the other managed runtime(s) are not permitted to report the error as shown at step340. This step ensures that even if different managed runtimes executing on different threads are requesting permission to report an error that only a single managed runtime will be permitted to report an error, and thus only a single error report will be produced for process120.

Various methods may be used by error reporting manager132to determine which one of the multiple managed runtimes requesting permission to report an error will receive permission to report. Such a determination may be made in a logical or arbitrary fashion. For example, in one embodiment, error reporting manager132grants permission to the requesting managed runtime that first notified error reporting manager132of an error.

After completion of step334, step338or step340, control then flows to decision step342.

At decision step342, error reporting manager132determines if a managed runtime running within process120is requesting to wait for the completion of error reporting for process120. In an embodiment, a managed runtime requests to wait for the completion of error reporting by calling WaitForErrorReportingCompletionEvent API212. However, this is only an example, and other methods may be used by a managed runtime to request to wait for the completion of error reporting. A managed runtime may request to wait for completion of error reporting in response to being notified by error reporting manager132that error reporting has already been triggered for process120during step316or in response to being denied permission to perform error reporting during steps334or340as previously described.

If error reporting manager132determines at decision step342that no managed runtime running within process120is requesting to wait for the completion of error reporting for process120, then control flows to decision step348. However, if error reporting manager132determines at decision step342that a managed runtime running within process120is requesting to wait for the completion of error reporting for process120, then control flows to decision step344.

At decision step344, error reporting manger132determines if a managed runtime running within process120has notified error reporting manager132that it has completed error reporting for process120. In one embodiment, a managed runtime running within process120notifies error reporting manager132that it has completed error reporting for process120by calling SignalErrorReportingCompletionEvent API214. However, this is only an example and other methods may be used by a managed runtime to notify error reporting manager132that it has completed error reporting for process120.

If error reporting manager132determines during decision step344that no managed runtime running within process120has notified error reporting manager132that it has completed error reporting for process120, then error reporting manager132will not respond to the call from the managed runtime requesting to wait for the completion of error reporting and will continue to check if another managed runtime has reported the completion of error reporting. The failure to respond to the call from the requesting managed runtime has the effect of suspending the execution of the requesting managed runtime, thereby ensuring that the requesting managed runtime cannot initiate termination of process120prior to the completion of error reporting. It is noted that this is only one example of a mechanism for suspending the execution of the requesting managed runtime and that other mechanisms may be used.

However, if error reporting manager132determines during decision step344that a managed runtime running within process120has notified error reporting manager132that it has completed error reporting for process120, then error reporting manager132will respond to the call from the managed runtime requesting to wait for the completion of error reporting as shown at step346. This will have the effect of causing the execution of the requesting managed runtime to resume, thereby allowing the requesting managed runtime to initialize a managed runtime termination procedure. It is noted that this is only one example of a mechanism for causing the execution of the requesting managed runtime to resume and that other mechanisms may be used. After step346, control flows to decision step348.

At decision348, error reporting manager132determines if process120is about to terminate. If error reporting manager132determines that process120is not about to terminate, then control flows back to decision step304(shown inFIG. 3A). However, if error reporting manager132determines that process120is about to terminate, then error reporting manager132will shut down as shown at step350.

The manner in which error reporting manager132and managed runtimes1301-130Noperate and interact to coordinate error reporting among the managed runtimes will now be further described in reference to flowchart400ofFIG. 4. In particular,FIG. 4depicts a flowchart400of steps taken by a managed runtime, such as any of managed runtimes1301-130N, to facilitate coordinated error reporting. The managed runtime discussed inFIG. 4will be denoted managed runtime130, although it may represent any one of managed runtimes1301-130N. Although the method of flowchart400is described herein in reference to components of example system100, persons skilled in the relevant art(s) will readily appreciate that the method is not limited to that implementation and may be implemented by other systems or other components.

As shown inFIG. 4, the method of flowchart400begins at step402in which startup of managed runtime130occurs within process120. In an embodiment, operating system110is prompted to initiate managed runtime130responsive to the execution of a managed application that requires managed runtime130to operate. After step402, control then flows to step404.

Note that, in one embodiment, error reporting manager132is initialized by the first instance of managed runtime130that is loaded within process120during startup of that managed runtime. This occurs before any managed runtime can interact with error reporting manager132.

At step404, responsive to the startup of managed runtime130, managed runtime130registers an error claiming callback with error reporting manager132. In one embodiment, managed runtime130registers the error claiming callback by calling RegisterErrorClaimingCallback API202and including a pointer back to managed runtime130as an argument to the API call. However, this is only an example, and other methods may be used by managed runtime130to register an error claiming callback with error reporting manager132. After step404, control then flows to decision step406.

At decision step406, managed runtime130determines whether an error has occurred. As will be appreciated by persons skilled in the relevant art(s), various mechanisms exist by which managed runtime130may encounter an error. For example, managed runtime130may own the base of a thread on which an unhandled exception is encountered and may be notified of the unhandled exception by exception management logic running on user machine100that has worked its way up the thread searching for an exception handler. Alternatively, operating system110may be notified of an unhandled exception and report the unhandled exception to a set of registered modules that includes managed runtime130. These are only examples, and there may be other mechanisms or means by which managed runtime130may determine that an error has occurred. Furthermore, it is noted that the term “error” as used herein is not limited to unhandled exceptions, but is intended to broadly represent any condition that would require an unexpected or abnormal termination of a managed runtime or application.

If managed runtime130determines at decision step406that no error has occurred, then control flows to decision step408. At decision step408, managed runtime130determines if managed runtime130is about to terminate. Such termination may occur, for example, in response to the orderly shutdown of a managed application that relies on managed runtime130for execution or in response to an error that causes an unexpected or abnormal termination of managed runtime130and/or any managed application that managed runtime130was invoked to support.

If managed runtime130is not about to terminate, then control returns to decision step406. However, if managed runtime130is about to terminate then control flows to step410, in which managed runtime130unregisters its previously-registered error claiming callback with error reporting manager132. In one embodiment, managed runtime130unregisters its previously-registered error claiming callback with error reporting manager132by calling UnregisterErrorClaimingCallback API204. However, this is only an example, and other methods may be used by managed runtime130to unregister its previously-registered error claiming callback with error reporting manager132. After step410, control then flows to step412, in which managed runtime130is shutdown.

Note that, in one embodiment, error reporting manager132will be shut down after the last instance of managed runtime130unregisters its error claiming callback.

If managed runtime130determines during decision step406that an error has occurred, then control flows to decision step414. During decision step414, managed runtime130communicates with error reporting manager132to determine if error reporting has already been initiated for process120. Such error reporting may have been initiated, for example, by a different managed runtime executing on a different thread of execution. In one embodiment, managed runtime130communicates with error reporting manager132to determine if error reporting has already been initiated for process120by calling HasErrorReportingBeenTriggered API206and then, in response to calling the API, receiving an indicator from error reporting manager132that indicates either that error reporting has already been initiated (e.g., “TRUE”) or that error reporting has not already been initiated (e.g., “FALSE”). However, this is only an example, and other methods may be used by managed runtime130to communicate with error reporting manager132to determine whether or not error reporting has already been initiated for process120.

If managed runtime130determines during decision step414that error reporting has already been initiated for process120, then control flows to step416. During step416, managed runtime130sends a request to error reporting manager132to wait for the completion of error reporting for process120. In response to sending the request, error reporting manager132causes the execution of managed runtime130to be suspended until another managed runtime has notified error reporting manager132that error reporting is complete. This step ensures that managed runtime130cannot initiate termination of process120until error reporting has completed. In an embodiment, managed runtime130sends a request to error reporting manager132to wait for the completion of error reporting for process120by calling WaitForErrorReportingCompletionEvent API212and error reporting manager132causes the execution of managed runtime130to be suspended by not returning a response to the API call until another managed runtime has notified error reporting manager132that error reporting is complete (e.g. via a call to SignalErrorReportingCompletionEvent API214). However, this is only an example, and other methods may be used by managed runtime130to send a request to error reporting manager132to wait for the completion of error reporting and by error reporting manager132to cause the execution of managed runtime130to be suspended until error reporting is complete.

After step416, control flows to step410, in which managed runtime130unregisters its previously-registered error claiming callback with error reporting manager132, and then to step412, in which managed runtime130is shutdown.

If managed runtime130determines during decision step414that error reporting has not already been initiated for process120, then control flows to decision step418. During decision step418, managed runtime130determines whether it has caused the error. If managed runtime130determines during decision step418that it has caused the error, then control flows to step420.

During step420, managed runtime130sends a request for permission to report the error to error reporting manager132. In one embodiment, managed runtime130sends a request for permission to report the error to error reporting manager132by calling IsCurrentRuntimeAllowedToReportError API210. However, this is only an example, and other methods may be used by managed runtime130to send a request for permission to report the error to error reporting manager132. After step420, control flows to decision step422.

During decision step422, managed runtime130determines if the request for permission sent to error reporting manager132during step420has been granted. In one embodiment, managed runtime130determines that the request for permission has been granted if error reporting manager132returns an indicator indicating that permission has been granted (e.g., “TRUE”) in response to calling IsCurrentRuntimeAllowedToReportError API210and determines that the request for permission has been denied if error reporting manager132returns an indicator indicating that permission has been denied (e.g., “FALSE) in response to calling IsCurrentRuntimeAllowedtoReportError API210. However this is only an example and managed runtime130may use other methods to determine if the request for permission sent to error reporting manager132during step420has been granted.

In one embodiment, error reporting manager132will deny permission if error reporting has already been triggered for process120. In further accordance with such an embodiment, if error reporting has not already been triggered for process120, but two or more managed runtimes are concurrently requesting permission to report an error, then error reporting manager132will grant permission to only one of the calling managed runtimes and deny permission to all of the other calling managed runtimes. In still further accordance with such an embodiment, if error reporting has not already been triggered for process120, but only one managed runtime is requesting permission to report an error, then error reporting manager132will grant permission to the calling managed runtime. This approach to granting/denying permission ensures that at most one error report will be generated for process120.

If managed runtime130determines during decision step422that permission has not been granted to report the error, then control flows to step416, in which managed runtime130waits for error reporting for process120to complete, then to step410, in which managed runtime130unregisters its previously-registered error claiming callback with error reporting manager132, and finally to step412, in which managed runtime130is shutdown.

If managed runtime130determines during decision step422that permission has been granted to report the error then control flows to steep424in which managed runtime130reports the error. Reporting the error may comprise, for example, providing information about the error to error reporting service122in operating system122. After step424is complete, managed runtime130signals error reporting manager132that error reporting is complete as shown at step426. This enables error reporting manager132to cause any other managed runtimes within process120that are in a state of suspended execution pending the completion of error reporting for process120to resume execution. In one embodiment, managed runtime130signals error reporting manager132that error reporting is complete by calling SignalErrorReportingCompletionEvent API214. However, this is only an example, and other methods may be used by managed runtime130to signal error reporting manager132that error reporting is complete.

After step426, control flows to step410, in which managed runtime130unregisters its previously-registered error claiming callback with error reporting manager132, and then to step412, in which managed runtime130is shutdown.

Returning now to decision step418, if managed runtime130determines during that step that the error was not caused by itself, then control flows to decision step428. During decision step428, managed runtime130communicates with error reporting manager132to determine if any other managed runtime running within process120has claimed ownership of the error. In one embodiment, managed runtime130communicates with error reporting manager132to determine if any other managed runtime running with process120has claimed ownership of the error by calling IsErrorClaimed API208. In response to the calling of this API by managed runtime130, error reporting manager132will either return an indicator that indicates that another managed runtime has claimed ownership of the error (e.g., “TRUE”) or an indicator that indicates that no other managed runtime has claimed ownership of the error (“FALSE”). However, this is only an example, and other methods may be used by managed runtime130to communicate with error reporting manager132to determine if any other managed runtime running within process120has claimed ownership of the error.

If managed runtime130determines during decision step428that the error has been claimed by another managed runtime running within process120, then managed runtime130will ignore the error as shown at step430, after which control returns to decision step406. This allows error dispatching logic within operating system110to subsequently invoke the appropriate error-claiming managed runtime, which will then perform at least a portion of the protocol shown in flowchart400for facilitating coordinated error reporting. In an alternative embodiment, rather than ignoring the error in step430, managed runtime130may directly invoke the appropriate error-claimed managed runtime, which will then perform at least a portion of the protocol shown in flowchart400for facilitating coordinated error reporting and then go to step410once error reporting is complete.

However, if managed runtime130determines during decision step428that the error has not been claimed by another managed runtime running within process120, then managed runtime130will request permission to report the error as shown at step432. Step432may be performed in a like fashion to step420as previously described.

After step432, control then flows to decision step422. As previously described, during decision step422, managed runtime130determines if the request for permission sent to error reporting manager132has been granted.

As was previously described, if managed runtime130determines during decision step422that permission has not been granted to report the error, then control flows to step416, in which managed runtime130waits for error reporting for process120to complete, then to step410, in which managed runtime130unregisters its previously-registered error claiming callback with error reporting manager132, and finally to step412, in which managed runtime130is shutdown.

As also was previously described, if managed runtime130determines during decision step422that permission has been granted to report the error then control flows to step424in which managed runtime130reports the error. After step424is complete, managed runtime130signals error reporting manager132that error reporting is complete at step426.

After step426, control flows to step410, in which managed runtime130unregisters its previously-registered error claiming callback with error reporting manager132, and then to step412, in which managed runtime130is shutdown.

Execution of the foregoing method of flowchart300as described above in reference toFIGS. 3A and 3Bby error reporting manager132and the foregoing method of flowchart400as described above in reference toFIG. 4by each managed runtime concurrently executing in process120will advantageously ensure that if process120crashes, at most one error report will be generated by the managed runtime that caused the failure or the first managed runtime that encounters an error that does not come from any of managed runtimes in the process. Execution of the foregoing methods by error reporting manager132and each managed runtime concurrently executing in process120will also advantageously ensure that the managed runtime that caused the failure will claim the error, and will generate the error reporting information if there is no other concurrent and different error being processed in the process. If there are two or more concurrent and different errors being processed in the process, the first managed runtime that is ready to report an error will report an error.

III. Example Computer System Implementation

FIG. 5depicts an example computer500that may be used to implement various aspects of the embodiments. For example, user machine100shown inFIG. 1may be implemented using computer500, including one or more features of computer system500and/or alternative features. Computer500may represent a general-purpose computing device in the form of a conventional personal computer, a mobile computer, or a workstation, for example, or computer500may be a special purpose computing device. The description of computer500provided herein is provided for purposes of illustration, and is not intended to be limiting. Embodiments may be implemented in further types of computer systems, as would be known to persons skilled in the relevant art(s).

As shown inFIG. 5, computer500includes a processing unit502, a system memory504, and a bus506that couples various system components including system memory504to processing unit502. Processing unit502may comprise one or more processors or processing cores. Bus506represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. System memory504includes read only memory (ROM)508and random access memory (RAM)510. A basic input/output system512(BIOS) is stored in ROM508.

Computer500also has one or more of the following drives: a hard disk drive514for reading from and writing to a hard disk, a magnetic disk drive516for reading from or writing to a removable magnetic disk518, and an optical disk drive520for reading from or writing to a removable optical disk522such as a CD ROM, DVD ROM, or other optical media. Hard disk drive514, magnetic disk drive516, and optical disk drive520are connected to bus506by a hard disk drive interface524, a magnetic disk drive interface526, and an optical drive interface528, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computer. Although a hard disk, a removable magnetic disk and a removable optical disk are described, other types of computer-readable media can be used to store data, such as flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROM), and the like.

A number of program modules may be stored locally on the hard disk, magnetic disk, optical disk, ROM, RAM or FLASH, or remotely on network storage in a LAN or WAN such as the Internet. These programs include an operating system530, one or more application programs532, other program modules534, and program data536. Operating system530may represent operating system110shown inFIG. 1and thus may include error reporting service122. Application programs532or program modules534may include, for example, logic representative of managed runtimes1301-130N, managed applications1401-140N, and/or error reporting manager132. Thus, when executed, these application programs532or program modules534can perform methods such as those described above in reference to flowchart300ofFIGS. 3A and 3Bor flowchart400ofFIG. 4.

A user may enter commands and information into the computer500through input devices such as keyboard538and pointing device540. Other input devices (not shown) may include a microphone, joystick, game controller, scanner, or the like. These and other input devices are often connected to the processing unit502through a serial port interface542that is coupled to bus506, but may be connected by other interfaces, such as a parallel port, game port, or a universal serial bus (USB).

A monitor544or other type of display device is also connected to bus506via an interface, such as a video adapter546. In addition to the monitor, computer500may include other peripheral output devices (not shown) such as speakers and printers.

Computer500is connected to a network548(e.g., a local area network or wide area network such as the Internet) through a network interface or adapter550, a modem552, or other means for establishing communications over the network. Modem552, which may be internal or external, is connected to bus506via serial port interface542.

As used herein, the terms “computer program medium” and “computer-readable medium” are used to generally refer to media such as the hard disk associated with hard disk drive514, removable magnetic disk518, removable optical disk522, as well as other media such as flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROM), and the like.

As noted above, computer programs and modules (including application programs532and other program modules534) may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. Such computer programs may also be received via network interface550or serial port interface542. Such computer programs, when executed or loaded by an application, enable computer500to implement features of embodiments discussed herein. Accordingly, such computer programs represent controllers of the computer500.