IE9 No-Reboot Setup and the Windows Restart Manager

On Windows 7, Internet Explorer 9 can often be installed without rebooting the system. In cases where a system restart is required, either the system lacks one of the required prerequisites (so IE Setup is forced to install it and reboot) or a running program or service is holding one of Internet Explorer’s binaries and it cannot be unloaded.

As explained on MSDN:

The primary reason software installation and updates require a system restart is that some of the files that are being updated are currently being used by a running application or service. Restart Manager enables all but the critical applications and services to be shut down and restarted. This frees the files that are in use and allows installation operations to complete. It can also eliminate or reduce the number of system restarts that are required to complete an installation or update.

The Internet Explorer 9 Setup program will attempt to close programs that are using IE binaries before installing the updated versions. Programs which have been closed by the installer will be restarted if they fall into one of the following three buckets:

  1. The program is registered to restart via the Windows Restart Manager
  2. The program is listed in the Start Menu’s Startup group
  3. The program is listed in the registry’s \Windows\CurrentVersion\Run keys

Registering to restart with the Windows Restart Manager is a best-practice, and is the ideal way to ensure that your application is cleanly unloaded and reloaded after the upgrade is complete.

One of my utilities, SlickRun, is a program launcher that runs when Windows starts and it loads WinINET.dll. Since this is an IE9-updated binary, the utility is shut down when IE9 installation begins and it is restarted when installation completes.

One of the interesting side-effects of restarting applications in groups #2 and #3 is that they’re restarted by calling CreateProcessWithTokenW. When launched by this API, a newly created process gets put into a new Job Object with blank limit flags. In certain obscure cases, this can cause problems for processes that are later spawned by the restarted SlickRun instance.

The problem is that when a descendent JOB_OBJECT_LIMIT_BREAKAWAY_OK flag is checked, Access Denied is returned because of the blank limit flags inherited from the restarted application’s Job Object. When testing IE9’s no-reboot setup, I observed that after SlickRun restarts, any Google Chrome instances it launches fail to function correctly. Chrome uses job objects to isolate its rendering processes and thus encounters the Access Denied issue.

I resolved this problem by updating SlickRun to use the Restart Manager; RM relies upon the Task Scheduler to restart processes and thus does not encounter the job-object limit.

SlickRun is written in Embarcadero Delphi and it now uses the following code to call the RegisterApplicationRestart function. I pass the RESTART_NO_REBOOT flag to ensure that SlickRun is restarted in the event of a crash or a software update, but not after a reboot, since the utility is already registered to start when Windows boots.

type TPKernelRegisterApplicationRestart = Function(lpCmdLine: PWideChar; dwFlags: DWORD): DWORD; stdcall;

Procedure GetWindowsVersionAndFunctionPointers;
Kernel32Dll: HMODULE;

Ver.dwOSVersionInfoSize := SizeOf(TOSVERSIONINFO);
WinMajorVersion := Ver.dwMajorVersion;
WinMinorVersion := Ver.dwMinorVersion;

if (Ver.dwPlatformID = VER_PLATFORM_WIN32_NT) then
Kernel32Dll := LoadLibrary('Kernel32.DLL');
if (0 <> Kernel32Dll) then
if (WinMajorVersion > 5) then
// Register with the Vista+ Restart Manager
@RegisterApplicationRestart := GetProcAddress(Kernel32Dll, 'RegisterApplicationRestart');
if @RegisterApplicationRestart <> nil then
RegisterApplicationRestart('-restart', 8 {RESTART_NO_REBOOT});


Similarly, applications that are written in .NET can also register with the Restart Manager like so:

public partial class Form1 : Form
public Form1()
if ((Environment.OSVersion.Version.Major > 5) &&
            (0 == RegisterApplicationRestart("-restart", RestartFlags.None)))
MessageBox.Show("Successfully registered for restart");

    [DllImport("kernel32.dll", CharSet = CharSet.Auto)]
static extern uint RegisterApplicationRestart(string pwzCommandLine, RestartFlags dwFlags);

enum RestartFlags
None = 0,
NotOnCrash = 1,
NotOnHang = 2,
NotOnPatch = 4,
NotOnReboot = 8


Restart Manager also supports a few other features to enable recovery of applications after a crash. Windows Error Recovery will restart the application after the recovery process completes, if the parameters passed to RegisterApplicationRestart request this behavior, and the recovery APIs enable the application to restore any preserved data.

If you develop an application that loads Internet Explorer binaries, please consider registering with Restart Manager to allow our shared users to have a more seamless update experience. Thank you!


Comments (11)

  1. mike belshe says:

    Thanks for the writeup – interesting stuff.  I hope this doesn't come across too harsh – I am just trying to help it get better 🙂

    Sounds to me like you've replaced "reboot" with "restart all of your interesting applications".

    Basically, if the user is willing to restart AIM, Messenger, Chrome, Flash, IE, Firefox, Office, and any other applications which touch WinInet, then IE9 can update without a restart, right?  But, all of those apps need to also be retrofitted to register with the Restart Service (does that exist on XP?), and if any of them don't, then you still need a reboot?

    Given that WinInet is the Microsoft-recommended method for accessing the internet on Windows, I hope more will be done to isolate apps so they can update independently rather than in one mega restart.  Or do I have it all wrong?


  2. @Mike: As you know, XP is in the final stages of extended support and IE9 won't install there. The question of componentization and reuse is a very interesting one and there are lots of pros and cons to it. The challenge of component reuse, of course, is that if the component is in use, servicing requires unload and reload. There are two alternatives: 1> limited Side-by-Side, or 2> full Side-by-Side.

    Limited SxS means that the application is allowed to keep running with the old binaries until a restart occurs. This is fine, except that if there are any cross-version compatibility problems, a crash may occur. (For instance, if the cache format changes, or some shared memory structure changes, etc). We actually have some support for limited SxS for AV applications (on a specific case-by-case basis) that load IE binaries.

    "Full" SxS is initially more appealing for compatibility– simply let every application have their own copy of the component and update it on their own schedule. I believe this is the strategy which is generally used by hosts of Gecko and WebKit. The problem is that with each security fix, either every application using the component must ship an update, or the user must suffer the risk that some software running a non-patched package will be exploited. We think that's too risky.

    There are other approaches, of course– hotpatching ( is one of those which can be very useful for servicing. On the downside, it can be significantly more complicated to hotpatch and it doesn't really work for a component-replacement scenario.

  3. Alexei Mihalchuk says:

    Since Vista also supports Restart Manager, will IE9 also install without a reboot?

  4. @Alexei: Good question. Unfortunately, while the Vista platform supports Restart Manager, not all critical services and applications on that platform that use IE binaries are using RM and hence no reboot installs are not possible on that platform.

    Fortunately, Windows 7 is rapidly replacing Windows Vista.

  5. Mike Belshe says:

    Regardless, restarting most of your applications is just as bad as a reboot – the user loses all state, has to close all work, etc.

    I know its hard work, but certainly MSFT won't shy away from a technical challenge, right?  🙂  This problem has been solved many times.  It's just a matter of whether you want to do it or not.

    But, if you're going to require all apps to restart, then I think it is disingenuous to claim that IE9 can restart without a reboot.  As an end user I can tell you, I've never upgraded IE9 without getting a reboot 🙂


  6. @Mike: I think you've somewhat missed the point. There's a set of tradeoffs to be made, and we've come down on the side of security. It's not a matter of trying to avoid "hard work" since it would be infinitely easier to just make a bunch of copies of IE binaries and let every app own updating their own copy.

    Well-written applications that use RM won't lose state because they can shutdown and restart and bring the user back to where they were before.

  7. Yuhong Bao says:

    Mike Belshe: Not on a server, where a full reboot causes downtime, while even a logoff don't.

  8. RichardDeeming says:

    On my Win7 Enterprise x64 system, IE9 setup closed the offending programs and told me Windows Explorer would be restarted when it finished. On completion, it decided to tell me that some files had still been in use, and I had to restart anyway.

    And all that to find out that my graphics card (EAX1600 Pro) is on the "not supported" list, so IE has to use software rendering!

  9. @Richard: Yes, unfortunately some services (and occasionally applications) holding our binaries fail to unload properly, or fail to restart properly, requiring a reboot. Hence, the value of these using Restart Manager.

    Vis-a-vis your graphics card, you should ensure that you have the latest drivers, and if you do, contact the graphics card vendor and request a timeline for a more stable driver.  Thanks!

  10. RichardDeeming says:

    @Eric: Unfortunately, I do have the latest drivers – 8.592 for Vista x64, released in April 2009. The vendor (ASUS) seems to have no interest in updating the drivers for their old products. The only mention of Windows 7 drivers I could find was a forum post from November 2009 asking when they would be released, which has never been answered. 🙁

  11. Yuhong Bao says:

    Tip: you can use Process Explorer to determine who is holding references to the system DLLs IE9 updates, such as JSCRIPT, MSHTML, IEFRAME, URLMON, and WININET.

Skip to main content