On Friday, MS went through the unusual step of releasing two versions of the lastest Fast Ring Insider Preview. At first, an initial version 19002.1 proved likely to cause restart issues. Later that day, MS issued 19002.1002 to correct same. Through sheer dint of struggle, I managed to get both of my test PCs updated to 19002.1. However, Windows Update (WU) proved unwilling or unable to offer those machines the CU for 19002.1002. Thus, I turned to uupdump.ml, and an ISO for the 19002.1002 build. That’s when things got interesting from the ISO mount perspective, and reminded me that multiple ISO mount strategies prove helpful.
It took a couple of tries, but I was able to mount the ISO after copying it onto the OS drive. Installation via setup.exe was a snap thereafter.
Why Did Multiple ISO Mount Strategies Prove Helpful?
Using uupdump.ml on my production PC ultimately produced a file named
19002.1002.191017-1454.VB_RELEASE_SVC_CLIENTPRO_OEMRET_X64FRE_EN-US.ISO It is 4.07 GB in size — not at all atypical for a current Insider Preview ISO. Because I planned to use it on two machines, I figured I’d want to copy it to my fastest SSD-based external USB drive. Right now, that’s a 1 TB Samsung 970 EVO NVMe mounted in a Sabrent EC-NVMe enclosure. However, when I attached the device to my Lenovo X380 Yoga, while Explorer “saw” the drive and the ISO file, it refused to mount. In fact, Explorer hung at “Working on it” and the virtual drive never mounted.
That’s what led me to a different strategy. Instead of trying to mount the ISO from the external drive, I copied it to an older (and slower) Mushkin Ventura Pro 64 GB USB 3.0 flash drive. Then I used that drive to copy the ISO file to the local hard disk on each of my two Fast Ring test machines (the aforementioned X380 and a Lenovo X220 Tablet). From the local OS SSD on each machine, I knew I’d get the fastest install performance anyway. So that’s how I did it. And indeed, both machines are now updated to 19002.1002, as the preceding screencap shows.
What Happened to the USB 3.1 Sabrent NVMe Drive?
Only this morning did I finally get a clue about why the ISO wouldn’t mount from the external NVMe-based device. Preparing to write this blog just now, I plugged it in again to the X380 Yoga’s USB-C/Thunderbolt port. This time, I got an error message from Explorer that helped me understand I had an issue. Here ’tis:
Oho! Seems that the 1 TB Samsung device wants more power than the USB-C port on the X380 Yoga can deliver. That explains the “interminable” mount it presented Friday.
What I don’t understand is why Explorer didn’t produce this error message on my initial attempts to use the device. Had it shown up immediately, I would not have made multiple tries to get it working before moving onto a different strategy. And it’s why I’ve always got a fallback or alternate strategy planned, whenever I work on installation, problem-solving, or troubleshooting tasks. Expecting failure makes it much easier to face and deal with when it happens, as it sometimes will. But that’s how things go sometimes, here in Windows World.
I’ve got another Belkin dock here at Chez Tittel now (Thunderbolt 3 Express Dock HD). This one has its own external PSU, and is able to deliver up to 85 W of charging power through the USB-C port. Presumably that means I should be able to use it to hook the Sabrent Device up to either of my X380 Yoga PCs. I’ll make that part of my testing when I post a mini-review of this device here at Windows Enterprise Desktop later this week. Stay tuned!
Man! I’ve had quite the afternoon today. Earlier, Microsoft dropped the latest Fast Ring build for 20H1. Numbered 19002.1, it’s raising hackles among many of its recipients. In fact, for the first time in I can’t remember when, the new build worked on neither of my two Fast Ring test machines. It took me over two hours to finally stumble across a solution for my Lenovo X380 Yoga unit. I haven’t yet upgraded my older Lenovo X220 Tablet PC. The primary symptom of trouble is widely reported (see this TenForums thread, for example). The setup phase while the old OS is in control proceeds until the first reboot occurs. But then, the PC goes into Restart (with spinning balls) and hangs there forever. Microsoft acknowledges this is indeed a problem and recommends some potential workarounds (see this Answers.Microsoft.com post dated 10/17). But none of that stuff worked for me. That’s why I believe Insider Preview 19002 poses peculiar problems for installers. Let me explain. . .
Getting to the latest version of the Insider Preview poses multiple, unusual challenges.
Why Say Insider Preview 19002 Poses Peculiar Problems?
Without getting past the initial reboot, Win10 installation can’t succeed. I tried everything I could think of on the X380 Yoga. But it wasn’t until I disconnected all USB devices, and popped out the SDXC card, that restart completed. I’d remembered a similar problem on earlier Insider Previews with my Surface Pro 3. Then, too, removing those devices allowed the machine to reboot successfully. Worked on the X380 Yoga, too. After that, the actual upgrade was pretty quick. Less than 15 minutes later, the desktop was available. That’s where I captured the preceding screenshot.
When the install completed, I’d lost my fingerprint reader. Having experienced this before, I went into Device Manager and reinstalled the on-disk device driver. That pretty much takes care of the X380 Yoga, which I must now clean up and back up to complete my usual post-upgrade drill.
The X220 Tablet Proves More Resistant
Unplugging the USB devices didn’t result in a successful restart on this machine. I could reboot successfully using the MS Answers workaround, though. For the record it’s shutdown /r /t 0 /f in an administrative PowerShell or cmd.exe session. I visited UUPdump.ml and grabbed the files necessary to build an ISO for 19002.1, then did just that on my project PC. I copied the ISO to a local drive on the X220 T, mounted it as a volume, and am running setup.exe from that volume right now. It’s 76 percent through the GUI install phase, so I still don’t know if this retry from code that didn’t come from Windows Update will actually surmount the reboot hurdle. I’ll keep blogging though, until I see what happens.
As I took a break for dinner with “the Boss,” this latest install did get through the first reboot and is now 77 percent through the post-GUI “Working on updates” phase. That means it’s already rebooted at least 2 and possibly 3 times, so apparently this approach has worked. I’m not sure if it was removing the USB external drive and the SD card that did the trick, or switching to the UUPdump-based installer. Whatever it is (or was), I’m just glad it got me over the hump. And so it sometimes goes, here in Windows-World!
Concluding Note: Success!
The X220 Tablet just showed me a lock screen, and is now working through the “Getting a few things ready” prior to initial boot. In fact, I’m now on the desktop and 19002.1 is in charge. What a relief! As is so often the case with Win10, where there’s enough will, there’s a way to get it installed.
Here’s an interesting one. I couldn’t back up my Surface Pro 3 lately, because Macrium Reflect keeps failing right as the backup completes. In fact, the external USB drive I plug into the Surface Pro dock disappears from Explorer at the same time. Bizarre! That’s what had me figuring what’s involved in fixing Surface Pro USB drive drop this morning. An anomalous default registry setting on the Surface Pro 3 knocked out a whole raft of Power Options settings. This included the USB selective suspend setting, which I immediately suspected might be causing my problems. Poking around online I used “unable to unlock power options Surface Pro” to find what turned out to be a working solution.
When I first dropped into Power Options, USB settings — and a bunch of other stuff — was MIA. WTF?
Registry Edit Key to Fixing Surface Pro 3 USB Drive Drop
In researching the missing Power Options settings, I found a post from a NIC maker (ekahau) that mentioned a weird default in the Surface Pro registry setup. It turns out that
HKLM\System\CurrentControlSet\Control\Power\CsEnabled is set to “Enabled” (value: 1) on Surface Pro PCs (HKLM is an abbreviation for HKEY_LOCAL_MACHINE). This not only drops a bunch of settings from the Power Options control panel widget, it also sets the USB selective suspend to the “on” state in an unchangeable way. By modifying the value for that entry from 1 (one) to 0 (zero), I got the missing setting back in Power Options. Immediately after this change, Macrium Reflect backup completed successfully. To be on the safe side, I disabled it anyway when the unit is docked (or running off A/C power).
I’m incredibly glad I found the right search string for this still-mysterious Power Options setting. I’m not sure what changed recently on my Surface Pro 3, either through Windows Updates or firmware upgrades, to break what had been working since time immemorial. I am, however, relieved to find backup working properly again, and my external USB devices remaining attached and visible in Windows 10. FWIW, it’s running Build 18362.10022, which I believe is the latest Slow Ring Insider Preview release. There may have been something in this code base that mucked around with the power options and related USB settings. Who knows?
Interacting with devices (and drivers) via RDP session uses redirection so what shows on one PC appears on another’s display. A quick look at the Display control in Settings shows what I mean:
Notice the text in red that reads “The display settings can’t be changed from a remote session.”
In a similar vein, the Output Device under Sound → Output is labeled “Remote Audio” (and no other output options appear in that pulldown list). In general when using RDP, you have to understand that certain resources that are normally purely local — display, keyboard, mouse, audio, and so forth — get mapped from the remote host PC (the one to which another PC connects remotely) to the RDP client (the PC through which the remote connection is handled). This means that managing those resources really means working on the client side of the connection. Thus, there are things you can’t do remotely that you can do easily and directly when working at the keyboard of the remote host PC.
But Wait! There’s more…
In Devices and Printers for the Remote host on the RDP client, certain devices double up in that view. Notice, for example, the doubled and redirected entries here for Fax, Print to PDF, XPS document writer, and so forth. The remote connection “sees” RDP client local and RDP host remote devices and shows them all.
Because there’s a local copy on the RDP client as well as the Remote Host printer entries double up when remoting into another PC inside Devices & Printers. (Notice the word “redirected” appears.)
[Click image for full-sized view.]
In general, if you want to work with devices or drivers in an RDP session proceed with care. Some of this kind of thing either won’t work at all, or won’t run to completion remotely. If so, you must switch to local, direct access. Once you do that, such things usually work without issues or problems.
Annoyingly, some applications or processes won’t run, or run to completion in an RDP session
Alas, the same thing is true for some applications. Older versions of the Lenovo System Update utility, for example (prior to version 5.1), would launch in a remote session, but the application window would never fully open. Thus, it didn’t work in a remote session. As soon as the affected PC is accessed locally, however, the utility does its thing quite happily. I’ve often longed for a master list of applications “Apps that don’t work with RDP” but have never found anything like that. Such knowledge comes through trial and error. Once such an error is identified, one learns to avoid using the balky or uncooperative application in RDP thereafter.
I’ve been fooling around with the built-in Windows 10 Sandbox lately. It is indeed a useful tool for trying out unknown or potentially risky software, trial configurations, and so forth. Just for grins, however, I tried to activate the Windows 10 Enterprise license in my Sandbox. And that’s how I learned there’s no Windows 10 Sandbox activation. I’m not 100% sure it’s by design, but I think it must be. Using my Visual Studio subscription MAK (Multiple Activation Key) for Enterprise in Sandbox, here’s what I see when I try to activate the OS running inside it.
Despite entering a known, good, working Windows 10 Enterprise key the error avers that it is not “a valid digital license or product key.” What gives?
[Click image for full-sized view. Key string is blanked out for legal/ethical reasons.]
Why Is There No Windows 10 Sandbox Activation?
There are two different ways to answer that question. Each gets its own section in the text that follows.
Answer 1: Sandbox Activation Makes No Sense
First, there’s the notion that Sandbox activation doesn’t make sense. The environment is evanescent. The whole thing evaporates as soon as the sandbox is closed. Thus, it’s reasonable to argue that it doesn’t make sense to permit activation to proceed on what is by design a throwaway, one-time use operating system instantiation. I turned to a post at the Microsoft Tech Community from Hari Pulapaka, MS Principal Group Program Manager for Windows Kernel. Simply entitled “Windows Sandbox,” it’s got some great information to share. Here’s a quote that spells out key Sandbox characteristics:
+ Part of Windows – everything required for this feature ships with Windows 10 Pro and Enterprise. No need to download a VHD!
+ Pristine – every time Windows Sandbox runs, it’s as clean as a brand-new installation of Windows
+ Disposable – nothing persists on the device; everything is discarded after you close the application
+ Secure – uses hardware-based virtualization for kernel isolation, which relies on the Microsoft’s hypervisor to run a separate kernel which isolates Windows Sandbox from the host
+ Efficient – uses integrated kernel scheduler, smart memory management, and virtual GPU
Answer 2: The Sandbox Doesn’t Support Activation Capability
The second argument about activation failure is more technical. It comes from informed speculation by TenForums user Superfly. He has good cause to know what he’s speculating about. For one thing, he’s the author of the excellent and free Windows key and license discovery/forensics tool called ShowKeyPlus. For another, he’s a resident expert — if not THE resident expert — at TenForums on the subjects of Windows 10 licenses, keys, and activation. When I asked him for his thoughts on this topic, he opined that “Sandbox does not expose the services required for activation,” going on to speculate that “I think it’s by design.” He says he may investigate further to see which, if any, licensing files and services are present in the Sandbox runtime environment. If that produces any further info, I’ll update this blog post.
But for now, it seems pretty settled that MS doesn’t allow activation of the Windows 10 Sandbox because it doesn’t make sense to activate an image that is temporary and does not persist.
Note: Added 15 Minutes After Initial Posting
Indeed, it seems Sandbox is designed as “frozen OS snapshot” all the way ’round. I just tried to run Windows Update on the Sandbox and got error code 0x80070422. Further research indicates that one must check to see if WUserv (the Windows Update service is running and available). And indeed a quick jump into Services.msc confirms that the Windows Update service is “disabled.” I’d say that provides at least an indication, if not outright proof, that updates and activation don’t work in Sandbox because it wasn’t designed to accommodate such things. ‘Nuff said.
In my previous blog post, I explained my recent gyrations with Thunderbolt drivers and connections on my 8th-Generation i7 Lenovo laptops. I stated a need for actual Thunderbolt hardware to work with and use this stuff. Thanks to a near-miraculous delivery from Belkin Monday evening, I am now learning Thunderbolt technology & connections. I got an email from Belkin the week after returning from SpiceWorld 2019. Did I want one of their new Thunderbolt 3 hubs announced at that show? I replied “Yes!” and didn’t think much more about it. Thus, imagine my surprise when my wife asked Monday night “What’s in this package from Belkin?” Turns out it was a Thunderbolt™ 3 Mini Dock (Model P-F4U098). This miniature hub supports two HDMI ports, plus 1 each USB 3.0 and 2.0, and GbE (RJ-45) ports as well.
Synchronicity: not much sooner wished for, than delivered. Here’s some real Thunderbolt hardware!
[Click image for full-sized view; Source: Belkin product page.]
Hardware Is Required for Learning Thunderbolt Technology & Connections
Now that I’ve got the Mini Dock, I’m actually able to use my Thunderbolt channel for data and device communications. It’s puzzling to me, however, that Belkin doesn’t include a USB-C/Thunderbolt pass-through connection on the device. Given that one of Thunderbolt’s major selling points is its ability to handle up to 40 Gbps per channel (20 in each direction, full-duplex), I’m stunned that HDMI is the only high-speed link on this device and that its only USB ports are 2.0 and 3.0 (not even 3.1). Be that as it may, I’m now learning a bit about the ins and outs of Thunderbolt (pun intended). Here’s what Thunderbolt Software (available through the Thunderbolt symbol in the notification tray on the Taskbar) tells me about itself:
After my recent driver install shenanigans, it’s nice to see that everything is current and correct.
I can also see my lone Thunderbolt device — the Mini Hub, of course — in the Attached Thunderbolt Devices widget as well (all Thunderbolt function are available with a right-click to its notification tray item). Here’s what that looks like:
I can see the hub, but the Thunderbolt software stays mum on what’s attached to it. Weird!
I figured the tool would show me device chains attached to the hub. Wrong! Nirsoft USBDeview showed me the goods when I plugged in a USB 3.0 flash drive to the hub’s USB 3.0 port. I was also surprised to understand that one must reboot Windows for a device plugged into the Thunderbolt hub to show up in Explorer (and be otherwise accessible to Windows). It’s not exactly the same as USB, where one can plug in or unplug devices and see their status change in real time. Thunderbolt is fast and, as the hub shows, can aggregate lots of services (video, networking, and USB storage) onto a single channel.
Where the Thunder Bolts from Here
I’m still getting the hang of this stuff, though. The FAQ from the Thunderbolt Technology Association (ThunderboltTechnology.net) has so far proven pretty illuminating. Given Intel’s emphasis on DisplayPort video therein, I’m thus a little puzzled about why Belkin elected to include 4K 60Hz HDMI ports instead. As I mess around with this Mini Dock, I immediately get the appeal of Belkin’s higher-end, more expensive full-size docks: they include up to 2 USB-C Thunderbolt passthroughs, GbE, DisplayPort, and a headphone jack, as well as external power (and thus also, charging support for laptops). Gosh! I’ve got a whole new product space to learn. This should be fun . . .
A famous quote from Joseph Heller’s Catch-22 reads “How can he see if he’s got flies in his eyes if he’s got flies in his eyes?” I was reminded of that snippet while chasing my tail this weekend. I wondered why I saw no Thunderbolt device in Device Manager on my Lenovo Thinkpad X380 Yoga laptops. Only gradually did I recall that because I have no Thunderbold devices, nothing SHOULD show up anyway. Only after spending some time chasing Thunderbolt drivers down, I realized that “Show hidden devices” might help. Here’s what that showed me:
Took me a while to remember, but drivers without removable devices using them only show up when “Show hidden devices” is checked. Sigh.
When Chasing Thunderbolt Drivers Down, Don’t Forget the Rules
How did I figure this out? I knew I had successfully installed both firmware and driver updates for Thunderbolt, because their installers reported successful completion. Indeed, when I ran DriverStore Explorer (RAPR.exe), it happily showed me a Thunderbolt item.
Note the item in blue at the bottom of this list. It says Thunderbolt(TM) Controller – 15BF at the far right.
[Click image for full-sized view.]
Only then did I smite my forehead and quote Homer Simpson: “Doh!” A quick click on “Show hidden devices” in DevMgr and there was the ghosted/greyed-out listing I knew had to be in there somewhere.
Because I don’t own any Thunderbolt devices — yet — I am currently unable to make this item appear in normal text in Device Manager without using my head just a little. Interestingly enough, though, it does show up on my Lenovo X1 Extreme. It includes a pair of Thunderbolt ports and a controller to manage them. Thus, it always has “something” going on in the Thunderbolt department even with no Thunderbolt devices attached. Here’s what that looks like when viewing attached Thunderbolt devices on that PC (available as a right-click option from the Thunderbolt icon in the right-hand app listing on the notification pane/area):
Now, I *need* to acquire some Thunderbolt hardware so I can really start understanding this stuff. Yeah, that’s the ticket!
Boy howdy! MS has been pushing updates at a furious rate lately. Just yesterday, KB4524147 bumped production-level 1903 to Build 18362.388. That install went swimmingly on 4 of 5 machines on which it was run. But machine #5 — my production desktop, as fate would have it — threw an interesting error code on the first try. That code is 0x80242016. According to MS Docs Update Error Code Reference, it indicates that “The state of the update after its post-reboot operation has completed is unexpected.” As far as I can tell, this means that something odd about the state of the update registers following the reboot. Thus, it shows up in Update History as “failed.” Obviously, because not even Microsoft knows what’s up in this case, this mystery error code 0x80242016 follows KB4524147. Here’s a snapshot:
Something unexpected showed up the first time I attempted a KB4524147 install. Fortunately, the second try succeeded.
[Click image for full-sized view.]
When Mystery Error Code 0x80242016 Follows KB4524147, Then What?
My reaction recaps the old saying that begins: “If at first you don’t succeed . . .” And indeed, as the preceding screenshot shows, a success followed the initial failure on a second try. But I’m mystified as to what happened on my production PC. But not even Microsoft can tell for sure, apparently. I monkeyed around with a Registry key for Windows Update memory reservation before that reboot, though. And because this apparently causes deep changes to the way Windows Update behaves, that change could very well have messed with successful completion of the KB4524147 update. But I’m definitely guessing here.
Above all, I’m bemused by an encounter with an error code that essentially says “Something unexpected happened after reboot, so the update is cancelled.” Things do go sideways occasionally with Windows, as I’ve observed on many occasions. I guess I should be grateful that what failed on the first try, succeeded on the second. Otherwise, I’d still be trying to figure out — and fix — whatever it is that went wrong. Had that second attempt failed, my series of next steps would have been as follows (each subsequent step assumes the preceding one has failed):
1. Download the KB4524147 manual self-installing update package from the Microsoft Update Catalog (32-bit, 64-bit, ARM64), and attempt a manual install.
2. Use DISM to apply the update package on an offline version of the OS image.
3. Perform an in-place upgrade install of 1903, and attempt the update again on a cleaner OS.
Surely, one of those would have done the trick. But if not, it would then be time to ponder a clean re-install of 1903, or a wait to see if the next cumulative update works instead, with a fallback strategy of upgrading to 1909/19H2 when it becomes available in the next month or two. And so it goes, here in Windows-World!
I’ve been experimenting with the new Windows Sandbox (available in 1903 and higher-numbered Preview builds) lately. This morning, I found myself in a pickle. I was using RDP to access my Lenovo X220 Tablet, with the Sandbox window maximized therein. A key sequence restores the Sandbox from whole screen to partial screen mode — CTRL-ALT-BREAK. But alas, that’s the same key sequence that does likewise for RDP sessions as well. So, when I tried to reduce the size of the Sandbox window to access the RDP session outside the sandbox, I ended up reducing the size of the RDP session window instead. That’s why I assert that RDP plus Sandbox sometimes equals screen confusion. Ultimately, I ended up having to close my RDP session and walk over to the X220 Tablet keyboard and minimize the Sandbox window directly on its host machine.
As long as I don’t maximize the Sandbox session in the RDP session Window on the remote PC, everything is OK.
[Click image for full-sized view.]<\p>
Why Say RDP Plus Sandbox Sometimes Equals Screen Confusion?
I’ve already explained that the key sequence to exit full-screen mode is the same for both tools. That makes the attempt to reduce one (the Sandbox inside the RDP session) reduce the other instead (the RDP session). I couldn’t figure out any way to minimize the Sandbox window within the RDP session without using the keystroke sequence. Then I started poking around the user interface at the top of the screen. With the Sandbox maximized, its control bar sits right underneath the control bar for the RDP session. So I found a “trick” that actually works. Here’s an image to help explain:
If you look very closely just to the right of the top RDP bar, you can see the edge of the restore button in the underlying Sandbox bar.
If you can catch and click that edge of the Sandbox minimize control, things work as they should. But it took a bit of wingling about, and thinking about how the controls worked and where they were placed to come to this happy conclusion. Go figure!
Thanks, Mr. Brinkmann! He posted a Ghacks.net item yesterday that alerted me to a fascinating Microsoft Tech Community blog post dated September 26. Entitled “Using machine learning to improve the Windows 10 update experience.” It comes from a pair of MS data scientists named Archana Ramesh and Michael Stephenson. Their story basically explains that MS monitors up to 35 “areas of PC health.” (Each is a collection of devices and/or facilities that could be subject to driver or installation issues.) Machine Learning (ML) lets the company use this data to offer updates to some PCs, but not others. This graph compares uninstalls, crashes and driver issues for ML-selected systems versus the whole population (baseline):
Note: for Kernel Mode Crashes and Driver Issues, the ML model selected PCs experience fewer problems than the baseline.
[Click image for full-sized view.]
Why MS Explains Machine Learning Role in Windows 10 Update Experience?
Basically, MS gathers information about Windows PCs and their configurations. This data gets crunched so machine learning can identify PCs for which updates work. This data comes from the Insider program, or others who voluntarily opt to install certain updates. Those configurations that work well are noted, for inclusion in the update offer. MS also recognizes likely problem PCs. Their receipt of an update offer becomes contingent on a fix for one or more blocking issues becoming available. Only when fixes are in place, is an update offer extended. The following flow chart visualizes this process:
Machines whose attributes indicate they’ll have no problems get the update offer. Those likely to face issues don’t come into play until fixes for expected issues are available.
[Click image for full-sized view.]
To me, this provides yet another good reason why Windows 10 users should permit MS to grab telemetry info from their PCs. Though certain suspicious individuals routinely silence their Windows 10 PCs and prevent them from “phoning home” to Microsoft, this kind of data is absolutely invaluable. And indeed, in my own experience, MS continues to improve in its detection of PCs likely to succeed with specific updates (and those likely to hit snags as well).
The authors also provide one of the best explanations of so-called safeguard holds I’ve seen anywhere from Microsoft. Look for a section entitled “Identifying safeguard holds” and read it over. It shows exactly how ML recognizes PCs that need them, and can make a big difference for users and IT pros alike.