What with running two Win10 test machines — a desktop and tablet/convertible — I’ve been banging up against the limits of this new software from time to time, and have had to refurbish some troubleshooting skills. This was called to mind yesterday by two very nice bits of information I came across, each of which related to at least one of those gotchas that helped me formulated to the title for today’s blog post.
When it comes to shooting trouble nothing beats good technique, except perhaps good automated tools.
Those two items are:
1. Sergey Tkachenko runs a small but potent Website called WinAero.com where he comments on Windows stuff, and publishes a wide variety of useful little Windows utilities and tools. Several of them, such as the Winaero WEI (Windows Experience Index, which brings the quick-n-dirty performance ranking back to Win 8 and 10 versions), have showed up in my own postings to this very blog. This particular item popped up a couple of days ago and is entitled “Change network location type (Public or Private) in Windows 10.” Apparently Sergey and I have often experienced the same problem, which is that after updates, between reboots, or upon waking from sleep Win10 often resets the network type from “Private” to “Public.” As he notes in this June 11 post, there actually is a way to get to this setting from the Network and Sharing Center. But it does require a reboot. I’ve found what I think is a simpler, if less direct method: I simply open Homegroup, which tells me that the network is the wrong type to participate. Click Fix and it resets the network type to Private, after which I can again use RDP to remote into my test machines.
2. I subscribe to the great and informative Windows Secrets Newsletter for the princely sum of $15 a year. I like it so much, in fact, that I have it set up to bill my credit card annually for ongoing coverage. Longtime Windows maven Fred Langa has a piece in this week’s offering, also posted 6/11, entitled Free first aid for a wide range of Windows ills, wherein he reminded me of the many windows FixIt tools available and taught me about Microsoft’s Support Diagnostics Program (SDP) and the Microsoft Automated Troubleshooting Server (MATS), two programs about which I’d heard bits and pieces but had never bothered to dig into more deeply than hearsay would allow. What I discovered was a treasure trove of tools for detecting Windows ills, often with fixes to match, that address all kinds of problems from the merely persnickety to the downright catastrophic. Just for grins, I ran MATS on my production PC, and it seemed to chunk through its lengthy laundry list of checks without difficulty.
Always nice to find techniques for troubleshooting, but even better to gain access to good automated tools for that purpose. Thanks, guys!
When the Win10 flag showed up on my Windows 8.1 machines, perforce I signed up for the upgrade, knowing that I must track the latest and greatest of Windows OSes no matter what. I’ve read various opinions on Microsoft’s early upgrade offer that vary all the from clever marketing ploy to a trick from the infernal master and found myself somewhere in the middle of that spectrum. But when a congratulatory e-mail showed up in my inbox yesterday, I found myself leaning more in the former direction (clever marketing) rather than the latter (devilish trick):
If you hand over an email address when you register for the upgrade, you’ll get this e-mail, too.
Having now had a bit more time to think about what’s going on here, I’m still inclined to think of it as a clever marketing ploy and not the Devil’s handiwork. Here’s why: MS is getting an early gauge of interest in Windows 10, and grabbing an early opportunity to reduce its support burden by lowering the number of users of older products and concentrating them (or trying to, anyway) on their latest and greatest desktop offering. At the same time, MS can reduce the first- and early-days load on the Akamai servers that usually provide the downloads (and this one is bound to be 2-3 GB in size) by trickling out those big files starting days before July 29 when the real onslaught begins.
Upon further reflection I do have to say it appears to be a very clever marketing and business ploy because it helps get the word out, keeps the new release in the public’s eye (or on their notification bar, at least), and helps the company make best use of bandwidth and server resources. Very interesting, and quite possibly also, a nice piece of work.
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.]