Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
In prior versions of Windows, especially if the installation had many applications installed over the years, it was not easy to run a program or navigate the system shortly after booting. I remember fighting with my mouse or looking over at the system chassis to see if the hard disk light was still blinking frantically, wondering "Are we there yet?"
Now think about the ideal Windows startup experience. Perhaps you envision not only the desktop loading quickly, but having a system that is responsive immediately. This was one of the Windows Vista design goals, but how did we make it happen? Enter Windows Vista's new "boxing" feature. In Vista, applications started from common startup locations get automatically "boxed" for the first 60 seconds. The term "boxed" means it will run with reduced priority, yielding and giving precedence to other programs such as those manually launched by a user.
OK, so what does that mean in practical terms? If you think of all of the applications installed on your system, there is a very good chance that one or more of them is an application that launches at startup via the Run key in the registry (HKLM\Software\Microsoft\Windows\CurrentVersion\Run). On pre-Windows Vista operating systems, applications that added themselves to this key tended to think of themselves as more important than any other applications. The net result was contention when all of these applications were battling with each other to start up first. So when a user tried to launch an application such as Microsoft Outlook, or Internet Explorer themselves when they logged on initially, the application appeared to be running very slowly and seemed unresponsive. The application was actually being stepped on by the startup applications fighting with each other to start.
Now, there are a couple of things to be aware of when dealing with “boxing applications”. The first is that you can disable this feature via a registry change. In the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer\Advanced\DelayedApps key is a value called Delay_Sec. This value determines the amount of time that applications are “boxed”. By default, this value is set to 60 (decimal), which is 0x3c in hexadecimal. You can change this value to 0, which will disable the boxing feature. One thing to note here, is that in order to make this change, you will first have to take ownership of the DelayedApps key in the registry.
Finally, if you’re an application developer reading this, and wondering if you can programmatically circumvent this feature, the short answer is “No”. Check out the post on the Vista Compatibility Team blog regarding this.
- Aaron Maxwell
I did a bit of playing around with this (SetThreadPriority, Vista, and Autostart Locations @ http://mygreenpaste.blogspot.com/2007/11/setthreadpriority-vista-and-autostart.html). It may be interesting to note that autostart apps launched via the Run key in the registry (or the Startup folder, as the referenced Vista Compatibility Team Blog posting indicates) also have their child processes "boxed", eliminating what would seem to be an easy way to "defeat" boxing.
The link you gave actually contradicts what you wrote here (slightly). It says that thread priority will be fixed at normal, that is, attempts to increase the priority will fail, which is not quite the same as reducing the priority. If I read that correctly, it should not affect a well-behaved application which wasn't boosting its priority in the first place.
And I'd like to point out that you've just told people how to programmatically circumvent the feature. It's just not trivial, and requires elevation. Don't think sufficiently poor-behaved applications (or rather programmers) won't do that anyway if they want to, though.
The Vista startup experience is one of the worst things that Vista brings to the table. Granted, it may have nothing to do with running startup applications, but the end-user startup experience is nothing short of terrible - even on high-end hardware.
It's so bad, in fact, that I recommend to everyone I know who's using Vista, to put their machines in standby or hibernate and never reboot (until of course the never-ending, monthy security patches require it). Vista contains 30 scheduled system tasks and at least 12 of these run either during system startup or at user logon.
It's particularly terrible after installing Windows Updates, which is pretty much the only time I reboot, thus making it seem to me that the system startup was consistently terrible.
(Also another unfortunate correlation with Windows Update/setup programs that require a reboot is the absurd amount of time it takes to restart - my assumption as to what happens is that they kick off a shadow copy, and then while rebooting, the new feature of Vista that allows a service to finish its work during shutdown causes it to take forever to do so until the shadow copy is finished).
I was wondering why my startup script was acting like it got booted in the head. Now I know.
Boxing -> interesting term for windows startup.
Still reminds of waiting for an Amiga 1000 to boot up, build a big ram drive, copy 2 800K floppies to said ram drive and then finally load the workbench.
No floppies, but not really any faster either. Shame really. At least my Amiga could decide that the ram drive contents were safely recoverable and bypass the floppy copy if you didn't do a full power down or boot a custom OS floppy....
I guess the message here is : the process still needs work, keep at it.
Yes, overall I have experienced faster logons and availability but when updates are installed, it's "Please wait while Windows configures updates" all the way before shutdown AND the next logon. Maybe MS decide to worsen the patching experience.
interestingly that in Windows 7 the default setting for "delayed apps" is 0 and not 60 as in vista.
I am more and more convinced that Win7 is only a highly tweaked vista. I will go thru all the registry settings and implement them on a vista box just to see if the performance will be equal.