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.]
I attended SpiceWorld earlier this week. There, I got into a discussion with some fellow SpiceHeads about how to avoid unnecessary elevation of privileges for users. Sure, you can give regular users admin accounts. But if your reason for doing so is to let them run one or more specific applications with admin privileges, there’s a better way. Sordum.org’s RunAsTool elevates privileges per application. Using this tool, you can create shortcuts for users that let them run individual applications with elevated privileges. Then you don’t have to grant them blanket admin access.
Admins can drag and drop .exe files from File Explorer into RunAsTool to add them to the mix.
How RunAsTool Elevates Privileges Per Application
The tool has two user interfaces: one for admin accounts, the other for standard users. In the admin UI (only in admin accounts) one can drag and drop any program to grant it admin privileges. Once added, click the radio button to “Run as administrator.” (See preceding screen cap.) Once defined, admins can right-click any such programs they’ve added and then create a shortcut on the standard user’s desktop. Those users can run the elevated program in the RunAsTool UI to take advantage of those enhanced capabilities and access.
Unnecessary elevation of accounts raises the risk of damage or compromise should if the account gets hacked or penetrated. It’s much safer to elevate only those applications that need (or won’t run without) elevated privileges. This prevents a hack of the account from granting a malefactor admin level access to the user’s PC (and possibly beyond). Security nerds call limiting access strictly to what’s required “the principle of least privilege.” It’s a principle worth following, if you ask me, and the RunAsTool helps to make that practical in environments where some applications need admin rights to run or work properly. ‘Nuff said.
For the past two days I’ve been wandering the halls of the Austin Convention Center, along with two-plus-thousand fellow SpiceHeads. This humble Pimiento is palling around with Habaneros, Serranos, and a Ghost Pepper or two. I even saw two Pure Capsaicins achieve the spiciest of all designations Tuesday morning. More important, I interacted with a few dozen attendees one on one. From them, I’ve learned that Jeremy Moskowitz’s Win10 Migration survey — about which I blogged here on July 20 — captures this audience very well. And that’s why I say SpiceWorld 2018 confirms Win10 migration intelligence. In fact, I hope my presentation this afternoon on the Moskowitz survey will be well-received. (Note: registration required to download this 20-page PDF document).
There’s nothing restrained or dainty about the SpiceWorld 2018 show logo. That’s in keeping with the company and its community of smart, opinionated and passionate IT pros.
Why Say SpiceWorld 2018 Confirms Win10 Migration Intelligence?
Moskowitz reports that smaller businesses are further along with migration than medium or large ones. Thankfully, this fits entirely with what I learned from my fellow show-goers. It also matches with results that Spiceworks analyst Peter Tsai compiled for the company’s 2018 State of IT report. If anything, SpiceHeads are ahead of this curve. (SpiceHeads is the self-mocking self-description that Spiceworks community members prefer most. As they gain community cred, pepper rankings move up the Scoville scale.)
That’s no surprise to me, considering how much these folks care about IT and related best practices, tools, and technologies. Helping SpiceHeads find the right vendors for technology acquisitions, and vice-versa, helps explain Spiceworks’ raison d’etre. Shortening the sales cycle, reducing wasted sales efforts, and sparing IT folks unwanted cold sales calls got multiple mentions during various keynotes.
Meaningful Uses for AI and Machine Learning
The online community of Spiceheads now numbers about 7 million, says Spiceworks’ Community Manager Sean Dahlberg. On its forums, the same questions and concerns repeat in posts, threads, and discussions. “That means some or lots of duplication” says Dahlberg. “We put AI to work to group similar items together and show them to community members in search responses.” Next, he goes on to observe that this aggregation takes some interesting parsing and organizing. However, recent tests show that combining answers and pointing to best replies saves readers time. How much? “About 8 person-years per month. That compares to old-fashioned search results that require members comb through numerous threads. They have to extract the good stuff themselves. New AI-based results present a summary of threads, and show best answers right away.”
To my thinking, this is great use of intelligence that Spiceworks has collected for some time. According to SVP Manish Dixit, the company carefully anonymizes data before moving it into datasets. Only then are they used for machine learning, statistical analysis, and predictive analytics. In fact, Spiceworks is really keen on helping the community identify and find good advice, tools, technologies and partners. At the same time they want to provide value to sponsors and advertisers.
Ideally, Spiceworks wants to link vendors with self-selecting prospective buyers or clients before the parties meet. Helping buyers and sellers save time, make good connections, and find best of breed options are all good things. That’s the kind of market improvement that anybody can get behind. Overall, Spiceworks is doing a better job of this than most organizations that serve large technical communities in an ad- and sales-based revenue model. Great stuff!
Wow! What a wild ride at Microsoft last week for Windows 10. On Tuesday, October 2 1809 was released. By Friday reports of bugs – especially a nasty one that “lost” files from the C:\Users folder hierarchy – led MS to withdraw 1809 from circulation. Some people who successfully installed 1809 might need access to an 1809 ISO (the installer image file, to be more precise) for repairs. That’s why an alternate Win10 source during hold period (until MS lets go of another release) could be a life-saver. Check this out:
Note that the Heidoc.net Windows ISO Download Tool still offers access to an 1809 ISO.
[Click image to see full-sized view.]
Heidoc.net: Alternate Win10 Source During Hold Period
I’ve blogged here before about Heidoc.net/Jan Krohn’s Microsoft Windows and Office ISO Download Tool. The foregoing screenshot shows that they’ve grabbed and still offer copies of the ISOs for 1809 for Home/Pro, Education, and more. Thus you can use this tool to obtain a copy of what MS has withdrawn from circulation. Because it does contain well-reported bugs, this is something you should consider carefully before messing around with. You should also make a complete image backup of your system drive and create recovery media before attempting an install in the face of possible gotchas. And please: don’t say I didn’t warn you!
If It’s Broke, Why Use It?
A TenForums poster this morning bemoaned the lack of access to an 1809 ISO this morning, because she wants to perform an in-place upgrade repair install to try and fix some Wi-Fi driver issues on a PC she’s already upgraded to that release. I recalled seeing an earlier post on a different topic that reported Heidoc.net still offered the 1809 ISO and used the program to produce the screen cap shown above. Proof positive that in this case, where there’s sufficient will and knowledge, there’s still a way to lay hands on an 1809 ISO.
Earlier this week, MS released the 1809 October 2018 version of Windows 10. This happened on Tuesday, October 2, in a somewhat less orchestrated fashion than for previous such releases. I blushingly confess I got caught in a snafu. Because the Download Windows 10 page said “Windows 10 October 2018 Update now available,” I assumed the Media Creation Tool (MCT) had likewise been updated as well. Wrong! That’s why it’s essential to check those Win10 Installer UFDs for version info before using them. In my case, that meant I did an in-place repair upgrade on one of my PCs from 1803 back to 1803. No harm done, however, and quickly replaced with 1809 when I realized my mistake. Sigh.
I didn’t realize that this message didn’t necessarily mean the MCT had also been updated. For a short while, in fact, that was a very bad assumption.
How to Check Those Win10 Installer UFDs
It couldn’t be simpler to check the Windows version for any Win10 installer. All you need to do is look at the details tab for the setup.exe file.
The details tab in setup.exe properties shows Product Version info. That’s the tell-tale!
To discriminate 1803 from 1809, you need to know that 1803 corresponds to version 10.0.17134.1, while 1809’s version is 10.0.17763.1. This is shown in the two side-by-side Properties windows above for each version’s setup.exe file.
If I’d only thought to check I could’ve avoided my mistake. By the time you read this, it won’t be possible to “accidentally” download the 1803 installer using MCT any more. But if you’re like me, you have numerous Windows 10 installer UFDs at your disposal. Now you know how to check what you’ve got for version numbers. Then you can use Microsoft’s Windows 10 release information page to map those numbers to the corresponding four-digit version IDs (1809, 1803, and so forth). Enjoy!
Yesterday, MS released Windows 10 1809. It took them a while to get the release pushed out through all channels. I was able to get to it first through the Media Creation Tool on the Download Windows 10 page. But within an hour, the Update Assistant and Windows Update also proved viable as upgrade sources. After all the dust settled on this latest release, I noticed some Interesting 1809 disk layout changes for the OS boot/system disk. Here is a before and after shot (from 2 different PCs):
Disk layout before upgrade above, after below. Note the new, 498 MB OEM partition that appears at right.
[Click either image for full-sized view.]
About Those Interesting 1809 Disk Layout Changes
Looks like the minimum or allowable size of the WinRE partition has gone up again, with the 1809 release. Both before and after shots feature a 450 MB OEM partition at the head of the disk. However, use of the reagenct /info command on before and after machines shows different WinRE locations. On the before PC, the partition is number 1 (first place from top figure above): a 450 MB NTFS partition. On the after PC, the partition is number 5 (immediately following the OS partition): a 498 MB NTFS partition.
Message traffic on TenForums also tells me that users who upgraded with WinRE partitions of 498 MB or larger in size found their disk layouts unaltered. That tells me the existing WinRE partition was preserved and its contents replaced during the upgrade process. Those PCs, like mine, who had the “old standard” 450 MB WinRE partition will find a new and bigger (498 MB) WinRE partition in their disk layouts as well. Most likely, it will be positioned immediately following the OS partition (from which the installer steals the space necessary to accommodate the 498 MB disk extent).
Why Use Two Different Tools to Show Disk Layouts?
I used the MiniTool Partition Wizard (MTPW) to show the disk layout on an already-upgraded machine. I did that to confirm that the reagentc /info output was correct. It read:
Because diskmgmt.msc does not show the 16MB Microsoft Reserved (MSR) partition, but MTPW does, you can count from left to right yourself, and confirm that the new 498 MB NTFS WinRE partition does indeed occur in position 5 on that drive. That’s why I highlighted (bolded) “partition5” in the preceding output string.