Improve Application Quality with Microsoft Foundation Class (MFC) Restart and Recovery

Introduction

.NET Developers and users have grown accustomed to applications like Microsoft Word that save temporary copies of a document while it is being created and edited, and offer the user the option of recovering these documents in the event of a crash, hang or system restart caused by patch installation. Windows Vista provides a standard mechanism for providing this support, and a previous article entitled, Build Build Resilient Applications with Windows Recovery and Restart Applications has covered this functionality from a Windows SDK perspective. The good news is that the release of MFC 10 automates most of the interaction with the Windows Application Restart and Recovery (ARR) APIs, and for the most part, makes taking advantage of these features a snap for .NET Developers. It's the simple matter of ticking a few boxes when the AppWizard is first run or adding a line of code in the case of existing MFC applications upgraded to MFC 10.

The simplest part of the Application Restart and Recovery features is the ability for a crashed application to be restarted. For applications that have registered with the ARR functions, Windows will restart an application that crashes if it has successfully run for at least sixty seconds, and for applications that hang, Windows will present a third option of allowing the application to be restarted in addition to the standard two options of closing the program or waiting for it to respond, as shown in Figure 1.

Taking advantage of the basic restart functionality is available for all types of MFC applications, and can be activated by ticking the AppWizard checkbox shown in Figure 2.

Figure 2. Using Application Restart in a MFC Application

Checking this box adds the code below to the CWinApp- derived MFC class. The m_dwRestartManagerSupportFlags member variable is declared as protected in CWinApp, and when it is set in the constructor, code inside CWinApp will register the application for restart. Retro-fitting restart support to an existing MFC application is a simple matter of adding this code into the CWinApp-derived class constructor. The call to the Windows SDK function RegisterApplicationRestart (which instructs Windows to re-start a crashed application) is made from CWinApp::InitInstance, so it is critical that the value of m_dwRestartManagerSupportFlags is set early within an MFC application's startup.

  // support Restart Manager
  m_dwRestartManagerSupportFlags = AFX_RESTART_MANAGER_SUPPORT_RESTART;

MFC applications that take advantage of Document-View architecture support can take advantage of more extensive restart and recovery support with automated documented saving and recovery available. MDI and SDI MFC Applications will have two further ARR options available when the MFC AppWizard is run, as shown in Figure 3. The first additional option (Reopen previously open documents) simply adds support for prompting the user to re-open documents that have been auto-saved prior to an application crash or hang. The second option (Support application recovery) is dependent on having the first option selected, and leverages MFC to play an active role in safe-guarding the contents of a document by auto-saving temporary copies at regular intervals.

Figure 3. Full Recovery and Restart MFC Options

Selecting the Reopen previously open documents AppWizard option will set the m_dwRestartManagerSupportFlags member variable to AFX_RESTART_MANAGER_SUPPORT_RESTART_ASPECTS, which is a bitwise combination of:
AFX_RESTART_MANAGER_SUPPORT_RESTART |
AFX_RESTART_MANAGER_AUTOSAVE_AT_RESTART |
AFX_RESTART_MANAGER_REOPEN_PREVIOUS_FILES |
AFX_RESTART_MANAGER_RESTORE_AUTOSAVED_FILES. The final option of Support application recovery will set the flag to AFX_RESTART_MANAGER_SUPPORT_ALL_ASPECTS. All the restart and recovery flags (along with explanations of their meaning) are defined in afxwin.h. MFC introduces a new class called CDataRecoveryHandler to handle the various operations related to automatically saving and recovery documents to supports ARR. CWinApp holds a protected member variable which points to a CDataRecoveryHandler instance, and by default this will be lazily initialized to a new CDataRecoveryHandler object as required. CDataRecoveryHandler, declared in afxdatarecovery.h, is designed to allow sub-classing to customize the behavior of application recovery and restart, with all the public methods declared as virtual, and factored in a way that there is a public method exposed and called by CWinApp for each logical operation. This allows a developer to define a CDataRecoveryHandler-derived class and override the one member function that implements the behavior that requires customization. All calls within the MFC codebase the interact with CDataRecoveryHandler retrieve a pointer via a call to the virtual CWinApp::GetDataRecoveryHandler, allowing a MFC application to override this member function and provide a derived CDataRecoveryHandler containing customizations. A future article will cover a fuller range of the customizations that are possible and how to take advantage of them.

For a lot of MFC applications, the default behavior of CDataRecoveryHandler will be sufficient. Selecting the Reopen previously open documents option when AppWizard runs adds a fairly minimal improvement to the restart experience--the previously--saved documents that are open when the application crashes or hangs are restored when the application restarts are re-opened. CDataRecoveryHandler stores a list of open documents in the registry, and creates a unique registry key in the form of a GUID string for each application instance that crashes to track the particular documents open in that process. The GUID string is also passed to the ARR function RegisterApplicationRestart, so when Windows restarts the crashed application, this GUID string is passed in to the new process by Windows as a command line argument, and the correct documents can be loaded.

The fullest level of application recovery support offered by MFC is the ability to save temporary copies of documents that are currently open and offering the user the option of recovering these documents upon application restart. The frequency of auto-save is controlled by the value returned by the virtual GetAutosaveInterval function of CDataRecoveryHandler. The value returned by this function, which is in number of milliseconds, is currently defaulted to five minutes (300000 milliseconds), but this can be customized in an MFC application with the following code:

  //inside CWinApp-derived class
  
  //auto-save every minute
  GetDataRecoveryHandler()->SetAutosaveInterval(60*1000);

Each time an auto-save interval expires, a timer will fire and temporary copies of open documents will be saved. This includes documents that have been created for the first time but have not been explicitly saved before, as long as the SetModifiedFlag has been called at the document-level to let MFC know that the document contains modifications worth saving. The default recovery dialog provided by MFC is shown in Figure 4, and if the end-user elects to recover the saved documents, the document title is annotated to indicate that it has been recovered, as shown in Figure 5.

Figure 4. MFC Application File Recovery

Figure 5. Recovered Documents

The introduction of ARR inside MFC is one of the most elegant examples of framework extensions in the long history of Visual C++. Not only is ARR-support simple and seamless to add to new applications, existing applications can also take advantage of the new features with the addition of a single line of code. The recovery mechanism is simple to customize, and by dividing the functionality into well- defined virtual functions, customization can be achieved without the need to re-implement large sections of framework code.