Banishing 'Get Windows 10' nagware isn't as easy as you think

In spite of what you've read, dodging Microsoft's 'Get Windows X' campaign takes more than two registry changes

Banishing 'Get Windows 10' nagware isn't as easy as you think

If you're running Windows 7 or 8.1 on a computer that isn't attached to a domain, you're no doubt familiar with the "Get Windows 10" ads that try to convince you -- sometimes subtly, sometimes forcefully -- to install Windows 10. Microsoft's intrusive campaign has drawn much well-deserved ire among Windows customers. I think it represents a new low in Microsoft marketing -- right down there in the Scroogled end of the gene pool.

Back in August, Microsoft posted KB 3080351, a discussion of new Group Policy settings and two obscure registry entries -- DisableOSUpgrade and ReservationsAllowed -- that, taken together, are supposed to "prevent Windows 7, Windows 7 for Embedded Systems, Windows 8.1, and Windows Embedded 8.1 Pro clients from upgrading" to Windows 10.

Yesterday, my old friend and erstwhile co-author Ed Bott ran an article on ZDNet that explains how to change two different registry entries -- AllowOSUpgrade and DisableGWX -- to "block Windows 10 upgrades on your business network (and at home, too)."

Both approaches temporarily block the immediate threat of "Get Windows 10" by removing the GWX icon in the Win7 and Win8.1 system tray and by derailing some of the Windows 10 update programs that are currently installed. Neither approach, however, will remove background tasks that bring GWX back, reclaim the 3GB to 6GB of hidden installation files Microsoft may have surreptitiously stored in the $Windows.~BT folder, nor will they keep your system protected if future Microsoft-initiated GWX attacks similar to the old ones occur again.

I've been talking about Microsoft's scummy GWX campaign since April, when researchers first identified KB 3035583 as the source of the attack. As best I can tell, KB 3035583 was modified, fortified, and re-released nine times in 2015. Through it all, Josh Mayfield, the inventor of GWX Control Panel, has kept his program updated to protect against the slings and arrows of outrageous fortune.

I asked Mayfield about the registry edit approach to protecting against GWX. He reminded me that GWX Control Panel (then GWX Stopper) started out last August as an easy way for nonprogrammers (and others afraid of manually editing the Registry) to keep themselves protected. But it's evolved into much more.

Here's what Mayfield told me:

  • The DisableGWX value, which GWX Control Panel has been setting since version 1.0, does one thing, and one thing only: When the scheduled GWX.EXE task runs, it checks for that registry value, and if it's set, GWX.EXE quits itself. That's how you remove the icon from your notification area. but this doesn't do anything about the several background tasks that Microsoft installs along with GWX.EXE.
  • Beginning in version 1.3 of GWX Control Panel, I've included additional logic to help people whose Windows Update control panels get hijacked by Windows 10. Version 1.4 and beyond can even rescue you from an already-initiated unwanted Windows 10 upgrade.
  • As your own visitors (and mine) have confirmed many times over by now, KB3035583 needs to be rehidden each time Microsoft pushes a new version. If you don't want to install it, and if you happen to get more than one version installed, uinstalling it no longer gets rid of the update. (I walk through this in more detail in my troubleshooting guide.) This is why I added the new Delete Windows 10 Programs feature in version 1.7.
  • Beginning about a month ago the KB3035583 update started installing a new background task -- beyond the ones previous versions already installed -- that resets the AllowOSUpgrade value to 1 (enabled) twice a day. Not all users have this background task -- I don't know how Microsoft decides how these things get distributed -- but for those who do, changing this value like [Bott] suggests will only help you for 12 hours or less.

Of course, changing any of the four Registry values won't delete the 3GB to 6GB of files Microsoft surreptitiously installed on many machines in the hidden $Windows.~BT folder. Changing Registry values won't uninstall or hide KB 3035583. Changing the Registry is a good starting point, but it doesn't clean out the crapware underneath.

It's important to realize that nobody has any idea how Microsoft will circumvent these protections in the future. What we do know is that Microsoft has wiggled around the stopgaps in the past -- having new versions of KB 3035583 reset the AllowOSUpgrade value, for example -- and it's clear that Microsoft has no fear of alienating diehard Windows 7 users. As Mayfield said this morning, "I'm still hearing from people who've had their Windows Update control panels hijacked, and Microsoft said they were gonna stop that nonsense months ago. Windows is a moving target, and Microsoft can and do change their policies/tactics at will."

Last October, Windows honcho Terry Myerson promised: "You can specify that you no longer want to receive notifications of the Windows 10 upgrade through the Windows 7 or Windows 8.1 settings pages."

I haven't seen anything in any Win 7 or 8.1 settings pages that allow you to just say no to the Windows 10 upgrade process. If you've seen something, please hit me in the comments.

As Mayfield says, "[GWX Control Panel is] based on both my first-hand experience and reports I've received from hundreds of users (most of whom are IT consultants and tech support professionals). The Windows 10 push is much bigger than what those Registry values cover. Period."

If you want to keep Microsoft from nagging you about Windows 10, you can change a couple of Registry values and hope that history doesn't repeat itself. Or you can hit it with a full barrage. Neither comes with a guarantee that Microsoft will play fair as it pushes the Win10 juggernaut. But I know which one I'll choose.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies