| Date: | December 25, 2003 / year-entry #177 |
| Tags: | tipssupport |
| 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)
Comments are closed. |
How about "HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun" / "HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun"
Are they run in order ?
The order of these is also unspecified.
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.
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.
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.
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.)
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?
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.
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.
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.)
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.
"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.
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.
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.
http://amiga.emugaming.com/wbstartup.html
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?"
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.
This program listed below can delay or schedule programs to start whenver you want.
http://www.fgroupsoft.com/Absolutestartup/
It says here you can specify the startup program order. http://www.greatis.com/regrun3startuporder.htm#NT
They are relying on undocumented behavior which can change (and indeed has changed) over time.
It happened some time ago. Right after the Community Server update on the blog, in fact. I was bothered
It happened some time ago. Right after the Community Server update on the blog, in fact. I was bothered