Every now and then I like to drop into NetMarketShare.com and see what’s up on the Internet with desktop operating systems. Even as they grow increasingly passe and irrelevant, I’m still fascinated to watch those dynamics unfold. However antediluvian this makes me, I’m not ashamed that I still spend my working days staring at a big screen with big PC iron behind it. Forgive me if that’s not where you live, and I hope you’ll indulge this modest preoccupation nonetheless.
Add up Win8 and Win8.1 counts and you get 16.45% which tops XP’s 14.6% share.
[Source:NetMarketShare.com Desktop OS Marketshare by version 6/9/2015]
I guess I missed the cutover date, because the last time I checked the situation was in late April. But now, at least, the end-of-life OS that lasted so very long and ruled so very many desktops has fallen behind the current valid incarnations of Windows. I’m not sure this is cause for celebration anywhere except Redmond. However, it is an important sign that despite the occasional case of “you’ll pry my XP out of my cold, dead hands,” common sense regarding the security and stability of no-longer-supported OSes is beginning to register around the world.
With the official release of Windows 10 due at the end of next month (July 29) it will be even more interesting to see how soon Windows 10 registers on this particular radar (it’s apparently still behind Linux at 1.57%, languishing somewhere in the “Other” category). After it starts to show on the radar, I’m even more curious to learn if Win10 will surpass Win8 before Win7 shuffles off the map. Got that?
Two days ago a strange little Windows flag icon appeared in the notification bar on my Windows 8.1 PCs. A quick mouse-over on the icon produced the text “Get Windows 10.” An equally quick click produced a Window offering early access to the upcoming and already promised free upgrade to the new OS when it becomes available on July 29, as shown here:
You can reserve a copy of Windows 10, which means it will trickle onto your PC before July 29, and become installable that very day.
A fair amount of system spelunking was required to determine that update KB3035583, which appears in my Update History files on or around May 15, is responsible for the appearance of the icon, which remains lodged in your notification bar once it pops up (unless you uninstall that selfsame update, then hide it so it won’t appear again unless you decide to re-enable it later). Among the various articles I found that helped me get this all figured out, Ed Bott’s ZDNet story “Get Windows 10: Microsoft’s biggest software upgrade in history begins today” (posted 6/1/2015) was the most helpful, so I’ll give it a nod and a shout-out here.
Something I haven’t seen mentioned in other coverage is what happens to Windows Update once you do reserve an upgrade. The usual display on the home screen is replaced by a confirmation of your reservation that looks like this:
The confirmation is a novelty at first, but you must now click the “Show all…” link to see if you have any current updates pending .
As far as I can tell, the real upshot of accepting the free upgrade offer is that until it takes effect you must click the “Show all available updates” link to check for pending updates, instead of clicking a link that says “Check for updates.” Don’t ask me why, but I find this mildly irritating. Others are somewhat more galled, with Windows maven Paul Thurrott probably the most outspoken in his reaction. I got a chuckle or two from the story that voices his pique on this subject entitled “Ask Paul: Why Do You Need to Reserve the Windows 10 Upgrade?;” if you read it, perhaps you will, too!
At any rate, this is something that those Windows 7, 8, and 8.1 users who do elect to reserve their upgrade will have to get used to seeing for the next 8 weeks, as the clock ticks its way down to July 29, and users will have the opportunity to make it go away. That upgrade will be around 3GB in size, according to various sources (including the afore-cited articles) so you’ll want to make sure the target drive for your “Downloads” folder/library has sufficient free space to accommodate this item as it trickles its way onto your soon-to-be upgraded PC(s).
If you’ve been reading this blog lately, you’ve seen my recent discovery that duplicate or outmoded drivers in the Windows 10 DriverStore can unnecessarily bulk up the size of the RecoveryImage folder that Windows 10 builds each time an upgrade or clean install is performed (if not, check out the list of links at the end of this post for those pointers). I’ve been noodling away at this lately, and have learned that RecoveryImage also applies to the “Reset this PC” option available in (Settings, Update & Security, Recovery) as well. I sort of figured this might also tie into the Refresh this PC facility familiar to those who’ve worked with various Windows 8 versions (nicely documented in Steven Sinofsky’s “Refresh and reset your PC” post in the Building Windows 8 blog).
Windows 10 does not recognize the recimg.exe (“record image” AFAIK) program at all!
Once I realize that the RecoveryImage files played into the refresh/reset paradigm, I figured that I might be able to delete the bloated version on my desktop test PC (~20GB) as compared to the more svelte version on my Venue 11 Pro tablet (2.38GB). But alas, when I went to build a custom refresh image to replace the reset image created during Windows install for Build 10130, I discovered that recimg.exe was nowhere to be found and thus also unusable for that purpose, as shown in the preceding screen cap. Sigh.
Of course, I can (and still do) continue to rely on image backup through the Windows 10 OS (more easily accessed through the Control Panel widget named available since Build 10122. But it doesn’t offer the incredible convenience of “Refresh your PC” which replaces only OS components and app installs it encompasses, while leaving files, preferences, and settings alone. I sincerely hope MS has merely turned this feature off for the technical preview, and plans to add it back in for RTM and GA releases of Windows 10. I’ve already fired off a couple of urgent Windows Feedback requests in that vein, and remain hopeful that somebody back at MS Galactic HQ is listening, and interested enough to act on this. If it’s gone for good in Win10, I’ll really miss it.
Previous Posts on RecoveryImage
While perusing the postings over at the Windows 10 Forums earlier, I caught an item there entitled “Trimming down Win10TP” that taught me a new way to use the Deployment Image Servicing and Management tool (aka DISM). According to the DISM reference on TechNet, it involves adding a couple of different switches to the by-now-familiar DISM /online /cleanup-image sequence.
Lots of building blocks go into Windows images, so lots of blocks can be (occasionally) cleaned-up.
[Image Credit: Shutterstock 223942717 © IndianSummer]
Those two switches are
1. /StartComponentCleanup, which TechNet explains as intended “to clean up the superseded components and reduce the size of the component store” (WinSXS).
2. /ResetBase, which TechNet explains as intended “to reset the base of superseded components, which can further reduce the component store size.”
Nothing loath, I tried them both! I’ve already cleaned up my driver store, and gotten rid of leftover update detritus and Windows.old installations on all these machines, but I did get from just under 1 GB to 2.1 GB back on the various machines I tried it on, including both Windows 8.1 and 10 (Build 10122) installations. Here’s a short table of results:
|Results of running DISM to clean Component Store (WinSXS)|
|Machine||Brief stats||OS||B4 C: size (GB)||After C: size|
|Dell Venue 11 Pro||i5/8GB RAM/256GB SSD||Win10||36.9||34.8|
|i7-4770K Desktop||i7/32GB RAM/256GB SSD||Win10||69.9||68.3|
|Production desktop||i7/32GB RAM/500GB SSD||Win8.1||98.7||97.9|
|Surface Pro 3||i7/8GB RAM/256GB SSD||Win8.1||60.4||59.9|
I wouldn’t call these earth-shattering space savings, but any time you can save another gig (sometimes more) of space, and tidy up Windows at the same time, I’m inclined to endorse the activity involved. I can also say it took a great deal longer for Windows 8.1 to crank its way through the work involved in this clean-up as compared to Windows 10. On the Win10 PCs it took under two minutes to finish up, on each of the Windows 8.1 PCs it took between 5 and 10 minutes to complete.
There’s a caveat to keep in mind, too: If you run the /ResetBase switch, you will thenceforth be unable to roll back any Windows Updates installed on that PC. This has yet to bite me on the hindquarters, but it is worth remembering, especially in corporate environments, where updates are carefully and cautiously applied anyway.
When I wrote a blog post on May 11 entitled “The Importance of DriverStore Cleanup,” little did I know the post would turn out to be both useful and prophetic. But after investigating the disk layout for the recently-released Build 10122 of Windows 10, I was struck by the difference in size for the RecoveryImage folder on my two test machines. The Dell Venue 11 Pro showed that folder with a size of 2.4 GB, while the same folder for the i7-4770K desktop weighed in at a hefty 20.4 GB instead. “Hmmmmm” I found myself wondering, “could drivers somehow be involved in this difference?”
After the upgrade on the desktop PC, I found only 14 drivers in the DriverStore for Build 10122.
A bit of spelunking into the causes for such a difference revealed that the RecoveryImage folder includes a sub-folder named Drivers. Further spelunking showed me that this folder is 1.7 MB on the Dell, and 18.1 GB on the desktop. That sure seems to suggest that drivers can occupy a LOT of space when the Windows installer uses a current image to generate a recovery image during the installation process, don’t it?
Further investigation shows over 120 sub-folders in the /Drivers/Regular directory tree on the desktop PC, where many (80%) of those folders include duplicate content with anywhere from 2 to 40 other such folders. Alas, the names of the entries therein appear to be auto-generated, and aren’t easy to puzzle out completely, though an inspection of their contents will help point seriously interested investigators at the relevant drivers represented therein. By comparing those names to other images of the same drive and a backup from the DriverBackup utility, I was able to determine that my duplicates came primarily from two sources: the Nvidia graphics card in that PC, and the RealTek audio circuitry on its MSI motherboard.
I take three lessons from this encounter:
1. It’s a good idea to check your driver store before any Windows 10 (or other Windows) upgrade to see how big it has grown. If it’s over 5 GB in size, you’ll want to prune it to reduce the size of the RecoveryImage that Windows 10 builds automatically during the install process.
2. It looks very much as if when Windows supplies drivers via Windows Update, multiple copies of the same driver often wind up in the driver store. Any time you get a driver from WU, it’s probably worth checking the store to see what new inventory has showed up on its shelves, so to speak. The CodePlex RAPR.EXE utility is just what you need for this task.
3. It’s probably a good to best Windows maintenance practice to check your driver store anywhere from 2 to 4 times a year, to eliminate clutter therein. Those who, like me, enjoy fooling with drivers and obsess about keeping them up-to-date will need to check at the higher frequency; those who avoid drivers except under duress can check at the lower frequency.
The urgency of these tasks (especially item 1 above) will be inversely proportional to the size of the boot/system drive where the upgrades occur. Those with tablets that have only 64 or 128 GB of storage will find this effort quite rewarding, but the payback for the work diminishes for those with 500 GB or more in their boot/system volume. I want to keep monitoring the driver store to see if my theories about WU driver delivery have any merit, and I’ve already proven to myself that item 3 is worth doing, if only because I tinker so much with drivers that I tend to load my driver store down pretty heavily over time. YMMV on that last item, as the old acronym goes!
The last couple of days have been exciting in my part of the world, mostly as a consequence of downloading, installing, and absorbing the latest Windows 10 build, 10122, which made its debut two days ago. As per current usual practice, Gabe Aul documented its release at Blogging Windows, in a post entitled “Announcing Windows 10 Insider Preview Build 10122 for PCs.” Dealing with the necessary steps of installation, driver tweaking, and familiarization, 10122 has been something of a “good-news, bad-news” scenario as is not atypical for a late-stage Windows OS beta release.
The Winver output for build 10122 shows an expiration date in October, 2015.
The good news about this release is pretty good indeed, on the whole. Whereas my Dell Venue 11 Pro has experienced install issues with the last three previous builds (a cold restart after the initial reboot screen ultimately proved to be the fix for this issue, but I learned that only after a countless number of other, failed possible workarounds), the Fast Ring “update install” worked fine this time. Ditto for my homebrew i7-4770K desktop test machine (which had no problems with any of those previous installs, either). The weird touchpad insensitivity issue I’ve been wrestling since MS released a new Synaptics driver version last week (version 184.108.40.206, straight from the manufacturer via MS itself) turns out to have been related to sensitivity settings easily addressed using the Mouse Properties widget available in the Control Panel.
Some cleanup following the install of Build 10122 is probably a good idea: I shed 20+GB on the Venue 11 and 19+GB on the desktop following the install, using the “Old Windows installation” checkbox item that makes itself visible in CCleaner (always grab “slim” version), or by clicking the “Clean up system files” button in Disk Cleanup available directly from Windows 10 itself, via drive properties. The old build is big enough to be worth removing if the upgrade works, particularly on tablets or PCs with smaller boot/system storage volumes at their disposal.
The bad news about this release has been documented online as consisting of difficulties installing on Surface Pro 2 and 3 models (see this NeoWin story for a workaround hitherto unknown to me that cleans up drivers and DLLs). Also, users who have non-Nvidia/non-Intel graphics adapters on their test machines have also reported difficulties in using the new build as well, particularly with the new Edge browser (see this NeoWin “known issues” story for more info). I’ve run into something that has popped up in other prior releases — namely, that program entries in the Start menu appear as they should, but don’t respond to mouse clicks or touches by launching the related executable. The workaround is to jump into the Program Files or Program Files (x86) folder hierarchy, then find the executable, and double-click the .exe file to fire it off. OTOH, the high-priced Windows 10 version of Stardock’s former Start8 , now called Start10, continues to work just fine, so perhaps that item isn’t as nugatory as I had previously thought: and perhaps Stardock paid attention to my qvetching and moaning when buying an Object Desktop subscription was the only way to get that software, because you can now download and use a 30-day trial for free, or pay $4.99 to buy only Start10 by itself. Good on you, guys!
I’ve also noticed that Build 10122 will freeze or hang on me for as long as a minute at a time upon occasion, particularly when the CPU load shows “maxed out” 100% utilization on all available threads, but also when jumping into or out of a Remote Desktop session (I often remote into my Win10 test machines from my primary production Windows 8.1 desktop, when writing articles or blog posts, testing various OS features and functions, or fooling around to look for potholes and gotchas). I’ve experienced a couple of blue screens when mucking around with drivers, particularly on the Dell Venue 11 Pro when trying to clear the “Out-of-date” flag on its Bluetooth driver with which DriverAgent presents me on that machine. I did notice that the new build does not apparently draw on up-to-date drivers from its predecessor during the install process, which set me to wondering why that isn’t a primary source for driver data when upgrading from one related Windows OS version to another. On the other hand, the desktop machine upgrade experienced no similar loss of “driver smarts” upon its completion, so it could just be a function of the age of the gear involved: the Dell is less than 6 months old, while the test desktop includes no components less than 18 months old.
On the whole, Build 10122 seems quite solid and is working well for me. I can only hope other beta testers fare as well, and have an equally enjoyable overall experience.
[Note added 5/25: I’ve now discovered that the issue with clicking entries in the Win10 Start menu relates to search index issues. If you visit Indexing Options in Control Panel, then click the Advanced button, then click Rebuild (for Rebuild index), the menus return to normal working order. This fix restored proper behavior on both of my Windows 10 test machines in under a minute (rebuilding the index comes with dire warnings about time required to rebuild them on machines with lots of storage and things to index; warnings notwithstanding, the rebuild process was quick, even on my desktop test PC with over 5 TB of storage). Thanks to this article at WinBeta.org that set me haring off on this trail: “How to: Rebuilding your search index in Windows 1o,” I was able to confirm that menu access issues apparently stem from search stuff.]
I’m using a Dell Venue 11 Pro 7139 as one of my two primary Windows 10 test machines at the moment, and it has become a recent focus for some interesting driver issues. Late last week, MS unleashed a new Synaptics HID TouchPad driver through Windows Update for Windows 10. As soon as I applied the driver, the touchpad stopped working properly (the cursor appears on screen and the touchpad buttons work, but the cursor does not move in response to motions on the touchpad once the system finishes booting up; interestingly it works fine during boot-up, but not afterward, once I establish a log-in). A quick trip to Device Manager, where I go to the driver Properties, Driver tab, and clicking the Roll Back Driver button takes care of the problem, and things go back to normal.
Until MS, or Synaptics, or Dell, fixes the standard driver not working problem on the 7139, I’m going to see this in WU.
Why is this a problem? The reason is that Windows Update in Win10 doesn’t give me the option to hide driver updates, so I can’t tell WU not to apply this update. Every time the system reboots, it checks for updates, applies the new (non-working) Synaptics driver, and bang! there goes my touchpad into “out of order” mode. I can, of course, use an external mouse (I have both Bluetooth and Unifying receiver-based meese at my disposal) or I can zip back into Device Manager and roll back the driver each time WU re-applies it for me. Just for grins, I decided to give Dell Tech Support a call to see if they knew anything I didn’t. Once they found out I was running Windows 10, they punted in Microsoft’s direction and urged me to post my issue to the Windows 10 Insider Hub/Windows Feedback (I have already done so) but were unable to offer any other solutions that might fix the problem once and for all. I spoke to a very nice service technician, and her boss, both of whom agreed that the issue essentially boils down to a lack of means or functions to selectively refuse driver updates from Windows Update in Windows 10. I hope that Microsoft will address this kind of general functionality in the RTM and/or GA releases, perhaps by making such drivers optional (which gives users the ability to refuse them, and hide them to prevent further auto-installation attempts).
[Note added 5/25: Last Friday (May 22), I visited the Synaptics widget in Control Panel, and by increasing the touch sensitivity of the touch panel, I was able to restore it to proper working operation. Something about the driver update caused the settings to be massively decreased, to the point where the touchpad really couldn’t function. Monkeying with those settings, and getting them to an apparently more normal range, allowed me to regain use of the device. Go Figure!]
In my last post here, I observed the number and frequency of updates for Windows 10 arriving via an unthrottled and untrammeled Windows Update. By far, the biggest number of items in the 15-day list concerned Windows Defender, with well over half the individual events resulting in an update of some kind targeting that application. And in fact, Defender was the only application to regularly receive multiple updates in one day, and as many as three updates on some days.
“If at first you don’t succeed…” may be a mantra for overcoming difficulties; that said, it shouldn’t apply to a one-or-more-times-a-day update like that for Windows Defender.
This morning, I discovered that both of my test systems were failing to apply Updates related to Defender. Further investigation revealed that in cases where Windows Update delivers more than one Defender update at the same time (as was the case with Update Versions 1.197.2868.0 and 1.197.2856.0) queued up at the same time), an interesting pattern manifested itself. The first such update would succeed, but the second would fail producing a variety of different error codes along the way. The fix was bone-headed and time-consuming but it worked: although Defender doesn’t require a reboot following its updates (nor should a set of routine security and antimalware additions), a reboot after each update when more than one Defender update is queued up for application was the only way I could get them to apply themselves successfully.
Looking back through my update history through early May on both machines, I see 9 failures on the homebrew PC and 7 failures on the Dell Venu 11 Pro: all of them involve Windows Defender. There are no other update failures in either record, in fact, which suggests to me that Defender is a culprit (or perhaps, a victim) for some kind of update problem. I’ve reported this to MS through the Windows Feedback app, and see that this has been reported many times over the past three months or more. I hope this is something they’ll fix prior to the upcoming RTM release: it’s bad enough that some updates require reboots to complete their successful application; it’s worse when updates that shouldn’t require reboots end up demanding them to work around as -yet-unknown bugs in their normal application process.
[Note added 5/25: Since recording these observations a week ago, I’ve been able to reconfirm them on several occasions for both of my test machines. I’m not sure that constitutes a sufficiently large pool to make a quorum, but from my perspective this now looks less like an interesting anomaly and more like a bug, and I’m reporting it as such to Microsoft through the Windows Feedback widget.]
In the brave new world of Windows 10, updates are no longer batched, but pop up when and as they appear. I decided to take a look at what that means by examining the Update Histories for my two current Windows 10 PCs, in terms of types and frequencies of updates involved. But first, of course, some caveats:
1. Windows 10 is a beta OS so it’s probably more subject to updates in general than a stable production OS would be.
2. Furthermore, Windows 10 is a beta OS that’s in the headlong rush to RTM sometime in the next 2-4 weeks or so, so perhaps what we see is waaaay outside the realm of what’s likely after GA comes and goes.
3. By way of comparison, the last Update Tuesday (May 12) deposited from 40 to 48 updates on my half-dozen or so Windows 8.1 PCs and tablets here at Chez Tittel. That works out to a daily frequency of roughly 1.3 to 1.5 updates, not including Windows Defender.
On Windows 10, Windows Update is handled through the Update & Security widget in the Settings app.
With all this in mind, take a look at what showed up on my two test PCs for the period from May 1 to 15 (I ran Windows Update just after logging into both machines on the 15th, but that day is far from over it still being early morning as I write this blog post):
|Windows 10 Updates May 1-15, 2015|
|Date||Dell Venue 11 Pro||Homebrew i7-4770K|
|5/3||Defender (3)||Defender (3)|
|5/5||Update KB2062095||Update KB3062095|
|5/6||Defender (2)||Defender (2)|
|5/9||Synaptics driver update||Defender|
|Realtek HiDef Audio driver update|
|5/11||Defender (3)||Realtek HiDef Audio driver update|
|Malicious SW Removal Tool||Malicious SW Removal Tool|
|5/14||Feature on Demand for X64 (.NET 3.5)||Feature on Demand for X64 (.NET 3.5)|
|Intel HD Graphics driver||Security Update KB 3051768|
|Security Update KB3066002|
|5/15||Security Update KB 3051768|
|Security Update KB3066002|
The data suggest some interesting take-aways from a new and upcoming Windows Update regime. First, I find it interesting that on some days Windows Defender gets as many as three distinct updates (the rhythm for other endpoint security solutions varies, but this is not unheard of in enterprise environments, either, and is usually separate from the normal controlled update deployment regimes in place). Second, it was fascinating to see device drivers arriving more or less at random: though the Windows qualification scheme is reasonably well-managed for drivers that pass through WU, I can’t imagine enterprises passing them onto clients without prior testing, because driver failures are as likely, if not more likely, to cause blue screens than any other kind of botched update. Third, it was interesting to see the monthly Malicious Software Removal tool show up solo on my Windows 10 machines — in fact, that’s what clued me into checking up for updates on my Windows 8.1 PCs.
The total number of updates for May so far, not including Defender (which I don’t consider to fall under the normal aegis of update management and deployment, anti-malware updates being of a somewhat different nature) was 7 for the Dell, and 6 for the homebrew PC, of which 3 for the Dell and 1 for the homebrew PC were drivers, the rest security and other Windows updates for each machine. This is not an insane number, but their irregular and unpredictable frequency and composition (drivers versus other updates, for example) means that enterprise IT pros will still be collecting them as they show up, passing certain critical items through on a high-priority basis (these might have been identified as “critical out-of-band security updates” in the old, pre-Win10 WU world; it will be interesting to see how they get labelled and handled in the new, post-Win10 WU world), and working and testing the remainder to see which ones make the cut for the next scheduled update deployment time slot. Given what I see here, I don’t believe that the recently-announced Windows Update for Business is going to have much of an impact. It should be interesting to wait and watch to see how it all plays out!
Realizing that yesterday was “Update Tuesday,” I opened up my update history on a production Windows 8.1 PC this morning, and found 40 (!) updates of varying shapes and sizes had been installed thereupon. You can read all about what hit yesterday in the MS Security Bulletin Summary for May 2015 if you like, but you’d best set aside at least half an hour to chew your way through its formidable contents. Suffice it to say here that you’ll find two critical items (MS15-043 and MS15-044) that could permit remote code execution, one that provides a cumulative security update for IE, the other that patches TrueType font driver related issues for Windows, .NET, MS Office, MS Lync, and Silverlight.
The big bulletins for May pose interesting vulnerabilities for IE and “TrueType fonts everywhere.”
Just for grins, I jumped over to my Windows 10 test machines and found a single common update from the herd of Windows 7/8 items had propagated over to the new desktop OS — namely, the usual monthly update to the Windows Malicious Software Removal Tool (KB890830). I’m not sure how many of the other updates released for earlier desktop OSes yesterday had already been applied to Windows 10, nor how many common elements may still be forthcoming. It seems fairly obvious, however, that ongoing streaming of updates instead of batching them up for monthly release will definitely lower the Wow! factor for those who have updates applied automatically when they log in the day after “Patch Tuesday” — err, rather, “Update Tuesday,” as Microsoft’s new nomenclature would have it.
The upcoming delivery of Windows Update for Business (see my May 6 blog post for details) means that enterprise admins will be able to permit some updates to propagate to end-users if they so choose, while holding back others for testing and safety/compatibility checks. My best guess is that enterprises will stick to their current approaches and toolsets, trusting to their own tried-and-true update handling techniques for some time to come, as they work with and try out WU4B to see if it does them any better than their own methods already do. The jury will be out on that question for some time to come, because it all hinges on large-scale, wholesale upgrades to Win10, which often don’t happen until 1-2 years after initial release to the general public. I’m wondering if Win10 will bring enough compelling new features to the party to accelerate things a bit, or if the impending retirement of Windows 7 and the lackluster response to Windows 8 might not prove a more telling impetus in the long run. We’ll see!