The documentation on the Run and RunOnce keys contains this caution:
An application must not continually recreate entries under
RunOncebecause this will interfere with Windows Setup.
What is this “interfere with Windows Setup” all about?
There’s a clue earlier in that same paragraph:
Applications should use the
RunOncekey only for transient conditions, such as to complete application setup.
The intended purpose of the RunOnce is to allow application installers to do some work after a restart to complete the installation. Therefore, any pending RunOnce entries suggest that an application install is still in progress, and Windows Setup tries not to upgrade a system while an application is in the middle of installing. (After all, who writes an installer that handles the case where the operating system is upgraded mid-install?)
Windows Setup is used not just for installing Windows from scratch, but also for upgrading from one version of Windows to another. And any persistent RunOnce entry will cause Windows Setup to keep asking, “My goodness, can this application finish installing so I can finally start upgrading the OS?”
I feel the idea of using RunOnce to resume a machine-level installation is fragile… OTS elevation sounds like a common scenario and the administrative user might not be the interactive user to log on after a restart.
OTOH, the documented way to enter into RunOnce without disturbing Windows Setup is to call RegisterApplicationRestart and keep running when the update is about to start. (To be precise, it achieves such effect, but RegisterApplicationRestart is not obligated to...
This post seems oddly familiar…
So the next question is, when somebody does make a persistent RunOnce key, what does Windows do about it?
There isn't much it can do. Maybe Windows Update could take note of the registered command line, and at the third of so reboot ignore it. But then, it may break legitimate installers, and it would contribute to what the pundits call "bloat". All those extra features and safety checks shouldn't be necessary, but in practice are needed in an open platform in which a sizable portion of programmers don't follow the rules. If you...
I bet someone will see this article and document it as the Microsoft-approved way of permanently disabling Windows Update. Coming soon to all the shoddy Windows tweaking utilities.
That’s immediately what I thought of doing when I saw this. Windows has in the past made it way too hard to prevent unattended and forced updates, though thank goodness MS has backed off on that enough that it’s less clearly useful than it would have been 3-4 years ago. Still, the idea of returning to completely manual triggering of updates has quite an appeal.
If you run one of those utilities, you have your own penance. I pity those users “smart” enough (note the quotes) to run those “advanced” utilities without understanding what they do. And I hate it when they are one of my users and blame on my applications problems caused by their tools.
The problem isn’t if you decide not to apply security updates in today’s world, but how you do it. If you resort to undocumented features with unknown side effects, you are on your own when something fails. And that’s what most users don’t understand: they used half-baked or undocumented utilities, and then blame Microsoft or other vendors when their software fail. I know because I, as a developer, have suffered it myself.
What’s so hard to understand about a tool that blocks automatic updates from being forced on you?