restart manager

Microsoft’s move to make Windows 10 a ‘software as a service’ means that updates are going to be even more numerous. We all know that too many updates require reboots, so reboots (or “restarts”) will also become more numerous due to the addition of feature updates since the number of updates is only growing. That’s not good news – restarts are a pain for both administrators and end-users alike. Microsoft surely knows that, so you would think that in this new world they would work to reduce the pain of restarts. Have you heard anything along those lines in all the discussions of Windows 10? Sadly, I haven’t.

With a little digging, however, you will find that Microsoft has actually been conscious of the pain of reboots for a long time, having invested very aggressively over the years to mitigate them. Our “Improve Security by Optimizing Your Reboot Strategy” whitepaper goes into details about those efforts, but today we’ll focus on Restart Manager.

As early as 2005, Microsoft described Restart Manager as:

“If a part of an application, or the operating system itself, needs to updated, the installer will call the Restart Manager, which looks to see if it can clear that part of the system so that it can be updated. If it can do that, it does, and that happens without a reboot.”

They said this feature would be used by Windows Update, WSUS, ConfigMgr, and similar services to greatly reduce the need for reboots. Wonderful!

Resources of various types, such as files and registry entries, are used by software that runs on your computer. When an update or installation occurs, it has to change a lot of resources. If any of those resources are shared, the other software sharing the resources could be affected. Changing a shared resource while it is in use could cause unpredictable results and is often not possible. Restarting the computer allows the resources to be updated or installed before any software starts using them, overcoming the sharing problem. Restart Manager tries to avoid the computer restart by only restarting the software that is sharing the resources.

This all sounds great, but today’s reality is that it is still very common for installations or upgrades to require restarts. You might think this means Restart Manager was deprecated, but Restart Manager events can be seen in the Windows 10 Application event logs. Looking at them, you’ll see that typically Restart Manager finds that an application “cannot be restarted – Application SID does not match Conductor SID”, cryptically meaning that the security context of the update program is different from the security context of an application using at least one shared resource. That symptom could be an indication of a malicious restart by some kind of malware, so Restart Manager is prevented from restarting the application. This issue might not occur for every application that is sharing resources relevant to an update, but if an update requires updating resources shared with multiple applications, the probability greatly increases that at least one application cannot be restarted. Therefore Restart Manager is not successful and a computer restart (reboot) is needed.

So Restart Manager is a great idea to reduce reboots but to be safe Windows frequently can’t use it. That’s disappointing, but even in the world of software, sometimes reality trumps theory. Learn more in our whitepaper.

Paul Thomsen
Paul Thomsen has been a Product Manager at 1E since August 2014. Current responsibilities include NightWatchman product management and special projects. That followed two and a half years at the company as a Solutions Engineer working directly with many organizations of all sizes. Prior to that Paul worked at Microsoft for 12 years, eight of which were as a senior ConfigMgr Engineer for the teams serving Microsoft IT (300,000 clients) and others. That included “dogfooding” many versions of ConfigMgr. For his first few years at Microsoft, Paul was a technical writer on the ConfigMgr (SCCM) product team. His career has been primarily IT-focused but has included several years as an application developer. Paul has been active in the ConfigMgr community for over 15 years, including presenting at many conferences, blogging at, writing the SMS column for BackOffice magazine for three years, and contributing to several SMS/ConfigMgr books.