In defense of Windows Vista’s Restart Manager.

In the last week there were three RSS feeds I follow that mentioned the new Restart Manager service in Windows Vista. First, Mary Jo Foley says, "The technology is designed to update parts of the operating system or applications without having to reboot the entire machine." That sentence is slightly misleading because the Restart Manager isn't actually responsible for actually updating anything but we'll get to what the Restart Manager is really all about in a minute.

[read more]

Comments (17)

  1. TIago Magalhães says:

    Correct if I’m wrong, it’s been a while since I dealth with any flavour of *nix.

    When you drop to one of the lower run levels all your user mode applications have to be stoped right?

    If that’s the case what does that happy place really get you?

    The comfort that knowing the "reboot cycle" didn’t have to touch the BIOS?

  2. Tiago Magalhães says:

    Ok, I was wrong runlevels 2 and 3 are not as low level as I thought.

  3. jws says:

    To be fair, as far as unix is concerned, the OS is the kernel and libc. In some ways, upgrading apps can be worse on linux, especially if the update requires recompiling a pile of dependencies. Unix wins on having better facilities for running multiple versions of shared libraries at the same time, which you’ll note is a core goal of the dotnet system. The other advantage of unix is that there is a culture of discipline that limits dependencies between various software layers.

    Historically, Win32 has been an undifferentiated mess of twisty code. It sounds like MS is finally making some decisions about where to draw the line between system code and user code. That fact that this is a non-trivial problem seems to indicate that Windows has been poorly managed. Ad-hockery on top of expedient shortcuts.

    The challenge is to fix Windows without turning it into something that is (Not)Windows. Not a job I’d want. I suppose the Restart Manager could mitigate the worst cases and the Pareto principal will apply, but there will be a core of 25% of mandated restarts that will simply be too intertwined to be performed ‘hot’.

  4. jws, I agree with most of your points. I can’t speak to how Windows became as deeply intertwined as it is but I know people are doing work now to untwist it piece by piece. A long process for sure and interesting to a suprisingly many, so here’s to hoping it gets better.

    Also, in my mind, a reboot is a reboot. It doesn’t matter what level of the software stack caused the reboot, reboots should be avoided. Smaller updatable core operating system just improves your chances of avoiding reboots.

    Fundamentally, I agree with your comment about a culture of discipline in UNIX and wish there was more of it in Microsoft (not that disipline is absent, just compromised a bit too often, IMHO).

  5. jws says:

    Let’s not talk about ‘reboots’ as such. Whenever possible we should not interrupt the user. There is a continuum of inconvenience that goes-

    1. no visable effect

    2. close and re-open application

    3. log off/log on

    4. shutdown/restart

    In the ideal state the inconvenience of patching a piece of code should be proportional to the importance of the code. Obviously, changing out ntoskrnl.exe is going to require a systemwide reset. My assertion is that this has not been the case in the past. In NT4, changing tcp/ip SETTINGS required a reboot, even without one byte of code changes. MS never paid the ‘tax’, as Raymond Chen calls it, of making os-level code components dynamic and modular. It’s a case of ‘pay now’ or ‘pay later’, and the bill collector has finally caught up.

    (I don’t mean to harp on this. I’m just hoping you spread the meme internally.)

  6. michkap says:

    I have some separate concerns about reboots needed for other, possibly more routine, reasons — like default system locale changes.

    I will blog about this soon, myself….

  7. There is something actually akin to runlevel 3 in Windows but to my knowledge we don’t take advantage of it for the purpose of updating user-land code: log off and back on. Even at runlevel 3 some services still run on *nix. Maybe it’s not completely the same, but close.

    The registry value HKLMSYSTEMCurrentControlSetControlSession ManagerPendingFileRenameOperations is not, unfortunately, processed until a reboot and happens very early during start-up. NTFS does allow the in-use file to be renamed and replaced but as Rob points out the application is still using old functionality. In this case the app can simply be restarted but few installer technologies or versions take advantage of that fact and prompt for a reboot if the application was running and not shutdown.

  8. Leon Zandman says:

    Mmm, I really like the fact that Microsoft addresses these reboot-issues, but this whole Restart Manager stuff sounds like it’s only targetting the symptoms and not the real cause.

    Now, by means of the Restart Manager API, the responsibility will be at the hands of the application developers, who will have to make sure their applications freeze/unfreeze in the right way. I foresee a lot of buggy (third-party) implementations that will probably cause the whole Restart Manager system to fail. Or am I being too pessimistic?

    And ofcourse it is cool to have Office 12 shutdown and re-open and remember their previous state, but why would I want to update Office while at the same time typing an important Word document in the first place? I never perform critical updates and continue working with the piece of software to which the update is applied. I always make sure everything is backed up, shutdown all my applications an run the update. Not because the update process forces me to, but it just feels more safe…

  9. Leon, while an end-user may not update their own computer while working on, say, a document a user on a corporate network that left a document open overnight might be updated according to the group policy. The idea is that when he or she returns to the office the next morning they won’t even realize they’ve been updated because everything that handles the message reboot manager sends is back in the same (or close, depending on implementation) state.

  10. Leon, first the "real cause" is a fundamental design choice in the operating system. There is no way (in the current design) to 100% avoid reboots. The same is true for UNIX. If you update the kernel (of any operating system), you’re going to have to reboot. I remember vaguely an embedded OS (maybe QNX?) that was uber-modularized and almost everything (or was it everything?) could be updated without reboot. They made some fundamentally different design decisions there than UNIX and Windows did.

    Second, you are being pessimistic but only time will tell if it is overly so. I think the Restart Manager is a good idea that will help in some (maybe many) cases.

    In every demo that I’ve seen, Restart Manager does a better job of detecting/stopping applications and services to avoid a reboot than the Windows Installer alone does today. That seems like goodness to me.

    As I noted above, other people are already looking at how to go after other aspects.

  11. Dean Harding says:

    > The idea is that when he or she returns to the office the next morning

    > they won’t even realize they’ve been updated

    Hallelujah! I remember working in a corporate environment where they would do updates in the middle of the night and if you happened forget to save/close what you were working on, then too bad – it just rebooted and you lost everything…

    One question, you mention the "Reboot Manager API", does this mean that an application has to be specifically designed to handle the reboot manager? How much of it is automatic and how much has to be handled by the application developer "manually"?

    It just seems to me that few applications would actually take advantage of the APIs and handle them correctly (because it’s a "tax" as Raymond Chen would put it – effort for the developers with no immediate benefits).

  12. Dean, check out the Channel 9 video clip I posted. They talk about more Restart Manager details there.

  13. Leon Zandman says:

    > The idea is that when he or she returns to the office the next morning

    > they won’t even realize they’ve been updated

    If I were a network administrator I wouldn’t be too happy about users who keep their machines logged in for the night. A sudden nightly reboot would actually be a nice punishment for them 🙂

    > because it’s a "tax" as Raymond Chen would

    > put it – effort for the developers with

    > no immediate benefits).

    Well, it clearly benefits the user experience, so that should be satisfying for the developer also. Users will expect all of their software to implement Reboot Manager functionality.

  14. Phil Wilson says:

    IIRC, your app gets a Windows Message telling it that the RM is about to shut it down, so the app saves its state. The app also has to register with the RM to be restarted with an explicit command line after the reboot. So the app looks at the command line when it starts up and sees it should rehydrate its preserved state. Yes it is app work, but I can’t think of a practical way for the OS to take on that burden.

  15. I’ve done application repackage and SMS deployment and I accomplished the same type of behavior using custom actions.

    Basically SMS would push an MSI that would detect a running process and kill it. After the program was upgraded it would start it back up using the credentials of the logged on user. Since the program was just a stateless presentation layer for the mainframe ( think UDP ) the application would look just like it looked before it was killed.

    Fancier implementations could be achieved with a little application development. After all we’ve managed to creation hibernation for the entire OS, developers can do this for their apps if they really want to.

  16. Hej,

    Windows Vista har en ny funktion som vi kallar restart manager. Denna funktion gör det möjligt…

  17. RJBruce says:

    Leon Zandman, as a network administrator myself, there’s a huge difference between (a) being unhappy that people are staying logged in with documents open and unsaved, and (b) willing to force a logoff or reboot.  When you’re dealing with people’s (very expensive) work product, you can’t just blow it off and say "they know better."  They should and do know better, but expensive lessons are bad lessons.  If I can get a machine updated and they don’t know anything happened, that’s fantastic.

Skip to main content