Windows
Windows
Windows PCs require a restart to apply each month’s security updates. Today we’re offering tips and best practices that can help you make sure your applications seamlessly resume after a restart and keep your app users happy. Some users manage Windows updates (and restarts) for themselves. Others prefer that their PCs automatically restart when not in use. In either case, users typically prefer to find their applications exactly as they left them after an update. Their flow on Windows is more productive and fun when apps restore their state, position and pending operations following an update. What does this mean for you as an application developer? If your app is documentation-focused, you might want to help people remember where in the document they were editing most recently. If your app helps people modify images, consider saving their “undo” stack and/or creating a temporary copy of their workspace. For game developers, it might be helpful to implement a quick “save” and ask players where they would like to resume. Ultimately, your apps can offer seamless continuity following a restart – for updates or otherwise – by following a few best practices:
// Register for restart with the current value of app text box
RegisterApplicationRestart(counterTextBlock().Text().c_str(), RESTART_NO_PATCH | RESTART_NO_REBOOT);
// Update registration before crash with the new value of the app counter text box
RegisterApplicationRecoveryCallback(APPLICATION_RECOVERY_CALLBACK([](PVOID recoveryData){
BOOL canceled;
if (SUCCEEDED(ApplicationRecoveryInProgress(&canceled)) && !canceled)
{
const auto counter = static_cast<uint32_t*>(recoveryData);
RegisterApplicationRestart(to_hstring(*counter).c_str(), RESTART_NO_PATCH | RESTART_NO_REBOOT);
}
ApplicationRecoveryFinished(true);
return (DWORD)0;
}), &_counter, RECOVERY_DEFAULT_PING_INTERVAL, 0);
// Best effort to register for crash and hang restart.
RegisterApplicationRestart(_counter.ToString(), REGISTER_APPLICATION_RESTART_FLAGS.RESTART_NO_PATCH | REGISTER_APPLICATION_RESTART_FLAGS.RESTART_NO_REBOOT);
// Best effort to register recovery callback to update restart arguments with the latest seconds counter value.
RegisterApplicationRecoveryCallback(new APPLICATION_RECOVERY_CALLBACK(p =>
{
ApplicationRecoveryInProgress(out BOOL canceled);
if (!canceled)
{
RegisterApplicationRestart(_counter.ToString(),
REGISTER_APPLICATION_RESTART_FLAGS.RESTART_NO_PATCH |
REGISTER_APPLICATION_RESTART_FLAGS.RESTART_NO_REBOOT);
}
ApplicationRecoveryFinished(true);
return 0;
}), null, 5000, 0);
Apps with critical workloads can use to keep the system running and prevent a restart, but this isn’t permanent. Both users and administrators need devices to stay secure and a system will eventually be forced to restart after an update. Further, keeping the system powered on can drain battery or use excess power. We encourage you to read more about for system services and long-running critical applications.
- Save the user’s state.
- Remember how their previous views were positioned.
- Relaunch the app following the update.
Universal Windows Platform (UWP) apps
Universal Windows Platform (UWP) provides to applications. While a UWP app doesn’t need anything special to be restarted and resumed after a system update, it is recommended to periodically.Win32 apps
If you are developing a Windows desktop app, you can use the Application Recovery and Restart (ARR) APIs to register your app for restart. Specifically, helps applications cleanly close upon system restart and relaunch after restart with pre-defined arguments. Whether you are building Win32 apps or you’re using Windows app SDK, you can find . In addition to registering apps for restart, you should consider how an app can best resume its previous workload and recover the previous state. Common strategies include saving often to disk and providing context to resume state in the arguments used when registering via ARR API. Here is a code example:// Register for restart with the current value of app text box
RegisterApplicationRestart(counterTextBlock().Text().c_str(), RESTART_NO_PATCH | RESTART_NO_REBOOT);
// Update registration before crash with the new value of the app counter text box
RegisterApplicationRecoveryCallback(APPLICATION_RECOVERY_CALLBACK([](PVOID recoveryData){
BOOL canceled;
if (SUCCEEDED(ApplicationRecoveryInProgress(&canceled)) && !canceled)
{
const auto counter = static_cast<uint32_t*>(recoveryData);
RegisterApplicationRestart(to_hstring(*counter).c_str(), RESTART_NO_PATCH | RESTART_NO_REBOOT);
}
ApplicationRecoveryFinished(true);
return (DWORD)0;
}), &_counter, RECOVERY_DEFAULT_PING_INTERVAL, 0);
.NET apps
Similar to Win32 apps, .NET apps can for restart by using the ARR APIs. The only difference is using to wrap the native API calls. You can find .NET sample code using ARR APIs .// Best effort to register for crash and hang restart.
RegisterApplicationRestart(_counter.ToString(), REGISTER_APPLICATION_RESTART_FLAGS.RESTART_NO_PATCH | REGISTER_APPLICATION_RESTART_FLAGS.RESTART_NO_REBOOT);
// Best effort to register recovery callback to update restart arguments with the latest seconds counter value.
RegisterApplicationRecoveryCallback(new APPLICATION_RECOVERY_CALLBACK(p =>
{
ApplicationRecoveryInProgress(out BOOL canceled);
if (!canceled)
{
RegisterApplicationRestart(_counter.ToString(),
REGISTER_APPLICATION_RESTART_FLAGS.RESTART_NO_PATCH |
REGISTER_APPLICATION_RESTART_FLAGS.RESTART_NO_REBOOT);
}
ApplicationRecoveryFinished(true);
return 0;
}), null, 5000, 0);
Apps with critical workloads can use to keep the system running and prevent a restart, but this isn’t permanent. Both users and administrators need devices to stay secure and a system will eventually be forced to restart after an update. Further, keeping the system powered on can drain battery or use excess power. We encourage you to read more about for system services and long-running critical applications.