Export (0) Print
Expand All
Windows Confidential Waiting for RunOnce
Raymond Chen


CONSIDER AN installation that needs to restart the system in the midst of the process. For example, the program might wish to upgrade a system DLL that is currently in use. You would need to trigger an intervening reboot to get the new DLL file installed, and then after the DLL has been upgraded, you could use it in the next stage of the installation.
The RunOnce key was intended for this sort of scenario—to be used by setup programs to complete their installation after an intervening restart. (This was back in the days when programs were trusted not to screw up.)
Windows® Explorer waits for the RunOnce program to run to completion before it creates the desktop and taskbar. This is because RunOnce operates under the principle that it is for setup programs. The RunOnce program could be changing system configuration data and you wouldn't want the user using a system while it's being reconfigured.
Say, for instance, the RunOnce program is rebasing and binding the files it had just installed—and some of these are part of a shell extension. You certainly don't want the user trying to run the program or activate the extension while its executable is still in the process of being updated.
Another pitfall of the "it's for setup programs" principle is that the RunOnce key is processed only if a user with administrator privileges logs on. Thus, users who aren't administrators wouldn't be able to complete the installation. Besides, if the RunOnce key were executed for non-administrators, it would no longer "run once." In fact, it would create quite a dilemma. How would you say, "OK, I ran that one; don't run it again"? To change this system-global state, you would need administrative privileges. And, obviously, the non-administrative user doesn't have administrative privileges! The program wouldn't be "run once" anymore; instead it would be "run over and over again until an administrator logs on."
  (Click the image for a larger view)
RunOnce, which is intended for finalizing program installation, is visible in Windows setup itself. When you try to install a service pack or upgrade to a newer version of Windows, the setup wizard checks the RunOnce key. If it's not empty, you will get an error message that says, "Hey, you still have some unfinished program installation in progress. Please finish that before you try to upgrade the operating system." This is fair since you wouldn't want to change the operating system right smack in the middle of a program's installation.
The whole design of RunOnce reveals its past. It was hatched in Windows 95, an operating system that did not make a distinction between administrators and non-administrators. Since everybody, in essence, was an administrator on Windows 95, a setup program that used RunOnce could rely on the RunOnce actions being performed upon the next restart.
On more recent Windows operating systems—this is especially true for Windows Vista™—it's possible that nobody with administrator privileges will log on for months at a time. As a result, a program that needs RunOnce to run may find itself in for a long, long wait.
As an aside, I've seen a perpetual RunOnce. It readded itself to the RunOnce key whenever it ran. This clearly goes against the intent of the RunOnce key, since this is no longer a part of the program installation but rather part of the program's normal operation. What's more, this behavior causes Windows setup always to report that there is an install in progress.
Thus, the user can never upgrade the operating system because this one pesky program is forever saying, "I just need to do a few more little things and I'll really be done." The program will not finish installing today, "but surely tomorrow." It's not unlike waiting for Godot—but hopefully without the existential crisis.

Raymond Chen's Web site, The Old New Thing, deals with Windows history and Win32 programming. He is currently working on a book, coincidentally titled The Old New Thing (Addison-Wesley, 2007).
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft