Holy Moly! I ran into an interesting issue yesterday when trying to update one of my Insider Preview test machines to Build 18277. The update kept failing with error messages that indicated access/permission problems downloading updates. When I switched from Windows Update to David Xanatos’ excellent Windows Update Manager (WUMgr.exe) program, I saw an endless series of HTTP 403 “access forbidden” error messages each time the update engine tried to grab a package. “Hmmmm” I thought to myself, “something odd going on here.” Then I remembered a TenForums post I’d seen earlier in the day: MSFT acknowledges some Win10 Pro licenses being mistakenly deactivated. “Could this be my problem?,” I wondered. Sure enough, when I visited the activation page in Settings, I confirmed for myself that MS Activation Server issues temporarily negate Win10 licenses. Check it out:
Not only does the license show up as deactivated, the troubleshooter claims it’s Win10 Home and needs a reinstall. Ouch!
Fixing MS Activation Server Issues Temporarily Negate Win10 Licenses Is Easy
Once MS realized it had this problem, it went all out to fix it. Within half a day, two simple methods now set things right if this happens to you. (Note: some reports affecting Windows 10 Enterprise users have surfaced, as well as Windows 10 Pro users. The symptoms and fixes are the same for both editions.)
Re-run the Troubleshooter
Now that the Activation Server issues have been addressed, running the Activation Troubleshooter will restore the digital license that belongs to affected installations. Appears as a link labeled “Activation Troubleshooter” on PCs in need of activation on the afore-depicted Activation Settings page. Takes a minute or so to complete.
Use the Software Licensing Management Tool (Command Line)
A faster, more direct method involves running either an administrative Command Prompt or Power Shell session with a single command. Here’s an illustrative snapshot. I ran this on those two of my PCs affected by the issue and it worked in 30 seconds or so. Easy-peasy.
After you run the slmgr /ato command, wait for the WSH pop-up and click OK. That’s it!
All’s well that ends well, they say. I’m guessing that Microsoft, perhaps even more than those with PCs affected by this issue, wishes it had never happened in the first place. Alas, however, that’s life in WindowsWorld!
Here’s an interesting feature that’s just appeared in the latest insider preview (Build 18272). If you hold down the Control (CTRL) key and use stretch controls, you can shrink or grow PowerShell, Command Prompt, or Windows Subsystem for Linux (WSL) windows. Here, stretch controls encompass shrink/grow gestures on trackpads as well as up or down motions on mouse scroll wheels. This beats the stuffing out of right-clicking on the title bar to manage font size selection, and using more traditional method to shrink and grow windows. Because new Win10 zoom controls are coming to future versions, only insiders can play with this capability right now. But I just tried it out on both PowerShell and Command Prompt windows and it’s way cool and convenient.
Soon, you’ll be able to use stretch controls to resize command window text as well as window size.
How Soon New Win10 Zoom Controls Are Coming?
Unless MS decides to slide this functionality into Windows Update sooner, these new controls won’t hit Win10 until next year. If history is any guide, that means everyday users will gain this nifty function between April and June of 2019. I learned this tidbit from Martin Brinkmann at ghacks.net. He posted “Windows 10 version 1903 may feature command prompt zooming” on November 7. His description of this process is accurate and concise:
All you need to do is hold down the Ctrl-key on the keyboard and use the mousewheel or trackpad to zoom in or out. The shortcut is the same that you may use in modern desktop browsers to zoom in or out of page content but the effect is different.
What’s cool, of course, is that the zoom effect here works for the entire command window (PowerShell, cmd.exe, or WSL). The best part is that text size increases based on window dimensions (bigger windows have bigger text, smaller windows vice-versa). For somebody my age who now squints at the fine print even wearing glasses, this is very welcome. Helps make Windows 10 more geezer-friendly, and I’m all for that!
Lord knows, Win10 has occasional gotchas and weirdnesses. Browsing TenForums, I noticed an interesting discussion on ejecting USB drives. Users may click the toolbar item labeled “Safely Remove Hardware and Eject Media” at their discretion. But apparently, it doesn’t always produce the “Safe to Remove Hardware” notification shown below. Though there are ways that sometimes work to restore notifications — see this TF thread for discussion — this doesn’t always work for all users. That’s when this handy Win10 USB eject tool comes in handy. It’s free from Quick and Easy Software and it’s called USB Disk Ejector.
When notifications work as they should, this is what Win10 shows when you use its built-in Safe to Remove utility.
Why Use a Handy Win10 USB Eject Tool Instead?
When the confirmation message fails to appear, there’s a certain amount of trepidation as to whether or not it really IS safe to remove the selected USB (or removable media) item. And because some users can’t fix the notification issue using Settings or underlying registry keys, an alternative makes sense. USB Disk Ejector is one such alternative. It pops up in the lower right-hand corner of the display (in the same place as Taskbar notifications). It lets you interact with USB and removable media devices directly. And when a device is ejected or removed, it changes the display to reflect that change in status immediately.
With something to eject, USB Disk Ejector lets you pick an item from its interface.
Once ejected, the device entry is removed from USB Disk Eject’s list of devices.
In my book, this is a useful little utility that can help some users work around a minor Win10 gotcha. Use it if you need it, but feel free to skip it if you don’t. In my recent experience, USB Disk Eject is quick and easy to use, entirely portable (runs just fine from a UFD), and even works from the command line. Best of all, if its developers have things right the tool succeeds in ejecting disks even when the built-in facility fails in that job. Oh, and it’s Open Source, too (code available from GitHub).
[Note: Thanks to long-time TenForums Pro User Callendar for bringing this excellent utility to my attention. Always glad to find cool tools!]
At least three recent versions of Windows 10 suffer from a Task Scheduler task failure. By default, Windows 10 is supposed to back up the Windows Registry when the OS is idle. That’s why the related task is called RegIdleBackup. (It resides in the \Microsoft\Windows\Registry subtree in Task Scheduler.) As I just confirmed for myself, this task is broken in Build 1803, 1809 and in current Fast Ring/Skipahead Build 18272. Why do I say Win10 registry backup task broken? Let me explain . . .
How to Tell if Win10 Registry Backup Task Broken on Your PC
Windows 10 stores registry backups in a folder named %windir%\System32\config\RegBack. If you visit that folder on your PC, and the folder is empty, the registry backup task is broken. This is true right now for all my 1803, 1809, and Build 18272 installations (9 physical plus half-a-dozen VMs).
When you try to access this folder, you may get the following error message from Explorer (I did on all of my PCs):
Although the folder is present, Explorer may present this error message should you try to navigate directly into it.
If that happens to you, simply visit the parent folder (C:\Windows\System32\config). Then you can manually navigate into the RegBack folder from there. Sure enough, all of mine were empty:
If the folder is empty, the RegIdleBackup task is not backing up the registry.
Even so, if you visit the Task Scheduler and check on the RegIdleBackup task, it will report its successful completion some time in the recent past. Here’s what I saw:
Even though no backup files are present, the task still reports success. Go figure!
Oops! Good thing I don’t rely on registry backups much (or at all). That’s because I use Macrium Reflect to create an image backup of my production PC daily at 9 AM. I can always mount that image, or run it as a VM, to regain access to prior registry snapshots.
Other Registry Backup Tools
If my solution isn’t for you, there are other third-party registry backup tools available. In fact, my personal favorite is from UK-based Bleeping Computer, and is called Registry Backup. Otherwise, more such tools are cited in the Raymond Computers article (10/27/2016) entitled 5 Ways to Backup and Restore the Windows Registry … You may also want to check that out.
[Note: Thanks to Martin Brinkmann at ghacks.net, whose 10/31 story Windows 10 bug prevents Registry backup creation brought this matter to my attention. I’ll be curious to see how soon MS gets around to fixing this potential gotcha.]
Earlier this month, MS posted a complete set of Group Policy settings for 1809. Grab this document from the Microsoft Download Center. It shows up as an Excel file named Windows10andWindowsServer2019PolicySettings--1809.xlsx. As MS posts new Win10 1809 Group policy reference, it offers information about 4,241 entries.
This innocuous download is 708KB in size, but contains a wealth of useful and informative data about policies admins can use to manage and control Windows.
Each line in the spreadsheet identifies:
- New in Windows: Version Number when item was added
- File name: the administrative template file (.admx) in which it is defined
- Policy setting name: official name for policy setting
- Scope: where the policy applies (Machine or User)
- Policy Path (object path in GP editor where the policy resides)
- Registry info (the full registry path for corresponding registry values)
- Help text: a brief explanation of what the policy is for, or is intended to achieve
When MS Posts New Win10 1809 Group Policy Reference, Grab It!
This information is useful for more than the policies it enumerates and describes. Because Win10 Home doesn’t include a Group Policy editor, it provides vital clues that Home users can chase down for managing their PCs. Thus,the corresponding registry settings are worth their weight in gold. They point at areas in that organic and complex data collection where investigation and experiment can be fruitful.
Please note, the details that appear on the download page are incorrect. They show a date of October 17, 2017, filename
and a size of 692 KB. As downloaded, filename Windows10andWindowsServer2019PolicySettings--1809.xlsx, date is October 2, 2018, and file size is 708 KB. Inspection quickly shows it makes reference to 1809 and earlier Win10 versions, so it’s the real deal.
Grab a copy today, please, and start digging in. In fact, there’s gold in them thar columns and fields!
[Note: Thanks to Sergey Tkachenko at WinAero.com for his October 26 story that alerted me to this spreadsheet.]
One of the funnier acronyms in computing is PBKAD. It stands for “person between keyboard and display.” Thus, it refers humorously to the weakest link in most troubleshooting scenarios. Like me, for instance, after installing the latest Insider Preview for Windows 10 (Build 18267). At first, I forgot that it’s necessary to re-apply the Macrium Reflect NTFS file system patch. Otherwise, you’ll see the infamous “Error 9” depicted below. But then, I grabbed the wrong patch (32-bit instead of 64-bit) and groused because it didn’t work. And that’s why I say operator error makes Insider Preview bug persist. Once I applied the right 64-bit patch, I could resume making image backups. Sheesh!
This issue comes from a change MS made to NTFS back in Build 18234, and has persisted into every Insider Preview since.
Getting Past Operator Error Makes Insider Preview Reflect Bug Persist
That turns out to be easy, actually. When I posted my issue to the TenForums community, other Win10 Gurus confirmed that my method was correct. They could only speculate I’d grabbed the wrong patch. When I downloaded and applied the right patch again, backup resumed working. Thus, it was obviously and completely a PBKAD problem. Yours truly really knows that a 64-bit patch is required to fix a 64-bit system. He just didn’t grab the right patch the first time he sought to apply it. Sigh.
The moral of this story is that when things don’t work, check your work first and foremost. Sure, I could’ve gone through the motions again and figured things out eventually. But this escapade demonstrates another great value of the TenForums community. It’s a powerful force to counter the unavoidable if occasional impetus to do something stupid. And it sure helped me out of a jam this time, too. Here’s what I observed in my closing post on that thread. “Glad to have my backup working again. It’s even MORE important than usual on the Insider Preview test machines, because I (or somebody else’s software) blow them up pretty regularly.” Case closed, thank goodness!
Here we go again, apparently. Paul Thurrott is reporting a second data loss bug for Build 1809. It seems that the Compressed Files feature in that release has a problem. It’s silently overwriting original files and folders. It happens when you move items from a ZIP file and those same files already reside in the target directory. Thus, a second data loss bug in 1809 raises serious concerns about Win10. In this case, Thurrott makes a telling and painful observation (I added bolding to the concluding text for emphasis; see also this Reddit thread):
“As with the original data loss bug in this release, this problem had been reported months ago through the ineffectual Windows Insider program, whose purpose now seems unclear. As I’ve observed many times throughout Windows 10’s lifetime, Microsoft collects a lot of data during the development of each version, but it seems to have no understanding of what to do with that data.”
Here’s the Reddit post that prompted Thurrott’s observations and invective, now proliferating across the web.
[Click image for full-sized view.]
Why a Second Data Loss Bug in 1809 Raises Serious Concerns about Win10
This echoes the data loss that caused the withdrawal of the original 1809 release. Build 17633.1 disappeared three days after it dropped. Insiders are reporting issues, but it’s not clear that Microsoft is catching and responding to them. There has to be some way of allowing users to rate severity. Or perhaps, AI/machine learning could flag Feedback Hub input. It’s vital to highlight issues that MUST be addressed before a release is allowed to go public.
I’m strongly of the opinion that any issue that involves data loss should go to the head of the “fix queue.” Obviously, other industry observers – including Thurrott, my business partner and Win10.Guru co-conspirator Kari Finn, and even long-time MS analyst Mary Jo Foley – feel likewise. The Windows Insider program is collecting feedback, but the process of analyzing and acting upon that feedback is questionable at best, and appears increasingly broken. If MS wishes to retain its market presence and desktop OS dominance this must change.
At a minimum, I’d suggest that MS expand upon the reporting capabilities in feedback hub to allow those who report issues to also be able to rate their perceived severity. Sure, this will add noise to that channel. But hopefully, it will also allow MS to pick up on issues where users lose data or where malfunctions threaten system integrity, stability, and usability.
Thanks to Martin Brinkmann at ghacks.net, I stumbled across a possible replacement for the excellent Windows Update MiniTool, aka WUMT. It’s from a developer who goes by the name of a Disney character, David Xanatos. The program’s name is Windows Update Manager, aka WUMgr. The program’s readme file says “This tool is inspired by the Windows Update Mini Tool, however in contrary to WUMT it is written in .NET instead of C/C++ and it is Open Source; those [sic: thus] it’s [sic: its] continued maintenance is enured [sic:ensured].” Like WUMT, WUMgr is written to the Windows Update Agent API. It actually looks almost exactly like WUMT, too, as the following screenshot shows. Thus, I must ask the question: Can WUMgr replace WUMT?
Those familiar with WUMT will recognize WUmgr’s look and feel as a nearly exact replica.
[Click Image to see full-sized view.]
Why Ask: Can WUMgr Replace WUMT?
WUMgr lets user selectively block access to WU Servers, disable Automatic Update, and even, disable Update Facilitators. This makes the WUMT wrapper script needed to turn WU on and off unnecessary.
Because WUMgr can completely disable WU, I think it’s got some chops that WUMT lacks. The only way to use WUMT likewise is via a so-called “wrapper script.” Only then does the script handle those functions independently. Contrariwise, WUMgr brings them into the GUI, and makes them easy to enable or disable as needed.
Is WUMgr Ready for Prime Time?
I can’t really say yet. Fact is, I’ve only been using the program for 5 days, and I haven’t had much chance to exercise it. But I’m going to be using WUMgr as heavily as I can going forward, and I’ll follow up here — and possibly also on Win10.Guru, where my WUMT overview is the most-visited piece of content there — as I learn more. Stay tuned.
In the meantime, here are some important WUMgr links:
A USB gotcha appeared among various woes in the wake of the initial 1809 release of Windows 10 (Build 17763.1). Having finally had time to test, I’m pleased to report that Build 17763.55 fixes USB issues. USB 3.0 devices, including drives and hubs, showed up in 17763.1 as USB 2.1. Now, they show up as USB 3.0 just as they should, with performance to match. My source for this info comes from Uwe Sieber’s excellent USB Device Tree Viewer utility:
Notice the (yes) value for Usb300. Note also confirmation that the drive is operating at SuperSpeed.
Further Proof: Build 17763.55 Fixes USB Issues
Further examination of other named fields in output from Sieber’s tool confirms USB 3.0 capability across the board. Interested users of the tool will find ample confirmation (or rebuttal) of USB 3.0 capability in the following fields, by name, for devices they check:
- Connection Information V2 (source for screenshot)
- Device Descriptor
- SuperSpeed Endpoint Companion Descriptor
- SuperSpeed USB Device Capability Descriptor
Further examination of driver information in Device Manager shows a series of 2018 dates for my PC’s ASMedia Root Hub, ASMedia USB 3.1 eXtensible Host Controller, Intel USB 3.0 eXtensible Host Controller, and USB Root Hub. The first two (ASMedia) show July 2018 dates, and the last two (Intel) show September 2018 dates. All are now current. In addition, their information squares with current/latest USB driver information from the always-informative and reliable USB driver info at Win-RAID.com. And finally, quick performance checks using CrystalDiskMark show that USB 3.0 drives (HDs and SSDs alike) are back in their usual ballparks. Thankfully: case closed!
Here’s an interesting note, with interesting implications about Windows 10 version 1809. Entitled “What’s new in printing in Windows 10, Version 1809” (dated 10/4/2018) it explains that print scan drivers move to Windows Update. That note explains further:
Prior versions of Windows included basic printer drivers that enabled simple printing when a full feature driver was not available. To reduce the Windows footprint and provide more storage space to users, these drivers no longer ship with the OS and instead are available through Windows Update.
Until 1809, MS bundled most common printer drivers into install.wim. Starting with 1809 they’re no longer included, and must be obtained via WU.
Why Did Print Scan Drivers Move to Windows Update?
The short answer is: “Saves space.” Previously, MS included a large number of print drivers with an OS image. Add a lesser, but still substantial number of scanner drivers. It means multiple gigabytes of stuff (even highly compressed). Pushing them into Windows Update means they won’t load locally during the install process. Instead, the device enumeration after the upgrade picks them up. Then, Windows Update hooks them up with your printers. That’s why MS says “In most cases, there is no noticeable impact due to this change.”
Here’s an interesting tidbit. “When you upgrade to Windows 10, version 1809, your installed printers will continue to work using the same printer driver as before.” This speaks to my long-held belief that the installer grabs and saves currently installed drivers from the pre-upgrade OS. Thus, it can make them available in the post-upgrade OS. New print drivers will indeed come from WU going forward, though. If WU isn’t available, drivers aren’t installed automatically for new printers (except for Mopria (“modern Wi-Fi printers”) compatible devices).
[Note: thanks to Sergey Tkachenko at WinAero.com who brought this change to my attention.]