What order do programs in the startup group execute?

Date:December 25, 2003 / year-entry #177
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20031225-00/?p=41353
Comments:    22
Summary:The programs in the startup group run in an unspecified order. Some people think they execute in the order they were created. Then you upgraded from Windows 98 to Windows 2000 and found that didn't work any more. Other people think they execute in alphabetical order. Then you installed a Windows XP multilingual user interface...

The programs in the startup group run in an unspecified order. Some people think they execute in the order they were created. Then you upgraded from Windows 98 to Windows 2000 and found that didn't work any more. Other people think they execute in alphabetical order. Then you installed a Windows XP multilingual user interface language pack and found that didn't work any more either.

If you want to control the order that programs in the startup group are run, write a batch file that runs them in the order you want and put a shortcut to the batch file in your startup group.

Comments (22)
  1. Vladimir Yangurskiy says:

    How about "HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun" / "HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun"

    Are they run in order ?

  2. Raymond Chen says:

    The order of these is also unspecified.

  3. Jordan Russell says:

    But doesn’t the registry store/enumerate values in a "guaranteed but not actually documented" FIFO order?

    I’ve found that whenever a new value is created, it is always enumerated last by RegEnumValue(); it never takes the index of a previously deleted item. This behavior is consistent across Windows 95/NT/2000/XP.

    This would seem to indicate that even if Explorer does no special ordering of its own, it would still execute Run/RunOnce entries in the order they were created, because that’s the order in which RegEnumValue() enumerates them.

  4. Mike Dunn says:

    You might not want to talk about relying on undocumented behavior in Raymond’s blog. ;)

    I wonder, do the entries in Run/RunOnce still have a 31 char limit? Back in the NT 4 days I wrote a little app that needed to run from the Run key. Being a conscientious person I named the entry something really descriptive like "Bob’s Classy Software Thingamabob". Imagine my shock when QA reported that it was never running.

    It turned out that when the name was over 31 chars, the entry was never processed. So the OS was apparently using a 32-char buffer in its enum and silently skipping values with longer names.

  5. Jordan Russell says:

    Uh, yeah – oops… But in certain cases you have little choice but to rely on this "undocumented behavior" when working with RunOnce. Writing a batch file is not always possible if you don’t have control over the applications that are creating the RunOnce entries (i.e. third-party installers).

    As for the 32-character limit: I was also impacted by this! The limit was either eliminated or extended in the IE4 "Windows Desktop Update" shell. The fact that I had IE4 installed on my own system made it especially difficult to diagnose the problem.

  6. Raymond Chen says:
    1. There is no guarantee that the order of RegEnumValue will be "in order of creation". The registry code was tweaked for performance in Windows XP and I suspect it will be tweaked for performance in the future. One of these tweaks may change the order of enumeration, since that is unspecified.

      2. There is no guarantee that Explorer will execute Run/RunOnce in the order that they are returned by RegEnumValue. (In fact, Explorer reads in the entire list, then does some processing on it, then runs the keys. Some of the processing might result in order changes.)

  7. Raymond Chen says:
    1. There are "Startup manager" type utilities that let you edit your Run keys, disable entries, etc. I doubt any of them preserve enumeration order. So >even if you assume that the undocumented behavior will never change< you still can’t guarantee order of execution.
  8. I often wondered about the timing of execution of the programs in the startup group. Does Windows simply attempt to start all of the programs as fast as possible, one right after the other?

  9. Jordan Russell says:

    Order of execution isn’t so important with Run as it is with RunOnce. With you run a string of installers, each creating an entry in RunOnce, it’s sometimes important that the first-created RunOnce entry be run first, since the latter ones may require that the action performed by the first entry already be completed.

  10. Raymond Chen says:

    Explorer doesn’t do any explicit timing. It just runs them in some unspecified order one right after the other.

    RunOnce processing is more complicated because there are some programs that >add themselves back to to the RunOnce key inside their RunOnce handler<. Explorer needs to be careful not to go into some sort of infinite loop when this happens.

  11. njkayaker says:

    It’s a bit dopy to have the the "Run" or "RunOnce" items run in "random" order.

    While one can’t rely on the enum order, one could implement this in a reasonable way.

    One could have a "RunOrder" and "RunOnceOrder" branch that associates a order number with the name.

    (Great site by the way.)

  12. Raymond Chen says:

    If you have a dependency between items in Run or RunOnce, it’s presumably because you created the dependency yourself, so you can write the wrapper program yourself, too.

    Enforcing an order on Run is particularly pointless since they all get fired off one right after the other. Even if they launched in a specific order, that doesn’t mean that program A will reach input idle before program B.

  13. Jordan Russell says:

    "If you have a dependency between items in Run or RunOnce, it’s presumably because you created the dependency yourself"

    What about cases where you aren’t creating the RunOnce entries yourself? Say, for example, you spawn MS’s Visual C++ run-time redistributable (vcredist.exe). It slaps these entries in RunOnce (among other things):

    "atl.dll"="C:\WINDOWS\SYSTEM\regsvr32 /s C:\WINDOWS\SYSTEM\atl.dll"

    "comcat.dll"="C:\WINDOWS\SYSTEM\regsvr32 /s C:\WINDOWS\SYSTEM\comcat.dll"

    "mfc42.dll"="C:\WINDOWS\SYSTEM\regsvr32 /s C:\WINDOWS\SYSTEM\mfc42.dll"

    "oleaut32.dll"="C:\WINDOWS\SYSTEM\regsvr32 /s C:\WINDOWS\SYSTEM\oleaut32.dll"

    "olepro32.dll"="C:\WINDOWS\SYSTEM\regsvr32 /s C:\WINDOWS\SYSTEM\olepro32.dll"

    Now, let’s say directly after that (without rebooting) you spawn another installer which creates another RunOnce entry. This entry points to an VC/MFC-based program. This program will not work correctly if the VC/MFC DLLs aren’t registered.

    If we are to assume that RegEnumValue() no longer enumerates values in creation order, how should a situation like this be handled? It seems you’d have to find and hack out the RunOnce entries the two installers added (taking special care not to disturb RunOnce entries that were already in place beforehand), sort them in the correct order, write the list to some file or registry key, then add a new RunOnce entry pointing to a program that processes that list.

    It’s in cases like these that it seems relying on undocumented behavior is actually more reliable and less error-prone than doing things strictly by the books.

  14. Raymond Chen says:

    Well that just plain sucks then. If some other setup program is multistage (like vcredist.exe appears to be – there’s the "do this before the reboot" stage and the "do this after the reboot" stage), then they need to give you some way of making sure you can regain control after its final stage so you can continue with your part of the setup.

    Actually it troubles me that vcredist.exe is replacing system files like comcat.dll and oleaut32.dll in the first place.

  15. Simon says:

    Back in the Amiga days you could specify the order of the startup programs, if they would wait before starting the next one or wait a specified time. Now, fifteen years later, when I sit and wait for my old laptop to log me in after a shutdown (taking around 8 (!!) minutes), I often think back to the good old Amiga…

    For a long time I’ve had this creeping suspicion that if Windows actually waited until the first startup program was loaded and idle before loading the next, startup-times would decrease… Right now it seems Windows tries to start all programs almost simultaneously, making my poor 4200 rpm drive almost spin to death.


  16. Raymond Chen says:

    Of course this assumes that the startup program will actually go idle within a reasonable amount of time. If not, then you get the complaint, "Why don’t all my startup programs get started?" (or, if say we decide to give up waiting if a program hasn’t gone idle for say a minute) "Why is there such a long pause before program X starts?"

  17. You can of course delay-load your app with a starter app that sleeps for a bit before loading the main app. Of course, the starter app has to be very well written for minimal load overhead itself, and I have never found it that satisfactory.

    I suppose it makes sense for all those ‘we update your system behind your back’ apps that everyone installs now, from Roxio to Sun (!), but the best way to tune their load time is to delete every single one of them.

    IMO only having run-on-startup apps is a weakness. We really need run-on-first-idle and run-on-at-desk for laptops, where power and desk trigger work. I guess you could hack the last with SENS but it would be serious work indeed.

  18. Downtick says:

    This program listed below can delay or schedule programs to start whenver you want.


  19. George Vossinas says:

    It says here you can specify the startup program order. http://www.greatis.com/regrun3startuporder.htm#NT

  20. Raymond Chen says:

    They are relying on undocumented behavior which can change (and indeed has changed) over time.

  21. It happened some time ago. Right after the Community Server update on the blog, in fact. I was bothered

  22. RSS It All says:

    It happened some time ago. Right after the Community Server update on the blog, in fact. I was bothered

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index