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 22.214.171.1245, the 126.96.36.1996 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!]
Every now and then, I have to check in over at NetMarketShare.com, to see what’s happening with the distribution of desktop OSes that the company detects on the Internet. This morning, I couldn’t help but notice that as Windows XP’s marketshare continues to decline — as it should, being now well past end of life — the difference appears to be split between Windows 7 and the Windows 8 versions (namely 8.0 and 8.1, represented separately). Here’s the current snapshot from the site:
As XP’s share drops, Windows 7 and 8 versions appear to be splitting that difference.
[Source: NetMarketShare.com Desktop OS Market Share for 2/9/2015]
With Windows 7 now enjoying clear majority status, it’s clear that Microsoft has to make Windows 10 as compelling as possible. With a GA date of October 26, 2012 for Windows 8, and October 17, 2013 for Windows 8.1, that means we’ve been messing with 8 versions for 27 months (for 8.0, with 15 months for 8.1). The figure certainly puts Microsoft’s desire to move all Windows 8 users up to 8.1, and also helps to explain why the company is offering a “free upgrade” to both Windows 7 and 8.1 users — it’s obviously the best way to capture as much of that substantial majority (66% not counting 8.0, nearly 70% with 8.0 included) of all desktops and move it along to the upcoming flagship version.
Everybody understands the stakes, and Microsoft’s mission has to be crystal clear: to give both personal and business users as many compelling reasons to upgrade as they possibly can. Though Windows 10 still has plenty of rough edges, and still lacks some of its key new functionality, so far MS has done rather better than worse to make a case that the upgrade is at least worth considering. Any by taking the cost out of the equation (at least for the first year past the GA date, whatever that turns out to be) they’ve certainly removed at least one potential sticking point for those inclined to try the new OS to see how they like it.
The next six months or so, as we inch ever closer to Windows 10’s General Availability (GA) date, should be very interesting indeed. A substantial portion of MS’s ongoing business viability hangs in that balance.
In working on a Windows 10 story for SearchEnterpriseDesktop this week, I came to an interesting realization. In Windows 10, MS has finally broken with tradition when it comes to sizing the paging file (you can check this for yourself, no matter what version of Windows you run: by default the paging file resides in the root of the system drive in a file named pagefile.sys). In past versions, up to and including Windows 8.1, MS has always set the size of the paging file equal to the amount of RAM installed on the machine on which it is running. In Windows 10, it seems to set that size at around 20-25% of RAM instead. Here are a couple of illustrative screen shots, with Windows 8.1 on an 8 GB Surface Pro 3 at the left, and Windows 10 on an 8 GB Dell Venue 11 Pro at the right:
Windows 8.1 Surface Pro 3 left, Windows 10 Dell Venue Pro 11 right, 8GB on both machines.
The recommended value for the paging file stays more or less the same at 4 GB, but the default value is dramatically different: exactly 8 GB for the Surface Pro running in Windows 8.1, but only ~1.9 GB for the Venue 11 Pro. Likewise, on my 32 GB desktop running Windows 10, the default paging file is set to a fairly paltry 5 GB with a recommended value of 7.5 GB.
What’s going on here, I believe, is that MS has finally started to take cognizance of machines with adequate (8 GB) or better (16 GB or higher) amounts of installed RAM. Except under heavier load than most end-user devices usually take on, very little paging activity occurs on such machines. A modest paging file of around 2 GB is apparently all that’s needed for less well-endowed machines, and 5 GB proves more than enough on my desktop with 32 GB installed. Tuning and tweaking aficianados have been trimming the paging file this way on Windows versions as far back as XP. I’m glad MS has finally started to do likewise on a more official footing.
Drat! It was with interest and curiosity that I jumped up to the Windows Store (beta) a few minutes ago, hoping to download and install the latest so-called “Universal Office apps for Windows 10″ through the Windows Insider program. Brandon LeBlanc’s “now available” blog post makes this sound like a snap, yet when I started poking around online, no search would produce a link to the promised software items: Word, Excel, PowerPoint, Outlook and OneNote. On a hunch, I followed his link “for more information on the universal Office apps” and found this disclaimer at the head of said posting:
As I write this blog post, the warning remains turned on and the files invisible in the Windows Store (beta). You can do the same as I, and keep checking back yourself, or keep your eyes peeled for the followup item I’ll post when those files become available. It’s hard to live out the dream in the harsh glare of daylight sometimes, but I have to respect MS for letting it all hang out, rather than taking down the announcements, and pretending this all never happened. Stay tuned!
[Early morning: Thursday, 2/5/2015: They’re heeeere! Don’t know when the items were posted yesterday because there’s no time stamp I can see on the Windows Store (beta). Off to check the Office Blogs…a user comment made just before 7 AM CDT this morning leads me to believe that Word, Excel, PowerPoint, Outlook and OneNote finally made their appearance early this morning. If you’re in North America, have at it! Elsewhere in the world, it looks like the wait may continue…]
Here’s what the new Word tile looks like in the Windows Store (beta). TP users can grab it (and the others) for free while the preview is underway.
Amidst the TechNet blogs let loose last weekend, this interesting little item from the Server & Cloud Blog let it be known that, for the first time since the Windows Vista era, the next release of Windows Server (which Paul Thurrott handily calls “Server vNext,” so I will too) will no longer be released in tandem with the next Windows desktop version. That is, though Windows 10 remains on the table for the latter half of 2015 (the smart folks are looking for a September or October release date), Server vNext won’t be headed out the door until sometime later than that.
Be it by design or by happy accident, Server vNext won’t release until 2016, so for now we’ll stick with WinServ 2012 R2.
Here’s what the blog post entitled “Windows Server and System Center roadmap update” has to say on the topic of release timing:
As we continue to advance the development of these products, we plan to release further previews through the remainder of 2015, with the final release in 2016. Our next preview is planned for the spring of 2015.
I agree with the consensus of the Microsoft-watchers who’ve opined on this change to what has been “standard operating procedure” with MS for some time now. Business users in general, and enterprises in particular, tend to follow behind the timeline when investigating, procuring, migrating to, and deploying new Windows Server versions. With Windows 2012 R2 less than two years old at the moment, releasing a new Server version simply lengthens the time span in which that new version might receive consideration and the barest beginnings of due diligence from business IT operations. Thus, there’s no reason to rush Server vNext out the door, and letting it slide until 2016 means that 2012 R2 remains the best target for migration for the many, many, many copies of Windows Server 2003 whose end-of-life data pops on July 14, 2015. In fact, I wouldn’t be surprised if Server vNext were to slip still further, and would wonder if that caused even the barest ripples of concern from its target customers.
I am a great fan of checking in on my disks from time to time, especially my system/boot disk, which goes by C: on my system. The last time I fired up WinDirStat on my production system, my eyes goggled at the sight of a file named Windows.edb thereupon that had waxed enormous and perhaps even malefic, at a whopping 37GB in size. A little quick research and I learned the following:
1. Windows.edb is the index file that Windows Search creates on most modern Windows systems as long as the indexing service is turned on (as mine was, obviously). Visit the Indexing Options in Control Panel to get at its settings and location.
That’s not very much stuff for a 37GB index! [click image for full-size screencap]
2. Some number of users have reported mushrooming or ballooning sizes on this file, particularly in Windows 8 (8 and 8.1) versions. Some of these online postings talk about corrupt indexes growing incontrollably large; I suspect it has more to do with how much stuff you want to index.
3. There are any number of ways to nip this monster at the roots, including turning off the indexing service (which does away with it completely), reducing the maximum amount of disk space the service is allowed to consume (it seems to run in 5% increments, assuming you leave it on the boot/system drive, otherwise it gets free rein over the entire disk), rebuilding the index, or moving the index file to another drive.
Because I like to search my huge trove of email messages in Outlook (1.2 GB of active messages, 10.6 GB of archived ones), I feel compelled to leave the Indexing Service turned on when it comes to my production PC. First thing, I tried re-indexing, but it didn’t seem to make any difference on my machine, even after a quick reboot. But with 1.5 TB of other SSD storage on that machine, I could — and did — easily move the index files to another fast disk without giving up on performance. So that’s the option I ultimately took, relocating it to my F: drive (which is a 256 GB OCZ Vertex 4. and no slouch as disk speed, though not as fast or vast as my 500 GB Samsung 840 EVO system/boot disk).
The upshot of this activity, including the reindexing of my included storage, is a Windows.edb file that is now a mere 517 MB in size. That’s a whole lot better than the 37-plus GB it occupied on the system/boot disk before I transferred it to a different disk.