Understanding Application Recovery and Restart
This article provides an overview of Application Recovery and Restart (ARR). In the companion topic, Developing with Application Recovery and Restart, the concepts discussed here are illustrated by code examples that shows the two features working together. The source code for a sample application that uses ARR can be found in the Application Recovery and Restart Samples topic.
Application Recovery and Restart
When an application experiences an unrecoverable error such as an unhandled exception, the Windows Error Reporting (WER) infrastructure communicates with the application user through a dialogue box as it performs a series of actions based on the system configuration and whether the application has enabled recovery or restart. WER actions can include sending an error report, closing the application, or closing and then restarting the application. If the server running the application is unattended, the application close or restart happens by default.
The Application Recovery and Restart (ARR) technologies enable developers to customize an application's behavior when WER terminates the application due to an unrecoverable error. The Application Recovery feature allows an application to perform data recovery and cleanup operations such as capturing application state and releasing resources before termination. The Application Restart feature allows developers to specify that WER should automatically restart an application that it has terminated.
Application Recovery and Application Restart are independent features that can be combined to provide an improved end-user experience after an application crash. When a fatal error occurs, an application can first use Application Recovery to persist data and application state information before shutting down. Then, using Application Restart, the application can restart automatically and restore itself to its previous state.
ARR technologies are used in scenarios where WER is responsible for terminating the application. Applications can also be terminated due to software installation. Windows Installer 4.0 uses Restart Manager, and developers can use it when developing custom installers. For information on these related technologies, see Using Windows Installer with Restart Manager.
For situations where WER will close an application, the application developer can specify custom behavior to execute. To use the Application Recovery feature, an application:
Registers the application for Application Recovery.
Implements a recovery function to be called by WER before application termination.
Communicates the status of a recovery in progress to WER.
When an application registers for Application Recovery, it supplies the following information to WER:
A callback to the function that performs the application's recovery operations
An optional application-specific data structure to pass to the recovery function
A timing interval used during recovery
It is important to note that by the time an application's recovery function is called, the application has already experienced a fatal error. Therefore, both the application and the system that it is running on are in an unknown state. Developers should not assume that their applications will be able to successfully perform recovery operations, especially those that need to acquire system resources such as database connections. To ensure some level of recovery after a crash, an application should persist user data and state information periodically while the application is working as expected, and not rely solely on being able to write files or update data stores during recovery. Applications can and should use the recovery function to attempt to free resources and shut down gracefully.
The recovery function is where the application performs actions such as recovering information that would otherwise be lost after the application terminates. Before forcing an application to terminate, WER will first call the recovery function specified when the application registered. WER will pass to the recovery function the optional data structure specified during registration.
During recovery, the application must periodically communicate with WER to indicate that the recovery operation is ongoing. The ARR APIs include a function that acts as a keep-alive, which the recovery function must call within a set time interval. The application specifies the time interval as part of its registration information. A time interval of 5 seconds is appropriate for most applications. If an application registers a recovery function and specifies a 5-second timing interval, the recovery function is responsible for calling the keep-alive function at least once every 5 seconds until the recovery function is finished. WER requires the keep-alive calls so that it can detect when the recovery function is hung or in a corrupted state. Failure to call the keep-alive function within the specified time interval can result in the application being terminated while the recovery function is still executing.
WER communicates its actions to the application user through a dialog window. Application Recovery is one of the actions that can be canceled by the user via the Cancel button in the WER dialog window. The information that the user clicked the Cancel button is sent back to the application each time it calls the keep-alive function. WER does not enforce recovery cancellation; it will not terminate the application while the keep-alive function is being called as expected. However, applications should adhere to the user's request.
When the recovery function is finished, it signals its completion to WER by calling a function. The application is then terminated. If the recovery function throws an unhandled exception, WER will terminate the application.
Application developers can specify that WER should restart a terminated application.
WER will not restart an application if it executed for less than 60 seconds before being terminated. This behavior prevents applications from repeatedly restarting if they crash at or near startup time.
To use the Application Restart feature, the application registers for automatic restart. When registering, the application can supply optional command line arguments to be passed to the application when it restarts. Developers can make use of the command-line arguments to determine whether an application is starting up normally or is being restarted by WER after being forced to terminate. In the case where the application is restarting, the application can attempt to restore its previous state if that information is available.
As part of restart registration, an application can also specify one or more conditions under which the application should not be restarted. The available conditions are:
The application crashed due to an unhandled exception.
The application was not responding.
The installation of a software update (patch) required the application to terminate.
The installation of a software update required the server to reboot.
An application that is using both Application Recovery and Application Restart cannot register for restart in its recovery code.