I went to print a phone card for my wife this morning, and wound up lost for a while in the “Hall of Mirrors” section of the Windows OS. In this case, I knew I needed to print to the Dell color printer upstairs (it helps to show color on the phone card for higher visibility access to its all important access numbers and codes), but I found myself unable to access that printer from my Windows 10 test machine. After resolving some network issues (a reset of the home network with the introduction of a new high-speed boundary device from Time Warner was the culprit there) I found myself looking at a half-dozen relic printer listings from PCs no longer on the network that I knew I would never need again. So of course, I set about learning how to remove them from the Windows 10 test machine.
On an AD network, this kind of thing is relatively easily handled with GPOs and scripts that will clean out stale devices. My home network doesn’t have AD, so I had to do it the old-fashioned way — namely by pruning the registry on the machine in question. I’m assuming that enough readers here have to deal with BYOD or end-user devices that may include registry entries outside the AD umbrella, so hopefully what I just learned will be of some benefit.
I’d much rather see two items I can actually pick, than 6 of which I can only pick two.
I wound up searching the registry for machine names for those PCs that proferred print drivers to the network, but were no longer present on the network. And lo and behold, they show in the HKCR\Local Settings\Printers\Roamed key therein, one entry per such printer that starts with the machine name for the PC that’s no longer in service or available. In my particular case, this included machine names for some PCs I’ve either sold (the Fujitsu Q704 hybrid tablet), loaned to family members (the Dell XPS12, loaned to my sister while she was recovering from a hip replacement, still not recovered), or whose OSes have been upgraded (my production PC, now running Windows 8.1, and my son’s AIO, now ditto). The upshot of all this is that now when I go into the Add Printer window on the test machine, I see only entries for printer (and shared printers) actually available on the network right now, instead of devices going back as far as the purview of the Windows registry on the machine in use (which can go back quite a ways, as some of these machines have been upgraded from Windows 7 to 8 to 8.1 and even through several preview versions of Windows 10, as on the test machine in question).
I’m inclined to close this blog post with a reminder that deleting keys from the registry is irreversible unless you back them up before you remove them, so the safest course of action is always to back the whole registry up before you start messing with it. Should worst come to worst, you can simply replace the damaged results of your bungled editing efforts with the presumably pristine version you captured before you starting messing around. In my case, I wasn’t worried, because I was only messing with entries for machines no longer present on the network. Even so, I still backed up anyway. You should do likewise.
Back in 2011, I blogged here about a program named DriverStore Explorer. Aka RAPR, this is a CodePlex project that when run in administrative mode enables users to see all drivers in the Windows DriverStore and to selectively delete those that aren’t in active use at the moment (find that blog at “Check Out DriverStore Explorer” which posted nearly 3.5 years ago). This weekend, in prepping a couple of machines to take on the road, I was pleasantly surprised to get back 1.5 to 2.5 GB of disk space on those systems’ boot drives simply by excising old drivers no longer in use. I also discovered two valuable techniques to make better use of the program for this task (cleaning up outdated or unused drivers), which I’ll describe in the following paragraphs.
Sorting the entries by the ‘Driver Class’ column lets you see all instances of the same driver together in groups. [Click Image for full-size version]
As the foregoing caption describes, sorting the entries in RAPR on the Driver Class column groups drivers together by type, as shown for example in the preceding screenshot by multiple instances of the NVIDIA Display Adapters (2) and Microsoft Human Interface Devices (4). By doing this on the machines I was cleaning up, I could see all the drivers for each device grouped together, and identify those with older dates likely (but not always) to no longer be in use. Thus, this describes the first technique for driver cleanup: use this mechanism to group drivers together so you can easily compare their version numbers and associated dates. It also leads directly into the second technique.
That second technique is probably best described as “try deleting the oldest drivers (or lowest version numbers) first, one at a time; do likewise for multiple instances of the same driver.” Windows does install multiple instances of identical drivers when a system hosts multiple instances of the devices to which they’re associated. That’s why you see four instances of the HID drivers in the preceding screenshot (I like to leave the penultimate graphics driver version on my systems, as well as the most current one, to enable Device Manager to roll back to that penultimate version if the most current one leads to system instability, as it sometimes does): the system that produced this screenshot has four such devices installed, all of which use the same driver. Here’s the nice feature of RAPR that keeps you out of trouble with experimental deletion attempts: if you try to delete a driver that’s in active use, it will block the initial attempt (you can still use the “Force Deletion” checkbox to remove it anyway, but I don’t recommend that unless you’ve got another and hopefully better driver ready to replace that item on hand). That’s why deleting drivers one at a time, slow and frustrating as it may seem, is the best approach to clean-up: it quickly lets you determine which drivers are in use, and focus on removing those that are sitting idle.
As I said in the lead-in paragraph, space savings that result can be helpful, especially on tablets or laptops with limited storage. On a 256 GB SSD (or larger drive), saving 1.5 to 2.5 GB or more isn’t terribly dramatic. Though still useful, this technique is best applied to systems whose system/boot drives are 128 GB or less, where saving space for unused drivers means making valuable room for data, paging, and other key elements of storage. Try out my driver two-step: I think most power users and admins can’t help but be tickled with the results. RAPR also works on every version of Windows I’ve tried since 2011, which means Vista, 7, 8, 8.1 and 10 on the desktop, and 2003, 2008, and 2012 on the server side (including R2 versions).
Anybody who’s read this blog for any length of time has witnessed me repeatedly and enthusiastically recommending Stardock’s great product, Start8, as a Windows start menu add-in/replacement for Microsoft’s current flagship OS. In fact, I run it on every single one of my Windows 8 machines, which means I’ve purchased six copies of the program, according to the number of keys I see registered in my account at the Stardock website. The program normally goes for $5, but if you look around online you can usually find coupons for 20% off or thereabouts, which brings the price down to an eminently worthwhile $4 a pop.
With a version number of 0.5, you *know* it’s an early beta release!
That’s why my ears perked up earlier this week when I read announcements on the usual Windows 10 news sources (for me that means Thurrott.com, Neowin.net, and WinBeta.org) that Stardock was releasing a beta version of their menu replacement for Windows 10, to be called Start10. Very quickly after digging in, however, I discovered an expensive catch: you must either buy a standalone license for Stardock’s bundle product called Object Desktop Manager ($50 new, $35 upgrade from other Stardock products, annual renewal fees apply) or a subscription to same ($10 for the first month, $4 a month thereafter, continues until you manually turn it off) to gain access to this software.
I’ve got to say that while Start10 appears to be a worthy successor to the excellent Start8 product, I’m more than slightly miffed at the tactics that Stardock is using to capitalize on interest in Start 10, to the tune of nearly ten times the cost for the product by itself (for the upgrade price, 12-plus times for those who might have to buy a new Object Desktop Manager license). Ditto for “encouraging” buyers to opt into a recurring subscription license that requires a manual opt-out to escape from. Sigh.
Having bitten the bullet and coughed up $35 to see what’s what with the new Start10 beta I can say it’s a lot more like Start8 (and the Windows 7 Start menu environment it was modeled after) than the native Start button environment on Windows 10. It looks and handles pretty much the same as previous versions, and brings with it the virtues of comfort and familiarity that convey from the previous version, and with my own personal Windows history back to the XP, Vista, and Windows 7 environments with which it establishes strong continuity. But I’ve learned to navigate in Windows 10 pretty darn well without Start10, and for now, I’m installing the beta only on one of my test rigs (the Dell Venue 11 Pro 7130).
While the program is nice, and works as expected, I can’t help but think it’s at least questionable, if not an outright rip-off, to use the desire from Windows-heads like me to check out a new release of a well-crafted and highly usable Windows 8 program for Windows 10 to extract significantly more money from its would-be users than they have to pay for the Windows 8 equivalent (and will probably have to pay for the standalone version, if history is any guide, after Windows 10 goes into public release). Stardock management: are you reading this blog post? Does this opinion swing any weight with you? If so, please make the beta available for free, or let people pay $4 to try it out, instead of sticking it to them to the tune of significantly more. I always thought Stardock was a standup outfit that built great products, but this whole experience has left a bad taste in my mouth. Please fix this, and restore my enthusiasm and respect for your otherwise great products, or at least give early adopters a good reason to pay extra to opt into the beta version early. As things stand, I just don’t get it right now. And until the price gets real, perhaps you shouldn’t get Start10, either!
This weekend, I installed a HighPoint RocketU 1144C on my production PC, in search of solutions to a USB 3 drive access problem. There’s a PLX PCIe 8609 DMA controller on that board, apparently associated with managing the PCI channels that this 4x device uses. And although the drivers shipped with the board got it up and running no problem, the PLX chipset showed up as an known “Base System Device” in my Device Manager after the install until I went out and found the necessary driver on the HighPoint site, courtesy of some partial pointers on the ASUS Republic Of Gamers (ROG) website that alluded to this issue along with the tell-tale Device ID string PCI\VEN_10B5&DEV_8609 &SUBSYS_860910B5&REV_BA.
The first time I installed the driver I got an error message from Windows saying it was a known problem, with the yellow warning sign in Device Manager showing it as disabled. If only I’d rebooted, I would have seen this message go away. Instead I kept searching for a newer driver, which proved my undoing. Norton Internet Security 2015 (NIS) didn’t squawk when I downloaded a file named Plx_pcie_8609_dma _controller_driver.zip, though it most assuredly should have. The sole contents of said ZIP file is the file eponymously named Plx_pcie_8609_dma _controller_driver.exe, and NIS didn’t squawk about it either while I installed it, though strange things started happening immediately thereafter.
Here’s the litany: In IE, Firefox and Chrome (those malefactors are thorough, I have to give them that) I started getting warning about SSL certificates with no revocation data (never a good sign) and advertising started popping up all over the place. After reading about Lenovo’s recent Superfish debacle quite a bit recently, I had a pretty good idea that an SSL hijack had occurred, along with some serious adware injections. A full system scan from Norton turned up nothing amiss, though I found mysterious new directories in my Program Files (x86) directory, new startup processes linked to same, and the usual symptoms of a successful malware exploit on my machine. Sigh. A quick return to my most recent Restore Point (dated yesterday) took care of all the symptoms, after which I was able to delete the unwanted folders that had popped up on my system/boot drive, and the files that lived in them.
I’m usually pretty careful about where I download files from, and NIS usually steers me clear of stuff I don’t really want on my PC anyway. But for some reason, this dastardly download got past my own common sense (the first line of defense) and my security suite (my second line) to deposit unwanted software of a decidedly unfriendly sort on my machine. I realize that adware isn’t necessarily malware, but if it represents something I don’t want on my machine, and makes it difficult for me to remove itself from the runtime environment, it’s bad enough for me to make it go away, no matter what lengths I must go to see it gone. And so it was with this stuff, whatever it happened to be.
The moral of the story is: don’t let your desires to find the right driver or other piece of software overrule your common-sense understanding of what’s safe to access online. I’m not sure why NIS didn’t squawk about the website from whence the download came — subsequent reputation research shows it questionable at best, and downright nasty at worst — but I should have known from the URL that the website was suspect. Please learn from my recent mistake, and stick to known good driver resources, like vendor sites, the driver download and tools suppliers (DriverAgent, Driver Detective, RadarSync, and so forth), and that great French national treasure, Station Drivers, instead. Now that it’s all fixed, all I can say is “Ouch!”
By and large, I’ve got to give Dell credit for a winning solution in their 11″ Venue Pro tablet with detachable keyboard. It’s on par, features and power-wise with equivalent Surface Pro 3 models but the Broadwell Mobile processor makes the unit run at least 20° C cooler than the SP3 does at similar load levels. In fact, even at full load the unit’s operating temperature never seems to exceed 41° C (as compared to typical operating temperatures for the SP3 in the high fifties to mid-sixties °C, depending on overall system load). And with no fan, there’s no need to worry about fan noise either (the SP3 isn’t bad, but I sometimes find myself wondering who’s running a leaf blower at this time of year, when I realize that it’s the high-pitched whine of that unit’s fan in full swing).
Compact tablet with replaceable battery good; plug in clamshell with extra battery better!
But since I’ve installed Windows 10 on this unit — it mostly runs quite nicely, BTW, and switches seamlessly between tablet mode and desktop mode, and undocks from the keyboard without a hiccup — I’ve had a couple of interesting problems with this unit. First and foremost, every time it goes to sleep or gets rebooted, I lose my network connection and have to go into Settings to re-establish same manually (even when instructed to reconnect automatically, it does not do so). Second, and somewhat more irritating, when the machine is left to its own device management, the Windows Driver Foundation — User Mode Driver (WUDFHost.exe) constantly consumes 24-27% of the unit’s CPU power. If I end that task, I can reclaim the CPU cycles, but I lose the Intel HID Sensor collection that includes the tablet’s orientation (gyroscope) sensor and probably the Near Field Communications (NFC) sensor as well (though I have no NFC devices, and thus no way to check its presence or absence after disabling that sensor collection).
This is mildly irritating, to say the least, but not an uncommon set of circumstances when beta-testing a new OS on a new hardware platform. Dell supports Windows 7 and 8.* versions for the Venue 11 Pro, but doesn’t officially support Windows 10 on that platform yet (though I’m sure they’re dealing with the same issues themselves, and no doubt working on a fix, though it’s unlikely to result in driver changes until the OS goes into RTM or GA status later this year). To misquote Ry Cooder in this connection, I observe “Well, that’s the way it goes, down in Hollywood…” These are the kinds of things one learns to work around, when working one’s way into a new OS. Sigh.
In reading over an interesting article on Ars Technica this morning, I realized that many online sources (including the otherwise redoubtable Ars) that describe how to reinstall Windows to eliminate OEM-provided “bundleware” tend to leave managing Windows drivers as an exercise for the IT pro or Windows enthusiast tasked with that job. There’s no need to jump through numerous hoops to take a snapshot of installed drivers prior to a Windows reinstall, though. Instead, I’d recommend any of a number of good utilities that will happily collect this information for you to make it available to Device Manager once you’re far enough along in the reinstall process to use the “Update driver” option on a driver-by-driver basis within that framework.
Thus, for example, eSupport’s for-a-fee DriverAgent tool includes a built-in driver backup facility, as do most other such driver management tools. Those who don’t wish to lay out any cash to back up their drivers can (and probably should) turn to the SourceForge utility named DriverBackup! instead. Either way, you can easily harvest all of your drivers with little muss or fuss involved. For easiest access, in fact, grab a USB Flash Drive and back the drivers up on that device. Then, you can point to those drivers as and when they might be needed: this can be incredibly handy in the occasional odd situation where the Windows OS installer needs a driver during the installation process, as might for example be the case on a PC that boots from a RAID drive. Ditto for post-install when looking for drivers to update or add from inside Device Manager.
As shown above, the user interface for DriverBackup! makes it trivial to grab and save a snapshot of the entire collection, which may then be used later on to restore drivers in need of update or installation once the clean (re)install is over and done with. Or, if you prefer, you can work inside Device Manager, and simply point to the destination folder for the backup on your UFD, after which Device Manager will ferret out the driver it needs for the job.
Slimware Utilities is the company behind RecImg Manager, a program that can capture and restore modern-format Windows images. This is the same kind of image that Windows 8 or 10 uses, when you elect to “refresh” a PC using the Recovery tools from the Update & Recovery option within Settings.
By default, refresh rolls you back to initial set-up; use RecImg Manager to capture a current image to use instead.
RecImg Manager will capture a snapshot of your current Windows installation, including all current software and drivers installed. In the event that you need to refresh a system, that’s most likely what you’ll want to refresh it to, rather than to its plain vanilla state immediately following its initial delivery for deployment or to a users. Normally, that’s followed by installation of various applications, tools, utilities, and current drivers — all of which might become lost if the image you use to refresh that PC doesn’t include such stuff. That’s why I’m in the habit of capturing such an image weekly, and after each time I apply Windows updates, new drivers, or other software I might wish to use again. If you keep up this regimen, you can point the “Refresh your PC” option to the most current of the RecImg Manager images available, and get all this stuff back once the refresh is completed.
Using RecImg Manager doesn’t get you off the hook for other regular backups, however: I have encountered a few situations in which the current Windows installation becomes sufficiently damaged that it won’t successfully refresh (or it might be unable to find your refresh images, which are stored in a folder named RecImg Snapshots on a drive of your choosing, and includes the all-important CustomRefresh.wim file that acts as the source for the OS refresh activity). That’s why I also capture a “System Image Backup” (now available inside the File History control panel widget) for each of my systems at least once a week also, if not more frequently. You should probably consider similar strategies as well.
Sergey Tkachenko, who’s the mind behind the excellent Winaero.com site and blog, struck paydirt recently with his post on working with the Alt+Tab key combo in modern Windows versions (I’ve tried his tricks on both Windows 10 and Windows 8.1 and they work nicely, not so sure about Windows 7 any more now that I don’t have a running installation at my disposal). He also points out his own free utility, called Alt Tab Tuner VIII (which works for both Windows 8 and 10 versions, version number notwithstanding) and lets users tweak and tune how Windows behaves when you strike Alt + Tab in numerous interesting and helpful ways.
The key combos to try out are as follows:
1. Ctrl + Alt + Tab leaves the Alt+Tab select box onscreen even after you release the keys. It sticks around until you make a selection, then hit the Enter key to switch the display to that view.
From left to right: IE, Chrome, Outlook alarm, Outlook UI, Desktop.
2. First, press and hold the left-hand Alt key. Second, press and release the right-hand Alt key. Third, use the Tab key to toggle among the switcheroo options that appear. This presents an old-fashioned Alt + Tab select box that Sergey sez goes all the way back to Windows 98. It does show modern icons, though, on Windows 8 and 10 versions. Don’t let go of the Tab key until you pick the icon you want to bring to the foreground, or you’ll find yourself somewhere you don’t want to be!
Check it out, and have fun playing around.
I’ve been a big fan of the Intel Driver Update Utility for years, especially since the company published the standalone program version (v2.0) in mid-2014. With the introduction of the 10.x.x.x versions of their chipset utility, most of a user’s ability to extract and install drivers manually, one-at-a-time, has been stripped away, though. And recently, when trying to install the latest chipset version on my production desktop (10.0.0.24), I found myself at odds with the aforementioned Driver Update Utility. In this case, a single composite screenshot tells the story (you may want to click on the reduced size image to see the full-size version to read what’s in the warning box positioned above the Driver Update Utility window, though):
Notice that even though the background utility says I’m running 184.108.40.2065, the 220.127.116.116 installer says I’m running 10.0.0.24.
When I run the 10.0.0.24 installer, it produces no error messages, and a check of the log files shows a successful installation (no error messages are thrown during its operation, and it signals a successful completion at the very end). Why then, does the Intel Driver Update Utility insist that I’m running a version of the chipset software that I’ve updated through various 9.x.x.x versions, and then from 10.0.0.13 to the current 10.0.0.24 version? I’m not sure, but I am send a friend of mine who works for Intel as a software engineer in the group that builds these utilities a link to this blog post, along with the log files from yesterday’s 10.0.0.24 install. Maybe they’ll be able to figure something out. In the meantime, be warned that the Driver Update Utility is not always 100% accurate when detecting and reporting on current installed chipset software versions. I’m guessing the utility looks at the version of some particular item in the driver collection, and that it’s not necessarily in synch with the current chipset software version that’s actually installed. Let’s hope it’s a quick and easy fix: I like this tool, and I’d like to keep using it with confidence.
Oho! Yesterday was “Update Tuesday,” the second Tuesday of the month. Tuning into Windows Update just after lunch I noticed a big batch of updates (38 on Windows 8.1 systems with MS Office 2013 installed, 18-20 on those without a standalone version of Office onboard, including my son’s PC which has Office 365, courtesy of the Round Rock Independent School district). As is my usual practice, I fired off the updates on my various desktops, notebooks, and tablets. About 20 minutes later, I noticed that all machines were hanging on the same update — namely KB 3001652 “Update rollup for Visual Studio 2010 Tools for Office Runtime.” To make things more interesting, the “Stop installation” option in Windows Update didn’t respond to being clicked, and when I tried to reboot out of the hang, the update kept trying to install itself — and hanging — before it would permit a graceful shutdown to occur. In other words, it “zombified” my system, with the only way out of the hang a forced reboot/cold start.
With no other way out of the hang, a forced restart appeared as the only solution, until I identified the process name for the culprit.
I finally figured out how to get out of the hung state to get to a restart (which, except for my Surface Pro 3, didn’t cause any problems on restart or shutdown thereafter; on the SP3 I had to reboot 3 or 4 times after the initial forced restart before it stopped issuing a Blue Screen upon shutdown with error message “Pages locked in memory…”): the installer for this particular update is named vstor_redist.exe and upon identifying it in Task Manager’s “Details” view, I was able to right-click that entry and use “End task” to kill the hung installer for the errant update. That got rid of the restart problems, and restarting the update process with the problem item unchecked let Windows Update do its thing without unwanted delay.
About two hours after the initial batch of updates issued forth from Microsoft, KB 3001652 was pulled from the servers. After that, the other machines I didn’t rush to update went through the download and installation process without a hitch. I was early to catch this item, though, because not even Windows 8 Forums reported on it until I was already in troubleshooting mode (see Update failure – KB3001652 for more coverage and item-by-item reporting). I actually ended up calling in a Support Incident on this problem, just because I wanted to see how MS would handle it. They told me I had to wait 24 hours to get a response because of the nature of the problem (a brand-new update with no solid history or troubleshooting info yet documented) and because of my current MSDN account status (just activated yesterday for a new 3 year subscription, thanks to the great folks at Software Wholesale International, who saved me at least $1,000 on that cost as compared to what MS charges).
It will be interesting to see if and when this item will re-issue through Windows Update. In the meantime, methinks MS has some work to do to fix this particular fix. If you find it proffered to you any time soon, my advice is “Proceed with caution!”
[Note added 2/12/2015: KB3001652 is back up on Windows Update. This time around it installs on Windows 8.1 systems — all six of them, in my case — without any hitches or glitches. Guess MS must have found and fixed the hang-up in the meantime. You may now proceed to install this puppy, but I’m not sure that you should also abandon caution in the process!]