Later last Friday (12/4), MS fired off KB3122947, labeled “Update for Windows 10 Version 1511 for x64-based Systems.” At first, I thought nothing of it, after getting it installed on a handful of PCs. But when I tried to update my Surface Pro 3, I encountered a repeated failure condition with error code 0x80070643. When I went looking for the manual update file to download and install by hand, I couldn’t find one (still can’t, in fact) but I did find something even more interesting. It turns out that the Deployment Image Servicing and Management command, aka DISM, also includes an add-package switch that lets admins target updates and install them directly and immediately. Here’s the fix, as it applied to this update file:
Turns out that if you know where to look for failed update install files, you can turn DISM loose on that task.
As the foregoing screen capture goes, the general syntax looks like this:
dism /online /add-package
The trick, of course is in finding the package file, which is relatively easy to do because it includes the KB article designator — KB3122947 in this case — as part of the filename. I used my search tool of choice (Search Everything) but you can simply use the built-in Windows Search facility through File Explorer if you prefer. Other than making sure to get the packagepath syntax (and content) correct, the process couldn’t be simpler. And because WU generally leaves the files it downloads in the SoftwareDistribution folder hierarchy even if installation fails, there’s no need to download a manual installer for balky updates ever again.
Sweet! I’m starting to think of DISM as something of a “Swiss Army Knife” of Windows maintenance and upkeep. Sooner or later, I’m going to have to pull all of the individual bits and pieces I’ve been documenting here in the blog into a more comprehensive reference. I just wish MS offered something more than a man-page type of reference for this increasingly excellent tool.
Every now and then, things happen in Windows-world that defy common sense, not to mention best practices. I’ve become a somewhat obsessive user of the system file checker (SFC) and the deployment image servicing and management (DISM) commands lately checking on the health and well-being of my system files (SFC) and image/component store (DISM). DISM works as sort of a backstop for SFC, so that when you can’t manually repair corruption or issues that the file checker detects, you can use the /restorehealth option in DISM to repair those files programmatically — at least, most of the time.
In the wake of a recent Nvidia driver update (395.06) and the latest Cumulative Update to Windows 10 (KB3116908, for x64 systems, which takes the Build number up to 10586.17) these two tools have fallen out of step with one another. Here’s a screenshot from one of my Nvidia-equipped PCs that shows the mismatch (I understand some AMD/Radeon drivers have also occasionally fallen prey to the same kind of thing, too):
Ordinarily, if one finds problems, so does the other; not this time!
In reading up on this issue (links to two good discussions, one at TenForums.com, the other at the Nvidia forums are also worth following) I learned that there’s a difference between the vendor version of opencl.dll that Nvidia wants to use (which ranges between 110 and 120KB in size, depending on recent driver versions) and the generic version of the same file that Microsoft provides (about 30K in size, which MS seems to insist on finding at the moment, even though best practice is to defer to manufacturer driver versions for that maker’s own hardware). If you look at the CBS log file that SFC produces, you’ll quickly see that all of its “corruption” complaints come from that single file in multiple locations, because it doesn’t match what MS expects to find. Yet DISM reports the component store is OK, as the screencap shows.
I’m not sure exactly what to do next, and have to agree with a recent poster to TenForums that the best strategy is to “…wait for MS to fix their problem.” In other words, “If it ain’t broke, don’t fix it” has to be the watchword here!
A recent set of data from the US Government’s Digital Analytics Program (aka DAP) shows that most of Windows 10’s growth appears to come from users switching from Windows XP or Windows 7 to the new flagship desktop OS. In a recent story entitled “Windows 7 and XP are the biggest losers with Windows 10’s rapid growth…,” Paul Hill at Neowin.net posted a very nice table of figures extracted from their downloadable source data to show what’s been up among the population of users visiting or using US Government websites sites over the course of 2015:
Numerically, Win10 is the biggest gainer for November, and Win7&XP are the biggest losers.
[Figure comes from afore-cited Neowin 11/29/15 story.]
Given that XP is only workable for those paying exorbitant post-end-of-life contract fees to MS (of which there is no shortage within some government branches and agencies), XP is clearly fading to black. That said, it continues to amaze me that an OS that hit end of life more than 18 months ago still registers so strongly on the radar. Please note that the percentages represent market share shifts, not percentages of the category/OS counts, so that you’d interpret the table to mean that Windows 7 is down by 7.0% ytd, and XP down by 2.1% ditto, while Windows 10 has gone from 0 to 12.4% over the same time period. Thus, the other items shown on the table account for the remaining 3.3% necessary to account of Windows 10’s growth.
By way of comparison, take a look at my 11/27 blog, which reviews recent desktop OS marketshare figures from NetMarketShare.com (NMS). There are differences across the board from these two different sample populations:
- Windows 7 stands at 55.71% on NMS, and 64.2% on DAP.
- Windows XP stands at 11.68% on NMS, and only 3.7% on DAP.
- Windows 8.1 stands at 10.68% on NMS, and 15.7% on DAP.
- Windows 10 is at 7.94% on NMS, but 12.4% on DAP.
I could go on, but you get the idea: the breakdown of desktop OS still varies quite a bit, according to the composition of the sample population from which its drawn. But the foregoing table shows pretty clearly that other Windows OSes are trending downward (except perhaps for Windows 8.1), while Windows 10 is trending strongly upward. I still don’t see enough momentum to get Windows 10 to the 1 Billion user mark by 2017 as per Microsoft’s stated wish, but it could be a closer call than I had originally thought. Time will surely tell!
As is often the case on a holiday weekend, I like to tinker with my PCs. This Thanksgiving weekend, I found myself wanting to access the BIOS on my production PC with its Gigabyte X77X-UD3H motherboard. But instead of switching over to the BIOS when I struck the DEL key during pre-Windows startup, the system stubbornly persisted in ignoring that input and booting into Windows nevertheless.
As it turns out, something about my Comfort Curve 4000 keyboard was preventing me from accessing the BIOS during boot-up.
Some quick online research was in order, and by searching on “unable to access BIOS” and the motherboard ID, I quickly learned that one or two factors were the most likely culprits:
1. The USB port I was using for the keyboard was not being read during boot-up
2. The keyboard I was using was too slow to get the keypress data to the UEFI shell during initial boot-up
I’m still not entirely sure which of those two causes was at fault, because I simply plugged a different keyboard into one of the front-panel USB 2.0 ports for this PC, knowing that the back-panel USB 3 stuff could easily be coming from an add-on card, and it being too much of a PITA to pull the machine all the way out of the baker’s rack in which it sits to check out that possibility.
At any rate, the new keyboard/front panel USB connection did the trick, and on the next reboot I was able to access my BIOS settings with no further difficulties, though I did also have to switch the Logitech wireless receiver that talks to my M325 mouse to a front-panel USB port for it to be recognized as well. Temporary set-up now working, I made the changes I needed to make to the BIOS, and happily reverted back to the old configuration on the next restart. My current favorite keyboard is a Microsoft Comfort Curve 4000, and the mouse usually plugs into a USB 3.0 port on the PC’s back panel right next to the port where that keyboard plugs in. The old set-up still works just fine — as long as I don’t need to access that PC’s BIOS.
It’s funny how PCs have their little quirks and foibles, and even funnier that Windows or the hardware has a way of reminding us of such things from time to time. Lessons now learned about troubleshooting “unable to access BIOS” for this machine, it’s back to post-holiday work for me!
Every now and then, I like to check in on the Desktop Operating System Market Share pie chart over at NetMarketShare.com. This morning, I had to fiddle the parameters a bit to get the site to show me the most recent stats (which for some reason first came up with a chart that didn’t register Win10 at all, and still showed XP with a market share of over 25% which puts it in the late 2014/early 2015 date range if memory serves). For November 2015, the current pie chart looks like this:
As the year moves toward its final month, Windows 10 is starting to show on the radar.
[Source: NetMarketShare.com 11/27/15]
At 2.54%, Windows 8 is already fading into complete obscurity, now behind Mac OS X 10.10 at 3.45% (but still ahead of 10.11 at 2.18%). Windows XP’s share continues to drop, now only one percent ahead of Windows 8.1 (11.68% for XP vs. 10.68% for 8.1). But Windows 10 has jumped into fourth place at 7.94%, which makes me wonder if Windows 8.1 will have a chance to eclipse XP before being overtaken by Windows 10, or if Windows 10 might not jump into second place ahead of both of those OSes in one fell swoop. Probably not but not entirely inconceivable, either.
Windows 7, of course, remains the true “elephant in the room” with a massive market share that still exceeds all other OSes combined at 55.71%. My prediction is that as soon as Win10 eclipses both XP and 8.1, it will then continue waxing as Windows 7 starts to wane. It could take as long as a year, however, before Windows 7 loses its majority share and Windows 10 consolidates its position enough to start seriously whittling away at the current big dog on the desktop OS front.
I guess that’s progress, as far as changing market dynamics go. What I’d like to start seeing is a chart that combines both mobile and desktop OSes, so we can get a sense of the relative size of both markets as a whole, and the position of the players in each segment. According to Cisco’s Visual Networking Index, the number of connected mobile devices was 7.4 billion in 2014, of which I’d have to guess that 80-plus percent were smartphones or feature phones, and less than 20% tablets or other more computationally oriented devices (such as laptops, notebooks, and so forth). By comparison, the total number of personal computers in use can optimistically be pegged at about 2.3 billion*. Methinks that gives the mobile world increasing heft while relegating desktop OSes to a decidedly second-class position overall. Perhaps that means I should start watching Windows Phones fortunes more closely, too? At under 3% for all versions tracked (10, 8.1, 8, and 7.5) that’s a whole different story, in a world where Android and iOS team up for over 90% of all devices.
[*Note: estimate of total PCs worldwide comes from a 2008 Gartner projection that indicates the total number at over 1B for that year, expected to double by 2014, combined with an estimate of 133% of Q1-Q3 2015 totals of 214 million from Statista, for a total of 285M units for this year, give or take.]
[Update added 11/29 12 PM CDT/-06:00 UCT] Neowin has a fascinating story just up yesterday evening entitled “Windows 7 and XP are the biggest losers with Windows 10’s rapid growth — US Gov’t” that sort of proves my analytical point and sheds some more narrowly-focused data on this marketshare trend (Win10 up, other Windows versions down). You can read the whole thing to see all the data, but the information comes from the government’s digital analytics program (DAP) which shows that among Windows users, 12.4% are using Win10, up from 8% in August, 2015. In the same timeframe, Windows 7 has lost 7% of its share, while XP has lost 2.1% (other versions are also down, with Windows 8.1 down by 1.1%, and Vista 1.6%). Neowin’s conclusion is worth repeating — namely that “…users who purposefully stuck with older — more popular releases — think that Windows 10 is a good upgrade and have started to jump ship.” Looks like MS’s free upgrade from Windows 7 and 8.1 to 10 may be starting to have its desired effect of migrating that user base.
Wow! It’s been a whacky week in advance of Turkeyday, with Version 1511 (Build 10586) gone over the weekend, then back again late yesterday. MS even furnished an explanation, which I reproduce from TenForums.com:
Here’s the scoop, straight from TenForums.com
I ran the new update, which is labeled KB3120677, on all of my Win10 machines last night (including both Preview PCs, and my 5 other production machines) without experiencing any difficulties. Here’s what Winver now reports in its wake:
We gain another .03 on the Windows build number, to 10586.14
More importantly, the versions of Windows now available from the Media Creation Tool are now back in synch with most other sources (the TechNet Evaluation Center, MS TechBench, and so forth, though MSDN shows no change on release date info). Looks like what diverged has already reconverged, which should be a great relief to Windows admins everwhere!
[Update added 11/25 1PM CDT -06:00 UCT] Further details on the settings mentioned in the TenForums post have come to light since I posted initially this morning. The specific details that have emerged center around the privacy options available in Windows 10: to view these, type “privacy options” into the Search box, and check out the Change privacy options that appear there. By default, all of these are turned on in Windows 10; the initial update to V.1511/Build 10586 reset all those options to the default even if the user had set one or more of them differently. Paul Thurrott‘s coverage of this topic says it best, in summing up what’s apparently been going on: “Suffice it to say, none of this matters in the slightest, which makes the pulling of 1511 and the resulting weird silence even weirder.” I concur, and in a tongue-in-cheek nod to the 1985 John Hughes movie classic, we should name this episode of the Microsoft Follies “Weird Silence!” Thanks, Paul…
There’s been a whole lotta hoopla over the past few days about the sudden disappearance of Version 1511 (Build 10586) from the Media Creation Tool late Friday, 11/21. Of the many stories published on this topic, the items from Ed Bott at ZDnet and Peter Bright from Ars Technica, are especially interesting. Current speculation on the reasoning behind this surprise move from the Colossus of Redmond seems to center around the notion that as-yet-undocumented bugs in this new release have prompted the decision to yank the images from the Media Creation Tool, and to revert to Version 1507, better known as Build 10240.
Being myself of a curious nature, I zipped on over to MSDN where Build 1511 also made its appearance on November 12, to see if it had been pulled from that subscribers-only download mecca as well. Here’s what I found:
Version 1511 remains readily available on MSDN, as of early AM Texas time 11/24.
This may just mean that MS hasn’t gotten around to pulling these files just yet, so it will be interesting to watch what happens to MSDN over the next day or two. It may also mean that the speculations about the bugginess of 1511 may be somewhat over-stated. For my own part, I’ve been running 1511 on my Technical Preview test machines for three or four weeks now without any obvious issues, and on all six of my regular Windows PCs (three desktops, a Surface Pro 3, an All-in-One, and a Lenovo X220 tablet) likewise since 11/13 or thereabouts.
While we’re all waiting for the dust to settle, I’d like describe fact and history as we know them at present. Previously, MS has only updated installers for major version changes and Service Packs, and such updates have propagated to the Media Creation Tool (let’s abbreviate this as MCT, and further observe that it is a utility of fairly new provenance, with roots only as far back as Windows 8.1, though Windows 8 did offer similar functionality under a different name) and MSDN in tandem. If the 1511 release counts as a “Service-Pack-like” update to Windows 10, then indeed it makes sense for it to be made available via the MCT and MSDN. Given that the two sources are currently divergent, I’d expect something else to pop up on the MCT front, to catch it up with MSDN. Or, we could be looking at a new regime for Windows 10, where the subscribers have access to releases not made available to the general public. Again: it should be interesting to keep watching, and see which way the mop flops next. According to neowin.net, 1511 is still supposed to be available through Windows Update, though some users have not been able to access it through that delivery mechanism (but that might be a function of a 10240 install that is less than 31 days old, and thus ineligible for WU to offer the upgrade, to give users 30 days to revert to the previous installation).
[Update: 8:45 AM CDT 11/24] Paul Thurrott points to an 11/20 System Center Configuration Manager Team Blog entitled “Issue with the Windows ADK for Windows 10, version 1511” as a possible explanation for why MS yanked the update from MCT. It affects multiple releases of the product and includes the statement “we do not recommend that Configuration Manager customers use the 1511 version of the Windows 10 ADK” (ADK stands for Assessment and Deployment Kit, a collection of tools that sysadmins can use to customize, assess and deploy Windows OSes to new computers). He may be right that this explains the current back-pedaling, and I believe he’s also right to speculate that “bringing back integrated installs will happen in the future.”
[Update: 2:30 PM CDT 11/24] Windows info site Tenforums.com cites MS MVP Greg Carmack’s reports of activation issues with V.1511/Build 10586 as possible cause for switching the MCT from 10586 back to 10240 (and possibly also for making them temporarily off-limits through Windows Update, protestations to the contrary notwithstanding). Read the whole thread for some whacky and entertaining conspiracy theories.
On 11/18, later in the day, my Win10 systems picked up a new cumulative update: KB3118754. What made this update interesting was that it led to an increment in the Windows 10 Version number suffix, as shown in this screen capture from the Winver command:
Following application of KB 3118754, the Build number went from 10586.3 to 10586.11.
After the recent application of the Threshold 2 update last week, the version number stood at 10586.3, and the software made available through MSDN and the Windows 10 Download (Media Creation Tool) was updated likewise. With the change in version number, I found myself wondering if this meant that the versions published through those outlets would also be changed to follow suit. A quick check on MSDN showed the pub date for the version available there remained fixed at 11/12 (the day before the Threshold 2/November 1511 update was pushed out through WU):
No change to the most current available MSDN version for Windows 10.
Just for grins, I downloaded another copy of Windows 10 from the afore-linked download page, and used the Media Creation Tool to build another Windows 10 installer UFD. Taking advantage of the info from my previous blog post, I used DISM to give me version info from the .esd file on that media, and saw no change in version info there, either.
I’m glad to understand that we can track versions for Windows 10 more precisely now, but that this doesn’t mean a constant need to update installer and/or repair/recovery media to track those frequent version number changes. I guess the difference between the current baseline version as defined by those items and the current actual version as defined by the most recent cumulative update will instead stand as a rough-and-ready metric for how many updates will need to be applied to the baseline version of Windows 10, should one be required to perform a refresh, reset, or in-place upgrade by way of repair.
The Windows 10 adventure continues, as we all learn the new and emerging rules of the road that are unfolding before us. Let’s hope we can keep making sense of what’s happening as those changes keep coming!
The more I dig into the DISM (Deployment Image Servicing and Management) command, the more “good stuff” I keep finding. Today’s gem comes courtesy of Sergey Tkachenko, whose excellent WinAero.com site has come in for kudos from me many times already in this blog. Earlier this week he posted an item entitled “How to see which build and edition of Windows 10 the iso file contains,” but his observations apply equally to bootable UFDs (or even optical media, for those who use them for Windows installation), and also apply to Windows versions as far back as 7 (and possibly even Vista, in which version the .wim, or Windows Image, file format was introduced). The same approach also works for compressed .esd (Electronic Software Download) files as well, like those included in the installer constructed using Microsoft’s Media Creation Tool (.esd . files are of more recent vintage, however, and go back only to Windows 8). In short, you can aim DISM at a .wim or .esd file, and use it to tell you what version of Windows it’s looking at. Here’s some syntax:
For .wim files:
where <dl> is the drive-letter for the volume you’re looking at (perhaps by mounting an ISO) and <wimfile> is the name of the Windows Image file you’re inspecting (usually this will be named install.wim or perhaps boot.wim)
This is the info from the UFD I built to upgrade the en-GB version of Win10 running on my production PC.
For .esd files:
where <dl> is the drive-letter for the volume you’re looking at (perhaps by mounting an ISO) and <wimfile> is the name of the Electronic Software Download file you’re inspecting (usually this will be named install.esd
If, like me, you’ve got numerous bootable installer and repair/recovery UFDs laying around, not all of them labeled — especially now, when we have to make sure we’re using the right version of Windows 10 to match what we want to install or repair — this little technique can come in quite handy. Give it a try!
In getting to know the new build of Windows 10 released late last week, I’m starting to notice some interesting refinements here and there. In particular, v1511 now combines location and time zone by default, so that it can reset a device’s time presentation automatically while on the move. I’ve long wondered why MS didn’t add this capability into the OS, given that Windows devices get time updates from time servers by default, and are tuned into their geographic locations ditto. And finally, it appears that MS has connected these two types of information to make that happen without requiring users to pop open the Date and Time widget from Control Panel (or to access Date & Time through Settings/Time & Language instead). Here’s what it looks like:
The Settings app lets you manage time and time zone settings automatically, and the Control Panel widget lets you override those settings.
This capability will be particularly handy for those who travel with their Windows devices. As soon as you turn off Airplane mode before getting off the plane (or cross time zones on slower modes of transport), your device should automatically reset the time zone shortly thereafter. Good stuff, if long overdue!