In my continuing efforts to maintain the health and well-being of my Windows 10 installations, I’ve continued messing about with the built-in deployment image servicing and management tool otherwise known as DISM. When I ran into a problem with targeting the windows image (.wim) and/or electronic software download (.esd) files that can be used to provide the full panoply of Windows files and component store elements (found in the often-mysterious %windir%\WinSXS folder), I turned to the Windows Ten Forums to search for other potential sources to replace corrupted component store elements.
Understanding the Symptoms
Despite targeting the install.esd file in the sources folder on my install/recovery UFD, DISM kept coming up with a “file not found” error in its attempts to replace the single corrupt file that a /scanhealth pass over my target system identified. Understanding that this meant the tool could not find the component store element it needed, I quickly pounced on the following “trick” to point the tool at an alternative, but equally valid source for the missing materials. It seems that if you copy the %windir%\WinSXS from a running Windows 10 system that comes up clean for the following commands, you can use it as your source for DISM successfully, too:
- sfc /scannow
- dism /online /cleanup-image /checkhealth
As long as cmd.exe gives you output that looks like this, you can copy the entire WinSXS folder to a UFD or other drive onto the target system, and then use that as the attribute value for the /source directive in the DISM command string that also includes the /restorehealth directive as well.
A Word of Warning
It takes a while to run the afore-cited commands, so it’s probably wise to fire them off in a window that you can cheerfully ignore for a few minutes. This sequence is entirely necessary, because the last thing you want to do is to provide one corrupt WinSXS folder as the source for repairing another corrupt WinSXS folder. Likewise, even when you succeed, it will also take some time (about 28 minutes for a USB 2.0 UFD, and 15 minutes for a USB 3.0 UFD, as per my own observations) to create the copy of that folder where and when you need it. But this technique works, as the foregoing screen capture shows, because I used it to repair the component store on the very system upon which this “component store OK” command sequence was issued.
For another discussion of working with the DISM command, please see my October 19 blog post entitled “Simple Trick Fixes DISM /source Syntax Issues.”
Goody, Goody: one of the things I liked least about Build 10565 in the Windows 10 lead-up to the Threshold 2 Build scheduled for later this month (November 2015) has apparently been fixed in Build 10576. Whereas Gadgets had more or less quit working in that preceding build (10565), they are once again working properly in the latest build (10576). Here’s a screen shot to show them in action alongside Windows version info:
MS claims that apps are worthy replacements for gadgets, and that they can “do many of the same things and much more,” where “some apps are better versions of the gadgets you love, and many of them are free” (quotes come from the “discontinued” page linked in the screenshot caption above). Alas, I must demur, because my primary use of gadgets is for real-time system monitoring, particularly using the excellent Network Meter and All CPU Meter gadgets from AddGadgets.com. I’ve yet to find an app that can match their compact capability to report on what my PC is doing with its compute capabilities (CPU Usage) or networking connections (Network Meter). In fact, I’ve grown dependent enough on these gadgets that I now feel just a little bit hamstrung when I have to run a Windows system without having them at my disposal.
So of course I’m delighted to discover the return of gadget capability via 8GadgetPack in Build 10576 of Windows 10. I’m hopeful this means gadgets will continue to carry on in future releases of Windows 10 going forward, including the upcoming Threshold 2 release scheduled for later this month. In fact, the rumor mill appears to be reaching consensus that this will occur on November 10 or thereabouts, that being “Update Tuesday” for this month, when MS normally used to release its updates and patches on the old once-or-twice-a-month only schedule — though this may or may not be true, it at least sounds plausible on that basis. We’ll find out soon enough, I reckon!
Between a couple of interesting stories reported at NeoWin.net and WinBeta.org recently, the rapid rise of Windows 10 installs appears to be slowing down from its initial explosive rate. Although the current level of 120 million installs reflects a daily rate of 1.33 M installs per day, that number has gone up from 110 million reported on October 6 to 120 million on October 29. For the past 24 days, that puts the daily rate at only 0.42 million per day, or 31.5% of the overall average. While many sources write gushingly about how well Win10 is doing, and how MS may indeed be able to reach its billion-install milestone in 2 or 3 years, I am not quite so encouraged by this recent and apparently massive slowdown in the daily install rate. Here’s a graph I put together to show what’s going on using a non-representative time scale:
There’s been a considerable flattening of the uptake curve since the beginning of October for Win10 installs.
The data points shown are as follows:
1. 14 million, 24 hours after initial release on July 29, 2015
2. 53 million, three weeks into the cycle on August 19, 2015
3. 110 million on October 6
4. 120 million on October 29
I can’t help but see a trend where the curve is losing upward momentum (sharper slope) in favor of slowing installations (flatter slope). Of course, a small number of data points makes it difficult to predict a trend accurately, but this looks like a phenomenon that’s reached its peak in terms of momentum and is slowing sharply. On the other hand, the upcoming release of Threshold 2 in November, and the switchover of Xbox consoles to a Windows 10 code base, may inject some further increases in the overall curve — we’ll just have to wait and see what happens. But based on the numbers at hand, it looks like MS may have been a tad over-optimistic in projecting the line out to 1 billion overall installs, even a full 36 months out from the initial release date for Build 10240 on July 29, 2015. Even at 1.33 M installs per day, it will take over 20 months to get to 1 billion total installs for the remaining 880 million left to go; at 0.42 M per day, that timeline stretches out to over 5 years!
Among my various desktops, laptops, and tablets, I’ve got an 16-month-old Surface Pro 3 purchased in August 2014. In working with the boot/sys drive recently I noticed I still had a windows.old folder hanging around, courtesy of my September upgrade to Windows 10 on that machine. “Hmmmm,” thought I to myself “that’s interesting: I thought I’d run CCleaner on that drive, and I *always* check the ‘Old Windows installation folder cleaning’ option therein when it shows up.” So I ran CCleaner again, and observed that the Windows.old folder on the Surface only included 400-odd MB of files (normally, for Windows 10, it runs somewhere above the 12-14 GB mark). Sure enough, although the program claimed to have cleaned-up Windows.old, it persisted past its supposed deletion size unchanged.
To make a long and somewhat tedious story as short and to the point as possible, I was also unable to remove Windows.old from the Surface using either the built-in Disk Clean-up utility, nor did the usually capable Unlocker program prove equal to the task of deleting the folder, either. Somewhat unpleasantly, I also observed that the latest Unlocker version comes chock-full of “bundleware,” including a search engine and home page replacement to some site that Norton disallows because of the presence of spyware and potential malware at that address. That’s why I’m no longer recommending the program to readers, and will have to find some more benign program to take over its role of resetting Windows file locks and overriding the strongest of read-only permissions.
Rd is the abbreviated form of the built-in “Remove directory” command at the Windows command line.
Once I cleaned up the small messes that Unlocker left behind on the Surface, I turned to the Windows 10 forums (TenForums.com) to their Tutorial entitled “Windows.old Folder — Delete in Windows 10.” That’s where I was reminded that, if all else fails, you can boot to a recovery/repair drive (which I always keep handy on a clearly labeled 8 GB USB 3.0 flash drive) and get rid of persistent files and folders at the command line. Here’s what I did to make that happen:
1. Shut down the Surface
2. Inserted the recovery/repair UFD into the USB port
3. Push the Volume Down button, briefly press the power on button, and hold Volume Down until the Surface logo appears on-screen
4. When the device boots into the recovery/repair disk, click through the first install screen, then elect repair on the second screen, and make your way into Troubleshoot, Advanced, and ultimately, Command Line Prompt
5. At the command line, run diskpart list volume to get the drive letter for your boot/sys drive (it won’t always stay the same when you boot into the WinPE image on a recovery/repair UFD, though mine did
6. Enter the following command to remove the persistent folder: rd /s /q C:\windows.old (substitute the correct drive letter to match your boot/sys drive as shown in the preceding diskpart command)
That’s all there is to it! Just goes to show that where there’s a will, there’s almost always a way to get things done in Windows, but also that getting there may not be as simple and straightforward as you might like. Such is life in Windows-Land!
If there are some distinctions to which Window10 testers should not aspire to attain, I’d have to say falling prey to the boot/system failures now widely associated with the recent KB3105208 cumulative update is one of them. The update appears to proceed normally, and then asks for a reboot (also a normal consequence of installing updates). But once a reboot has occurred, instead of the usual subsequent reboot start-up, what many sources are calling a “blue screen” or BSDO occurs instead. I will actually quibble with this terminology and observe that a normal start-up fails, and the built-in recovery screen pops up instead. What makes this update particularly insidious is that normal recovery techniques don’t work: you can’t perform a start-up repair, you can’t run a restore, and apparently, you can’t do much of anything at all, except perhaps for a clean reinstall of the OS.
How do I know all of this? My Dell Venue Pro 11 fell prey to this malaise, and I dithered around with it for a while before turning to the Internet for such flashes of wit and wisdom as might be available. Fortunately for me, turns out there is no shortage of insight on this particular failed update, much to my benefit and to the benefit of others who might have found themselves in that boat. This potential gotcha is no longer a threat, because in the wake of widespread yelling about problems with KB3105208, MS yanked the update and has promised to re-release it without the errant fix that brought affected systems down.
This snippet from the BIOS Configuration section of the VP 11 7139 User’s Guide gets to the heart of this matter.
As it happens, the only systems affected are those with Secure Boot enabled, which make tweaks to a UEFI BIOS to secure the boot-up sequences from unwanted tampering. The trick to the fix is to disable Secure Boot in the UEFI after which the system will return to what passes for normal with Windows 10 preview builds. My VP11 is now back on the job, awaiting the repair to KB3105208 that will let me turn Secure Boot back on, or the next Fast Ring release, which will hopefully do likewise.
Just another day in the sometimes exciting, at other times frustrating, round of the preview OS victim … err … tester. One more thing: you will also have to visit http://windows.microsoft.com/recoverykey to retrieve your BitLocker recovery key so that the next reboot can decrypt your boot partition (this is what protects it from tampering when Secure Boot is enabled) to permit a non-Secure Boot restart. Entering a 42-digit numeric string is not without its unique delights but if you’re careful you can get it right the first time!
There has been plenty of heated discussion about the way MS has handled updates in Windows 10. Much of that discussion has centered around Windows 10’s update push behavior, which forces updates on Windows 10 PCs whether the recipients want them or not (see one workaround for this in my 7/27/15 post on the MS “Show or hide updates” tool). One additional consequence of this behavior is that, following the application of some updates, Windows 10 will automatically reboot itself within 24 hours at some scheduled time or day or night — I’ve got my time window set for 3:30 AM, for example, since I’m pretty much never up and at the PC at that particular time myself. Alas, however, sometimes we don’t want Windows to reboot for awhile, usually to preserve machine state because of something we’re working on, watching, or otherwise engaged with that would be derailed thereby. That’s why I was pleased to see a Registry hack made public over at Sergey Tkachenko’s excellent Winaero.com site yesterday, in a blog post entitled “How to prevent Windows 10 from automatically rebooting for update installations.” In that post, he also shows the somewhat tyrannical warning message that Win10 displays when the scheduled boot time is nigh:
No choice but to close all apps and batten down the hatches when this message appears.
Here’s the registry hack involved, for those comfortable with mucking about therein:
- Launch the registry editor (e.g., type “regedit” in the Search box).
- Navigate to this registry key:
\WindowsUpdate\AU (all on one line of text, please)
If the key does not exist create it.
- Within the key create a DWORD value named NoAutoRebootWithLoggedOnUsers and set its value to 1.
- You must restart your PC (in a cruel twist of irony) for this change to take effect.
That’s all there is to it. Enjoy!
I’ve got a Samsung ML-2850 monochrome laser printer on my network, and I’ve been chasing around various ways to interact with it lately. It seems that unless you’ve got access to a print server, and set up that print server to offer the network printer up to network users, you can’t access a network printer by name. You must instead access it using its IP address. Perforce, at the same time I also realized that it really makes sense to reserve an IP address for a networked-attached printer in DHCP to prevent the occasional automatic renumbering that sometimes occurs from rendering an old DHCP-assigned address obsolete and non-functional.
This required some futzing around with my Arris TG1672G boundary device, which combines cable modem, router, firewall, and WAP capabilities in a single package (in my area, Time-Warner requires such a device to access their fastest consumer-grade Internet service, rated at a putative 300 Mbps, but which I’ve seen running as fast as 353 Mbps lately). I had to create a DHCP reservation (what the device itself calls a “Reserved IP client”) using the device name along with its IP and MAC addresses, all of which I discovered easily using Nir Sofer’s excellent Fast Resolver utility.
After that, I was able to use either the “Add a printer using a TCP/IP address or hostname” or the “Add a local printer or network printer with manual settings” option in the Add printer dialog box to add the device using its now-static IP address. This dialog box is available either through the Settings (Devices –> Printers & Scanners) app or the Devices and Printers widget in Control Panel in Windows 10. Here’s what that drop-down menu looks like, from which I knew I needed to select 192.168.0.18, that being the static IP assigned to the Samsung printer.
The secret to successful setup is knowing the right IP address.
Though it’s not as easy as it could be with the network printer discovered automatically, it’s still workable enough. Perhaps these observations can make it work better for you.
I’ve been messing around with the MS Deployment Image Servicing and Management (DISM) tool since it made its debut along with Windows 8, when it replaced the ImageX tool built into previous Windows versions, as well as the Windows Package Manager (Pkgmgr.exe), PEimg, and intlcfg tools likewise included in older versions of the Windows Deployment Toolkit. For modern Windows versions — meaning Windows 8, 8.1, and 10 — DISM is a kind of master or skeleton key into the whole world of Windows image creation, management, and repair for versions of Windows from 7 through 10 (though DISM post-dates Windows 7, it still knows how to work with it anyway).
As much as I’ve worked with DISM, one little gotcha has hampered my use of the utility, especially when working with the all-important command that allows the tool to fix a corrupted WinSXS (Windows Component Store) directory, as will sometimes happen to Windows installations. The general syntax for this command takes the form:
DISM /online /cleanup-image /restorehealth
But when the WinSXS store gets corrupted, it becomes necessary to point the tool at a different respository for the files that DISM will copy to replace any corrupted files that it finds. This is also where things can get interesting, because the syntax for an additional parameter — named /source is perhaps a bit trickier than it looks. Through trial and error, if using a WIM (Windows Image) file as your source (as is common when working from an ISO for the underlying OS), I learned that one must use this syntax to properly point to the source files involved:
DISM ... /source:WIM:path&filespec:1</p
I’m not exactly sure what the colon one (:1) at the end of the file specification is about, but the command won’t run without it. I found clues to its necessity, but not in the DISM TechNet documentation as you might expect. Rather, it was the usually helpful postings over at Windows Eight Forums on DISM and image repair that clued me in. Go figure!
Since the latest Patch/Update Tuesday earlier this week on 10/13, the computer trade press has been rife with stories about Microsoft’s accidental enablement of the Upgrade to Windows 10 option on Windows 7 and 8.1 PCs. More than mildly curious upon reading about same, I checked the 8.1 boot image on one of my dual-boot test machines (I’m already running Win10 on the “other boot” for that PC). Sure enough, here’s what I saw in my Windows Update widget for Optional update elements on that machine:
Note the checkbox next to “Upgrade to Windows 10 Pro” is already checked!
Indeed, MS has been doing everything it can to persuade Windows 7 and 8.1 users to upgrade to Windows 10, including the by now infamous “Get Windows 10” widget it installs in the Taskbar on PCs running those OSes. But consensus is emerging that this latest prompt to catch users up with Windows 10 might be taking things a step too far on the side of MS convenience versus user control.
And in fact, Ars Technica obtained a statement from Microsoft on this subject that I reproduce verbatim here:
As part of our effort to bring Windows 10 to existing genuine Windows 7 and Windows 8.1 customers, the Windows 10 upgrade may appear as an optional update in the Windows Update (WU) control panel. This is an intuitive and trusted place people go to find Recommended and Optional updates to Windows. In the recent Windows update, this option was checked as default; this was a mistake and we are removing the check.
Because I was still able to elicit this behavior this morning, one day after the report hit the Ars Technica website (and then proliferated wildly around the Web), it seems that MS hasn’t yet gotten around to pushing that removal out quite yet. Consider yourselves warned and/or amused, hopefully in equal parts!
I’ve been steering clear of writing about Windows 10 Preview builds since the 10240 Build became publicly available starting on July 29, mostly in the interests of addressing the Windows 10 version that the vast majority of users have at their disposal. But a single change to the latest released Insider version (numbered 10565) requires me to report and comment to the broader world of Windows admins, as it promises to make their jobs easier.
Simply put, Build 10565 lets you use a Windows 7 or 8.1 product key to activate a clean Win10 install on an eligible PC.
Here’s what that change boils down to: instead of requiring an upgrade from Windows 7 or 8.1 to complete successfully, before allowing a clean install of Windows 10, this latest build allows a clean install of Windows 10 on a target machine, where its original Windows 7 or 8.1 key may be used to activate Windows 10 during the clean install process. In other words, an immediate clean install is now possible, using the key from the OS resident on the target PC at the time the clean install gets underway. This is not only simpler, it’s also much faster than having to go through the upgrade before enabling a clean install to occur.
We have received a lot of feedback from Insiders on making it easier to activate Windows 10 on devices that take advantage of the free upgrade offer to genuine Windows by using existing Windows 7, Windows 8 or Windows 8.1 product keys. If you install this build of the Windows 10 Insider Preview on a PC and it doesn’t automatically activate, you can enter the product key from Windows 7, Windows 8 or Windows 8.1 used to activate the prior Windows version on the same device to activate Windows 10…
If the automatic upgrade doesn’t work, users can take the Change Product Key option in Windows Activation and enter their original Windows 7 or Windows 8.1 product key to activate their Windows 10 free upgrade.
Microsoft actually listening to and acting upon well-reasoned user feedback and input? Wow! What’s the world coming to? Seriously, this could be the best single change to the Windows 10 upgrade/install process made so far, and an incredible boon to admins and power users tasked with making that upgrade everywhere. And that’s why I felt compelled to blog about it today, too, even though installing 10565 on one of my test machines re-introduced the by-now-familiar “won’t recognize Killer Ethernet devices” problem I’ve seen on numerous prior Preview releases.