I have always been wondering why Windows Installer only allows you to install one program at a time. It is very frustrating not to be able to launch multiple installations, especially when setting up a new installation of Windows. What is the reason for that?

  • So far, none of the responses directly address the question. A good answer would explain what is fundamentally different about Windows installations compared to other systems. ¶ For instance, if it asked why Windows must reboot for updates when Linux just keeps on running for years, the explanation would be that Linux allows files that are currently in use to continue being used even after they have been removed from the file system, whereas the Windows file system was not designed to do that. Commented Sep 28, 2022 at 12:57
  • The former comment is wrong. If Windows needs reboots for updates depends on the updates, pretty much like with Linux. In both cases even live patching doesn't handle all possible cases, why all major Linux distributions contain infrastructure to tell the user about necessary restarts. Deleting files in use is possible for Windows as well of course, just have a look at dwShareMode for CreateFileW and FILE_DISPOSITION_INFORMATION_EX with e.g. FILE_DISPOSITION_POSIX_SEMANTICS. Pre-conditions are different, for Windows/NTFS first user decides and needs to explicitly OPT-IN to things. Commented Feb 17, 2023 at 13:31

3 Answers 3


It would be very complex to guarantee correctness, when concurrent installations take place - assuming that they share some of the files. This would need some form of transactions.

  • You need to lock files
  • It should be possible to undo intermediate changes, if the installation fails (not sure, if that's possible now?)

These concepts are known from transactional databases - but the topic isn't trivial, and you usually don't find a fully transactional infrastructure in file systems (even though journaling file systems provide a part of that). One problem is, that multiple locks can lead to a deadlock - then you need deadlock detection (or both installers will hang forever), and a way to treat that. Deadlocks can be avoided (e.g. by always locking files in the same order), but there are other problems:

If you lock all the required files up front, you get effectively what you have: One installer must wait until the other is finished. If you don't lock all required files up front, and keep on going, you risk that the "transaction" will fail. That would mean, that one of the installers would have to be restarted.

Then you may have to think about transaction isolation levels - to be fully correct, your transactions would have to be "serializable" - but that's not easy, even for many databases.

There may even be alternative strategies to deal with the problems, which circumvent full isolation, but it would usually be even harder to prove their correctness.

I believe, with concurrent installation, we would have a lot more intractable post-installation problems - especially because I don't think, an OS vendor (or a distribution) would go through all the trouble to make it 100% clean. So I would prefer not to use it, even if it were offered by the OS.


But maybe what you really want is not even installing "at the same time". Maybe it would be sufficient, if you could queue up the installations, which are then executed one after the other (ideally without asking any questions in between). And that's really something, some other OS (distributions) handle a lot better.

  • 2
    While correct, this answer seems to me too verbose. Someone asking why the installer service works the way it does is not likely to understand this answer.
    – gWaldo
    Commented Aug 27, 2010 at 13:32
  • 4
    @gWaldo: Okay, maybe you're right... Then again, I don't just want to say "It's complex, believe me (period). You wouldn't understand it anyway". Maybe the OP (or someone else stumbling on this question) is truly interested, and an answer that gets to the bottom of the problem will help him to estimate, if there's really a lot of complexity involved to solve something that looks so easy on its surface. Who knows? Commented Aug 27, 2010 at 14:08
  • Very true. That's a good point.
    – gWaldo
    Commented Aug 27, 2010 at 14:21
  • While all the talk about isolation sounds plausible, you can run multiple installers if they do not use Windows Installer framework. I've never had any of them break when running side by side... Maybe I'm just lucky :) As for queueing installations, there are tools for that, but given multicore CPUs (heck, desktop CPUs can now run 8 threads...), it seems that running them side by side would be the answer (although they may still fight for I/O).
    – Rytis
    Commented Aug 27, 2010 at 15:33
  • 2
    @Rytis: I wish I had the same luck :-) - I've had installers break randomly even without running them concurrently. About multicores: There would be another way to utilize them: By using multiple cores within one installation process. That's still not always possible or easy, but can be coordinated a lot better. Overall I think, the biggest time saver is still, if the entire installation process (queue) only asks questions at the beginning and at the end. Then you can get a coffee, or do something else while the installation runs (and utilize the remaining cores for whatever you want to do.). Commented Aug 27, 2010 at 16:32

This is by design, in order to avoid having two installations manipulating the same files/folders/registry keys/etc.; it could probably have been done in different ways, but Microsoft made this choice.

  • 1
    Any reference to support your claim? Commented Aug 27, 2010 at 15:11

Concurrency: You can kick of several MSI files to install in rapid sequence one after the other using a batch file. You can not run two MSI files simultaneously in the sense that they both write to disk at the same time.

Transaction & Rollback: The reason is that part of an MSI installation is run as a "transaction" - a sequence of changes that are either committed or rolled back depending on whether the actions in the transaction list complete without error. All must complete without error, and then the transaction is committed, otherwise a full rollback of all changes occur. It follows that only one such transaction can be active at any given time.

Technical Sequences: At the technical MSI level, only the actions between the standard actions InstallInitialize and InstallFinalize in the InstallExecuteSequence are run as a transaction. No system changes are supposed to happen outside these actions, but sometimes MSI files are erronously designed to make changes in other sequences.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .