Starting up inside the box

the shell team received two customer questions about a month apart which seemed unrelated but had the same root cause.

I found that in Windows Vista, the xcopy command is ten times slower than it was in Windows XP. What is the source of this slowdown, and how can I fix it?

We have an application which takes a very long time to start up on Windows Vista than it did in Windows XP. We noticed that the slowdown occurs only if we set the application to autostart.

Let's look at the second one first, since that customer provided a useful piece of information: The slowdown occurs only if they set the program to run automatically at logon. In Windows Vista, programs which are set to run automatically at logon run with reduced priority. This was done in response to the fact that application developers went angling for a bonus and decided to slow down the operating system overall in order to get their program to start up faster. To counteract this tragedy of the commons, the performance team runs these programs inside a job object with reduced CPU, I/O, and paging priority—which the performance team informally calls boxing— for 60 seconds, so that the user isn't forced to sit and wait for all these startup programs to finish doing whatever "really important" stuff they want to do.

Okay, back to the first customer, the one who reported that xcopy was taking a long time. It took a bit of back-and-forth, but eventually the customer revealed that they were performing the xcopy in a batch file which they placed in the Startup group. Once they volunteered that information, the reason for the slowdown became obvious: Their batch file was running inside the box, and consequently ran with low-priority I/O.

There is no way to escape the box, but it so happens that logon-triggered scheduled tasks are not placed inside a box. That's your escape hatch. Don't abuse it. (Of course, now that I've told everybody how to avoid being put in a box, everybody will now take advantage of it, because eventually, nothing is special any more.)

Oh, and if you look more closely at the Delay_Sec setting on a Windows 7 machine, you'll see that it's set to zero, so the boxing behavior is effectively disabled on Windows 7. I guess the performance team gave up. "Fine, if you want your computer to run like a dog when it starts up, then go right ahead. I won't try to save you from yourself any more."

Bonus chatter: You can explicitly "put yourself inside a box" by using the PROCESS_MODE_BACKGROUND_BEGIN process priority mode. Programs which are intended to run in the background with minimal impact on the rest of the system can use this mode.

Comments (41)
  1. Not Norman Diamond says:

    I tried editing HKLMSWMSWindowsCurrentVersionExplorerAdvancedDelayedAppsDelay_Sec to change its value from 0 back to 60 and regedit says 'Error Editing Value – Cannot edit Delay_Sec: Error writing the value's new contents.'

    That sucks.

  2. PlexMan says:

    @Not Norman Diamond

    Follow the first link and in that article you will see why you can't edit the registry value:

    "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."

  3. @Not Norman Diamond

    "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."

  4. Joshua says:

    Good riddance.

    Incidentally, it's immediately obvious to me how to work around this behavior if some no-good application vendor wanted to do so. The essential technique was published in an MSDN article for NT4 about how to write a self-deleting executable.

  5. configurator says:

    I've notices a lot of these kind of apps have splash screens (which is an extremely stupid idea, by the way), and display them while loading on login; slowing down over the first 60 seconds will only cause the splash screens to display for longer and the system to seem actually slower to load (although it would be responsive while said screens are shown), wouldn't it?

  6. jader3rd says:

    But at least with scheduled tasks, I can administer them to behave as I want them to.

  7. Joe Dietz says:

    I've always taken the opinion that balancing and scheduling processes, threads and memory is best left up to the kernel team.  Attempting to arbitrarily control resource usage at the application layer is often counter productive.  Though I entirely understand the motivation, most of these things being autostarted could very likely have waited a bit to start, or should have themselfves elected to run at a low priority.  But the shell team really can't win here, so I'm glad to see they recognized defeat when they saw it.  Win7 is an obviously better product than Vista, which I think reflects the maturing of its developers.  Vista had the feel of a fresh generation starting at Microsoft full of idealistic ideas about how to change the world, Win7 has the feel of an experienced team that understands their limitations.

  8. Anonymous Coward says:

    The only solution to this problem is to make it impossible for applications to set things to run on startup without user intervention.

  9. 640k says:

    A service which polled for users logging on and started a custom logon job would also do the trick.

  10. Bart says:

    Don't worry Raymond, the secret was already out. I was wondering why some vendors where starting their software through tasks, instead of using the startup group or the oh-so-invisible [/sarcasm] windows/currentversion/run entry in the registry.

    At least I now know why.

  11. Jonathan says:

    Maybe Windows 7 aims at solid-state drives, where the I/O burden would have much less of an effect.

  12. Dan says:

    @Anonymous Coward

    Be serious.  99% of users when prompted by the application to "click X to make SuperDooperMegaFunFunFun start faster" will robotically click X adding it to autorun on startup, just like they're successfully social engineered into installing any malware that leaks through their security screens.

  13. cheong00 says:

    Actually in some case I want to have user setting to control the running priority of certain application (with aid of some dialog obvious like "compatability option"?)

    There are some applications that users will want to run in background priority. But now the user seems to have no way to set the preference themselves.

    Note: For advanced users that is comfortable with command line, they can use "start low/normal/high/realtime" to specify the priorty before the application loads.

  14. Ens says:

    Certain applications change behaviour when run under a job object.  I recall a bug I fixed some months ago for a big release.  Our main process, call it process A, was creating a second process, call it D for Destination, with CreateProcessWithTokenW (which was used to de-elevate privileges).  That second process was ultimately launching an arbitrary list of 3rd-party applications.  A certain commonly-installed product from a non-Microsoft product exhibited pathological behaviour.  We might have let that slide, except that the product in question was a direct competitor to our product, so it gave the appearance that we were doing something underhanded when we really weren't.

    Turns out that our competitors' process doesn't like being placed in a job object, and CreateProcessWithTokenW puts the child process in a job object with no chance of escape (no JOB_OBJECT_LIMIT_BREAKAWAY_OK).

    Ultimately my solution was to create two intermediate processes.  Call our original process A and the findal target application D for Destination.  A would CreateProcess process B.  Process B would put itself in a job object with JOB_OBJECT_LIMIT_BREAKAWAY_OK, and then CreateProcessWithTokenW C.  This automatically placed C in process B's job, so the API's side-effect of adding its own job was defeated.  C would then call CeateProcess with CREATE_BREAKAWAY_FROM_JOB process D.  On net, we achieved a CreateProcessWithTokenW from A->D without ever putting either A or D in a job object.

    Of course, this whole scenario falls apart if we ourselves were created in an unbreakable job object (if it's breakable, then the B process is unnecessary but not harmful).  But at least then we could point our finger at somebody else as triggering the problem :).

  15. Gabe says:

    It might be nice for everything run from the Run registry key to be low priority but allow users to set the links in the Startup folder to run at regular or low priority. That way if somebody wants their crap to not run so slowly they can put it in the Startup folder where it won't be invisible to users.

    If a user decides that their start-up is too inconvenient they can go to the Startup folder, see what shortcuts are for unimportant programs, and set them to low priority. Assuming shortcuts would have a way to set the priority of the program they run, this should be a good way to put users in control of their startup experience.

    [Visibility doesn't help. I go to my Startup folder (I bet most users don't even know that there is a Startup folder), and I see "Contoso Client". Can I delete Contoso Client? Will my computer stop working if I delete Contoso Client? Last time I deleted something from my Startup group, my 3G modem stopped working. Play it safe and just leave it there. -Raymond]
  16. Paul says:

    This seems like one of those "Darned-if-you-do, Darned-if-you-don't" situations.  This is truly a fantastic idea, in my opinion–There are machines out there that *clearly* require some level of intervention along these lines during startup.  Between consumer AV, browser plugins, PDF readers, IM, "helpful" utilities that shipped with consumer hardware, and *VM updates, the value of something like this becomes readily apparent.

    *Whatever* most of those things are doing during startup, they certainly don't need to be doing it at a high to moderate priority level.

    That being said, if one or more of those utilities does something even more annoying like paint a splash window, create a dialog or 2, etc, the user gets stuck with an unresponsive window or splash hovering over their desktop (or worse, at the top of the desktop).


    Maybe it would be cool if the feature kept the program in a box until it painted a window? Developers that try to get out of the box by painting a useless window might rapidly annoy their users into disabling/uninstalling their program, so the risk of leaving such an obvious escape hatch might not be so bad?


  17. Nick says:

    Just a guess, but perhaps they ran into complaints from people who manually added things to startup.  For example, say someone adds Outlook to startup because they want it to always run at login. Under Vista they might have to sit and wait *longer* than they would had they just clicked an Outlook quicklaunch icon.

    And, as you point out, there is an "exploit" that can be used to bypass the lower priority.  The team probably figured that they really only had two options: make it impossible to automatically start programs at normal priority (bad because it cripples users) or give up (why maintain code for a feature that everyone you've targeted it for has found a way around it anyway).

    I think they made the correct choice.  Eventually someone has to be left holding the blame for poorly written software.  Ideally it would be the crappy software vendors, but if not then it's left on the user who chose to install their software.  This seems like the only real option, as long as we're not living in some nightmare locked-down world where users cannot fully choose what software to install or remove (iOS and locked Android).

    I don't envy the people trying to balance the decisions which help provide a good Windows experience for the "regular" computer users with those that give "power" users the flexibility and capabilities they desire.

  18. stb says:

    Very interesting article. I searched MSDN / Google for setting I/O-Prio programmatically for my process to "nice" without going for low Page priority. Using PROCESS_MODE_BACKGROUND_BEGIN just nices all things (I/O, CPU, Page) which slows down my service. I realized I could set the I/O-Prio to low when opening a file, but could not get this to work (C# call to win32api). ProcExp still showed the file handles having "normal" prio.

    Now I saw the reg keys BoxedIoPriority, BoxedPagePriority and BoxedPriorityClass for startup processes. How can I set I/O-Priority alone for my process?

    BTW, here's my (non-functional?) code for nicing I/O prio for a filestream in C#:


           internal struct FILE_IO_PRIORITY_HINT_INFO


               public UInt32 PriorityHint;


           [DllImport("kernel32.dll", SetLastError = true)]

           private static extern bool SetFileInformationByHandle(IntPtr hFile, uint fileInfoByHandleClass, [In()] ref FILE_IO_PRIORITY_HINT_INFO info, UInt32 buffersize);

           private static void SetFileBackgroundMode(FileStream fs)


               var hint = new FILE_IO_PRIORITY_HINT_INFO();

               hint.PriorityHint = 1; // low

               SetFileInformationByHandle(fs.SafeFileHandle.DangerousGetHandle(), 12, ref hint, 4);


  19. Burak KALAYCI says:

    "I won't try to save you from yourself any more."

    Thank you nanny!

  20. Brian Tkatch says:

    One reason to hold back from purchasing the book, is demonstrated here: Half of Raymond's stuff is interesting because of the linked articles. Some may be humorous, others are quite informational.

  21. Thomas says:

    > they can put it in the Startup folter where it won't be invisible to users

    Unless it is, you know, *hidden*.

  22. Joshua says:

    [Last time I deleted something from my Startup group, my 3G modem stopped working. Play it safe and just leave it there. -Raymond]

    My response would have been either to replace it with a desktop shortcut called "Connect" or return the product to the store depending on the severity of the design problem requiring an auto-start application.

    [You, my friend, are not a typical end user. (And returning the product to the store means canceling your 3G contract with your cellular provider. And who knows, the provider you switch to may have the exact same problem!) -Raymond]
  23. Gabe says:

    I'm not sure I understand the argument against having startup items in the Startup folder in order to let people choose what priority they run with (assuming a hypothetical feature allowing a shortcut to specify a priority). Are you saying that putting things in the Startup folder is a bad idea because people might delete the shortcuts without realizing they're important? I wasn't advocating deleting shortcuts (just changing their priority), but certainly if a user finds their Startup folder and deletes something unwittingly, only to find that their computer stopped doing something they cared about, they could always undelete it. Furthermore, because it's a shortcut, it can have a comment telling you how important it is to the functioning of your computer.

    The problem with the Run key is that there's no penalty to the softwar vendor for putting their program(s) there. Most users don't even know about it! Even if I'm a user who knows about it and is willing to edit my registry, all I can tell is that there's some program called BTTray.exe that is supposed to run. I have no idea what that program is or why it's running when I log in, nor do I have an easy way to undo the operation if I delete it.

    A Startup folder shortcut is something I can discover just by browsing my Start menu, it has an icon and a comment telling me what it is ("Bluetooth with Enhanced Data Rate Software"), and if I remove it (by moving to the Recycle bin or just another folder), I can easily undo the operation if I need to.

  24. David Walker says:

    Of course, the original "asker" didn't know that saying "I found that in Windows Vista, the xcopy command is ten times slower than it was in Windows XP" is not the same as saying "I found that in Windows Vista, running the xcopy command from the startup folder is ten times slower than it was in Windows XP".  

    I can almost understand their confusion, but, didn't they ever try to debug this by running the same program manually, that is, after Windows had started up?  They should have noticed that it wasn't slower then.

  25. David Walker says:

    @640K:  POLLING for users to log on?  No, that's just wrong.  Very wrong.

    You can schedule tasks to run at logon.  Several well-written program installers will help you with this, by prompting you to enter the logon password on the screen that's about to come up, then it uses the Scheduled Task creation interface to bring up the Add Scheduled Task window (whatever its official name is).

  26. Alex Grigoriev says:

    How about simply making the applications start faster? By simply bringing the whole image into memory on the image load. Touch every page, and it's there. And because it's linear read in most cases, it's very fast. The computers got at least 2GB these days, in case somebody didn't know that.

  27. asf says:

    @Alex Grigoriev: The exe might be fragmented all over the disk * several apps = a lot of pointless I/O.

  28. David Walker says:

    @Alex Grigoriev:  I hope you're not serious.  Do you expect this to be done for every application, including the parts of the program that the user is not going to use?  That's just wrong.  What if every program did that?

  29. Ian Boyd says:

    @David Walker: +1

  30. Alex Grigoriev says:


    It can easily be done either by user mode module loader, or by an add-on kernel module using an image load callback (PsSetLoadImageNotifyRoutine) which will work for all applications. And the parts of the program the user won't be using? They will be aged out by a normal page aging if they're not touched for long time. Not a big deal. It's not like there is memory pressure in a typical consumer box these days.


    Even if some exe happens to be fragmented (which is quite unlikely), it's better than loading a page from this exe, a page from another exe (by random demand). If you have multiple processes starting in parallel, those seeks can slow it down dramatically.

    And of course, a reasonable limit on the pre-load size should be used.

    ["It's not like there is memory pressure in a typical consumer box these days." Can I quote you on that the next time somebody complains about how much memory Windows is using? That way, when somebody says, "Why is Windows wasting all this memory and I/O bandwidth loading programs I don't care about?" I can tell them "Alex said it was okay." -Raymond]
  31. Gabe says:

    A quick look shows that a trivial app like Notepad has a couple dozen DLLs, a moderately complex one like IE has over a hundred, and a major one like VS2010 has hundreds.

    Can you imagine what Alex's idea would be do to file servers? It's one thing to say that your local computer has so much RAM and disk bandwidth, but a file server has to share its disk cache, disk bandwidth, and network bandwidth with everybody else using it. And god help you if you're accessing the app over the Internet on a VPN!

  32. Alex Grigoriev says:

    "Can I quote you on that the next time somebody complains about how much memory Windows is using?"

    Yes, Mr Chen, you have my full permission. I don't know if Windows already has that "average physical memory usage" parameter as a part of user experience improvement program telemetry. If it does, check it out. If it doesn't, go around and see what your coworkers' boxes have at the moment.

  33. Alex Grigoriev says:


    From "couple dozen" DLLs only the notepad.exe module is a non-shared file section object. The rest of those DLL's pages are shared by all processes. Also, if you start multiple notepad.exe processes, the exe itself will also be a shared file section.

    One day I'll actually write that driver and post it on the codeproject of like that.

  34. Alex Grigoriev says:


    "And god help you if you're accessing the app over the Internet on a VPN!"

    If your IT hates you so much that they installed your app on the VPN share, ask yourself, what would you rather prefer:

    a) suffer your VPN roundtrip every time another 4KB of your executable needs to be brought in;

    or b) suffer your VPN roundtrip much fewer times while the image is being fully loaded.

    Also, /SWAPRUN:NET linker switch exists for a reason.

    ["My Excel spreadsheet takes 30 minutes to load because stupid Explorer is saturating my slow VPN connection trying to prefect some app I don't even care about." -Raymond]
  35. CGomez says:

    It is too bad if the performance team gave up.  "Startup helpers" do need to just go away and it sucks that I have to go about maintaining my system when I know my mom and dad won't be able to.

  36. Yuhong Bao says:

    " Vista had the feel of a fresh generation starting at Microsoft full of idealistic ideas about how to change the world, Win7 has the feel of an experienced team that understands their limitations."

    Yea, I remember Jim Allchin was involved in Vista, while Steven Sinofsky was involved in Windows 7.

  37. Rick Brewster says:

    I wrote a little command-line utility that you can use to set any process to use "process background mode" (or to disable it, of course). It's very handy, like if you're unzipping a bunch of files and you'd rather have it operate in the background, including its I/O (you could set it to Real Time CPU priority and it probably wouldn't even matter, it's so I/O bound). I'm hesitant to release the source code though because it could probably be used to write a virus. It uses some interesting techniques so it can call SetPriorityClass() within the other process (you can't enable/disable process background mode for another process). Maybe a version 2 would let me set the background mode for any particular UI thread, which would be great for long file operations in Explorer.

  38. xpclient says:

    So boxing CAN be disabled on Vista! On a related note, why does holding down Shift no longer prevent items in the Startup folder from running beginning with Vista? It was very useful for troubleshooting a program that caused problems when it launched at startup.

  39. cheong00 says:

    @Chris: The performance team does leave the switch to you, so you can enable it yourself if you do care.

    @xpclient: Have you tried using "Right Shift" key?

  40. hagenp says:

    Please see "Programmed Politeness" by Kai A. Olsen,

    IEEE Computer, July 2011 (Vol. 44, No. 7) pp. 108,106-107

    'We should require a minimum of politeness. A polite system would ask, "Do you want a shortcut on your desktop, a new menu in Word, or automatic updates?" Then at least we'd feel that we're in control.'

    'It's discourteous to interrupt. […] While some polite programs understand this, many behave like a bull in a china shop. Messages pop up at the most inconvenient time. While we're giving a speech using a presentation program, the computer might tell us that new mail has arrived, offer to help clean the desktop or, worse, require a reboot.'

  41. voo says:

    "or, worse, require a reboot"

    Now I'm sure we all know where that example comes from – and I'm also sure it's heartfelt by basically everyone (though Win7 [Vista?] included the "wait 4 hours" option which means I'm not that likely anymore to kill the service every time something's updated)

Comments are closed.

Skip to main content