Why is it sometimes that I need to restart my computer after installing new software and at other times I don't?

Is there any reason why it needs this reboot or why it's not always one way or the other?

  • 2
    It's basically to update the registry Aug 4, 2010 at 2:07
  • 4
    In some cases you can just restart a service instead of rebooting.
    – ccook
    Aug 4, 2010 at 9:37
  • see also superuser.com/questions/2467/… Aug 4, 2010 at 11:37
  • 8
    @dwayne Most problems are with locked file (dlls) not the registry. The registry is being used to tell windows the files to replace on the restart but is not the reason the restart is needed. Aug 4, 2010 at 11:58

7 Answers 7


It depends.

If the software being installed affects an integral part of the operating system then a restart is required. For example a new kernel for the operating system.

On Windows systems, it is often used used because users are considered to be too stupid to use their computers properly. As an example, Microsoft publishes details of how to change the "Node Type" used for networking on its website, including the instruction to "restart the computer" when all that is required is a restart of a network service as detailed here. Because we, as users are too stupid to restart a service, we are told to restart everything.

For some pieces of software, I have come to the conclusion that it is a habit and is often not necessary even when told to do so. If I don't think that a piece of software should have done anything major to the operating system, I tend not to bother, and haven't experienced any problems (and if there were problems they would be easy to solve).

  • 6
    I agree. These days, unless they update a critical system file or driver, there is no reason to have to restart the system. Often it is developers who want to make sure they "cover all the bases."
    – surfasb
    Feb 13, 2011 at 6:30
  • 1
    If it's an older installer, it may just ask for reboot regardless. If it's a naive developer, it may be set to prompt for restart regardless of whether or not it's needed. Newer installers that correctly leverage the features in MSI are actually able to report on what applications are holding needed files (dlls, etc) open and prompt the user to stop them - it's only if they choose to leave the applications running that they will be prompted for a restart. It's pretty much a sloppy mess, nothing forces devs to use MSI, much less use it correctly.
    – Stephanie
    Jul 17, 2011 at 2:29

Sometimes a piece of software will make a change that cannot come into effect while the computer is use. Some reasons might be - a file is in use, the change can only occur during boot up of the computer, there might be a security issue which can only be done before the computer has its networking active, maybe the virus scanner would interfere with the install.

Sometimes, it's just sloppy programming by the developers.

I'm sure there are many more.

  • 1
    In particular, which changes cannot come into effect when the computer is in use? Jan 23, 2013 at 20:09

Often when you install new software a DLL (file) that is used by lots of other software packages need to be upgraded to a new version. (This much more likely to be the case when upgrading an application you already have installed.)

If the DLL is being used by an running application, part of it will be loaded into memory and the rest will be read from disk when it is needed. Therefore the DLL will be locked on disk. (Think of the problems if it was not locked!)

A DLL that is locked cannot be updated, so the installer will ask windows to replace the DLL with the new version the next time the machine is restarted. Hence the need for a restart.

Some better installers will tell you the applications that should be closed down before running the installer, so letting the DLL be updated without a restart. However that make the installer’s UI more complex and leads to more support calls.

An installer for an application can also get the application to save its state, shut it’s self down, then restart after the DLL has been updated. This can only be done if the DLL is used by a single application. Most self updating applications do this – this should be the norm for mass market applications when there are lot of users.

All of the above can lead to complex logic that is hard to test. Testing installers takes a long time, as you need to try to guess every state a user’s machine may be in. So it is often best for an installer to be simple and always work, even if it leads to a few more restarts for the user.

It is not often that a user decides to buy a different application due to installer restarts, so the vender spends the time (money) working on what is needed to get user’s to buy their applications.

How often have you had a problem after installing an application that sorted itself out when you did a reboot? Think of the support costs of lots of users phoning up with problems that are sorted out just with a reboot. It can quickly become very tempting as a developer to always get the user to do a reboot after installing your software even when you think it is not needed.

Most operating systems and software were written in the days when diskspace and memory cost a lot of money. There is now a move for applications to have a private copy of all DLLs they use, hence making upgrading easier, but using more storage space.

On servers this is being done with "containers", however "containers" don't work well for desktop software, as you wish to be able to access the data saved by one application with anther application. (Otherwise just use a iPhone.)


The reason is because if you don't: you will crash. From Raymond Chen:

Even if you replace a file that is in use, there may still be code in the system that wants to use the old version. For example, suppose you have two files which work together:

  • A.dll
  • B.dll

You issue a patch that updates both of the files, but A.dll is in use. No problem. You simply replace both of them. As a result, programs that were still using A.dll keep using the old version, but new programs will use the new one. And all programs get the new version of B.dll.

Now a program that was using the old A.dll decides to call a function in. It naturally expects the old version of B.dll, but instead it gets the new version. Depending on what sort of change you made to B.dll, this call may work—or it may crash. Both DLLs assume that its partner comes from the same matched set.

  • There are ways around what you describe, but they require thought. Jan 11, 2013 at 17:09

To be completely honest, it's less work (and therefore less $$) on the part of the software developers to assume that updates will always result in a restart. This is probably as much a decision of the bean counters as it is of the developers.

Ultimately, there are very few updates that could not, in an ideal world, be done without restart, but it takes a lot of pre-planning, and there are some risks, given the wide variety of possible configurations a system might have.


It has to do with the fact that it is very hard to change code as it is running without causing some major problems. The solution: stop everything before changing the code, that way you can be sure nothing is running. It is a brute force hack that is largely unnecessary a lot of the times that it is supposedly required, but it can be absolutely necessary, especially if you happen to be updating particularly important code. There is actually an entire company that specializes in making updates that DON'T require a reboot for this particularly important code. The way that they do it is in this paper http://www.ksplice.com/paper.


You're required to restart when important system files for Windows are being modified, because Windows does not allow these files to be modified while they are in use. So most updates from Windows Update require a reboot, as do programs that integrate themselves into Windows (like antivirus). Until you reboot, Windows cannot perform the last few steps necessary to "install" the program.

You can compare this to Linux, which rarely requires you to reboot. Even when you are asked to reboot, you usually only need to log out and back in. This is because a typical Linux environment is comprised of many different separate programs that work together to create a complete OS. If an important file is modified during an installation, you usually at best only have to restart the one specific program that uses the file.