Windows 10 Insider Preview releases have been flying thick and fast recently. On August 10, we saw Build 17735. On August 14, Build 17738. And on August 17, 17741. That’s three in an 8-day period. The latest build — 17741 — also has another distinguishing characteristic. It shows that Win10 Version 1809 makes official debut, as this screen capture from WinVer spells out:
Look carefully: Second line of small-print text reads “Version 1809 (OS Build 17741…” No more wondering!
[Click image for full-sized view.]
Visual Proof: Win10 Version 1809 Makes Official Debut
With less than two weeks left in August, it certainly seems possible that 1809 actually *could* appear in September. After all, 1809 means “the ninth month of 2018,” which indeed falls next month. But the actual release date will depend on bugs in need of squashing, fixing, or otherwise addressing when a golden release — of which 17741 is merely the first possible such — hits the Insider population.
If recent history is any quide, Version 1809 won’t be publicly released until some time in October. Think about it. 1703 has an 4/5/17 release date; 1709 a 10/17/17 release date; and 1803 a 4/30/18 release date. Unless some kind of minor miracle manifests, I’m strongly inclined to think that 1809 will hit the streets in October, rather than September, Version number aside.
But hey: at least we now have official confirmation from Microsoft that the next version number, as promised, will indeed be 1809. That’s something, right? The next versions of Windows 10 will switch away from two-digit month numbers to H1 for the first half of the year, and H1 for the second half. That gives MS a LOT more latitude to make sure the next release is rock-solid before making it public. After all, 19H1 (as the upcoming new nomenclature should have it) isn’t over until June 30, 2019!
I’m totally in favor of focusing on stability and functionality over hitting an arbitrary release date. Maybe MS is giving itself more wiggle room with the new naming scheme. But as long as they use it to make doubly darn sure that Windows 10 Feature Upgrades are rock-solid and ready for prime time, I’m all for it. We’ll see how that works out sometime in the second quarter of 2019. Stay tuned.
If you search the Registry on installations of Windows 10 Pro or higher versions (Enterprise, Education, Workstation) you can find all kinds of interesting stuff. Case in point: those who look will see that the Win10 registry includes AllowExperimentation key. It appears in two locations, in fact:
Kind of makes you wonder why it’s there, and what it’s for, right?
What’s Up with Win10 Registry Includes AllowExperimentation Key?
I learned about this at TenForums, thanks to an eagle-eyed, long-time member and guru there whose handle is “dalchina.” He produces a screen from the German freeware program O&O Shutup10 to explain things a bit:
Hmmm. This sounds interesting, but also a little scary. What’s the real deal here?
[Click image for full-sized view.]
MakeUseOf Sheds More Light…
Obviously, there’s more going on here than meets the eye. An article from technology website “MakeUseOf” (aka MUO) sheds a little more light on the subject. It’s entitled “How to Disable Microsoft’s Settings Experiments in Windows 10,” and it too makes an interesting read. It’s not completely accurate any more, though. Before I explain, here’s what it says (quoted verbatim, ‘cept I added a link to ShutUp10 and some highlights):
One of the newest changes allows Microsoft to “conduct experiments” with the settings on your PC. It’s not present on the stable version of Windows 10, and only exists in the Pro and higher versions. This suggests that Microsoft might be testing it with Insiders for a full release later. You can disable this experimenting with a simple tweak if you like.
The easier method is using the Windows 10 privacy tool ShutUp10, which includes a switch to Disable conducting experiments with this machine by Microsoft. Enabling this option changes a Registry value, which you can do on your own if you don’t want to use the privacy tool.
The first highlighted passage doesn’t match my hands-on checks yesterday and today. Indeed, I found these keys in Insider Preview builds 17738.1000 and 18219.1000. These are the current Insider Preview Fast Ring and Skipeahead Builds, respectively. But I also found them in the latest production release on half-a-dozen PCs running the 177134 build. Interestingly, they don’t appear in both …current.. and …default… locations in the Insider Preview versions, but they do appear in both places in the production builds.
Looking to the Registry
Here’s what that registry key looks like in the …default… location (see graphic for complete key specification):
There’s a surprising amount of information associated with this key.
According to the MUO story the value of the key in the …current… location determines its status. It reports a 0 (zero) value disables the setting, 1 (the default) allows experimentation with device settings, and 2 allows “full experimentation” (whatever that means). On PCs running 17134, this value was set to 1 (I guess that’s why it’s identified as the default value) in the …current… location. Again: it was absent in that location on the Insider Preview PCs. Seems completely reversed from what I expected, but there it is.
Should You Be Worried?
When things like this pop up in the media, a certain alarmist constituency that I lovingly like to identify as the “tin-foil hat brigade” tends to sound off loudly. I’m not so sure it’s a big deal one way or the other. Certainly, on Insider Preview PCs, I’d say something like this is fair game as part and parcel of obtaining the feedback that people who join the program agree to provide. As far as PCs running public release builds go, I’m not inclinced to worry myself. But if you are, feel free to reset the key’s …current… value to 0 (zero) to make sure it’s turned off. Easy to do, and might confer some added piece of mind.
Found myself on an odd track this morning. I started playing with reagentc and diskpart at the command line. Next thing you know, I discover the boot prompt for the recovery partition on my Lenovo T520 isn’t working. This leads me on a quest to set things back to rights. So, I start researching how to add recovery partition to Win10 boot menu and work my way to a quick fix. It’s working once again, thanks to NeoSmart Technologies excellent EasyBCD program. A couple of contortions proved necessary, with able assistance from MiniTool Partition Wizard free (MTPW).
Use EasyBCD to Add Recovery Partition to Win10 Boot Menu
In theory, it’s incredibly easy to add this entry into the boot menu. I show this on a screen capture that populates the fields for the Portable/External Media entry at the bottom of the EasyBCD program window. Those selections should be:
- Type: WIM Image (Ramdisk) [Tells the PC to boot to a ramdisk image loaded from the Windows recovery image file, WinRE.wim]
- Name: Call it what you will (I picked Win10 Recovery because it tells it like it is)
- Path: Because you can’t see the whole thing here, it’s actually “X:\Recovery\WindowsRE\Winre.wim” Accessing this path is what makes MTPW necessary to use EasyBCD
To provide a new boot entry, you must provide a valid path to the image file used for booting. That’s where MTPW comes into play…
How MTPW Makes This Maneuver Possible
Simply put, you can’t use this command unless the path specification is valid. That means you must temporarily assign the target recovery partition a drive letter, so you can point to the Windows Recovery image file (WinRE.wim) that you’ll use to boot from. MTPW lets you right-click that partition easily, then select “Change Letter” from the pop-up menu that presents. Change the default “None” to an available drive letter (I used X:). Then right-click the same partition again and select “Explore” from the pop-up menu instead. Use this to navigate to the file named “Winre.wim,” as shown here:
You can use the explore data to craft a complete and valid path to the WinRE.wim used for recovery boot.
[Click image for full-sized view to enhance legibility.]
Once you’ve done this work in MPTW, you can open EasyBCD and enter a valid path string for WinRE.wim. If it works, you’ll see something like this in the “View Settings” tab for EasyBCD after you Add New Entry as shown above:
Handily, EasyBCD resolves the boot file reference into terms that don’t use a drive letter value, so they persist even when the drive letter goes away!
As your final step, jump back into MPTW, right-click the recovery partition and assign it the old default value of “None.” That’ll keep the file system from bugging you about running out of space on that partition in the future. That’s it!
Something interesting happens on Windows 10 systems with Logitech mice and unifying transceivers. Go into Device Manager, and turn on “Show hidden devices” in the View menu. On such PCs, you’ll see a usually hidden device category called “DriverInterface” show up. On systems with a Logitech mouse and unifying transceiver (UT for short), at least two Logitech Driver Interface devices appear. In figuring out more about Logitech Driver Interface drivers, I’ve learned what the icon question mark means. To begin, here’s what these items look like on most of my Logitech-equipped PCs (5 of 9 here at Chez Tittel):
All three items include blue question marks. What’s that about?
The Question Mark in Logitech Driver Interface Drivers
Turns out that the blue question mark has a specific meaning when it shows up in Device Manager. Here’s a table from a Lenovo web page entitled “What does the icons mean in Device Manager” [sic: should of course be “What do the icons mean in Device Manager?”].
Here are symbols that can appear on DevMgr icons, with associated meanings.
[Click image for full-sized view.]
As you can see (or perhaps not) a question mark comes with an explanation. It reads “This indicates that an exact device-specific driver is not available, and that a compatible driver has been installed.” Curiously, driver information appears as normal and unexceptional in the Driver tab for that device, as follows:
Things get interesting when you click the “Driver Details” button (outlined in blue on the preceding screenshot). Normally, this is how one produces vendor IDs and other useful descriptive information about an underlying physical or virtual device. But here, we get none of that. This is what shows up instead:
What’s It All Mean?
This final message in the sequence tells us everything we need to know. Microsoft provides a compatible driver (as the question mark indicates). But that driver is neither needed nor used. It’s not even loaded, as the response window clearly states. This also tells us why these items don’t show up unless we force them to appear with “Show hidden devices” in Device Manager. Because they’re not needed, loaded, or used, DevMgr need not show them to us, either. I’ve been trying to “fix” these for years. Now I finally understand that no fixing is needed, because there’s nothing going on here anyway. Go figure!
With the upcoming release of Windows 10 this fall, Version 1809, the Snipping Tool may be no more. Those who run the Skip Ahead version of the Insider Preview can see a warning to that effect. In essence, this says “NoMo Snipping Tool Try Screen Sketch instead.” Here’s how this looks in the Snipping Tool screenshot from Skip Ahead Build 18204.
I was amazed to learn that the old familiar Snipping Tool actually dates back to Windows XP Tablet PC Edition from 2005. I didn’t get to know it until Vista came along in November 2006 myself.
OK Then: NoMo Snipping Tool Try Screen Sketch Instead
In the Skip Ahead preview, you can click the button shown labeled “Try Screen Sketch.” This launches the eponymous application. If you click its “New” button, you make a rectangular screen snip by default. This works much like the old Snipping Tool. Screen Sketch also offers options to crop, annotate or highlight screencaps. Personally, I’ve used tools such as Corel Draw, IrfanView, Greenshot, and SnagIt Editor to work on screen stuff captured using Snipping Tool.
Screen Sketch offers basic capabilities, but its controls aren’t as fine-grained or as comprehensive as those other tools. Thus, I probably won’t use it for image annotation or manipulation myself. For basic capture and annotation it works — as long as you don’t mind “touch writing.” Can’t stand it myself. As a writer, I’m a keyboard guy through and through.
But if you use Snipping Tool now, you’ve been warned. It’s likely to disappear in Windows 10. If not in Version 1809, then in Version 19H1. (That is, I believe, the new version nomenclature that could appear for the first Feature Upgrade of 2019). One version or the next, sometime soon, Screen Sketch will take Snipping Tool’s place. If you’re like me, and make frequent screen grabs, you’ll pin it to the Task bar right away. If you want to get an early start with the tool, you can already download Screen Sketch from the Microsoft Store.
I follow the news at TenForums.com. Among other things, it keeps me up with new Insider Preview releases. It also cover updates and changes in Windows-World. This morning I saw a interesting headline in its News Forum. It reads New Firmware Update for Surface Pro 3 – August 7, 2018. Take a look, and you’ll see it links to an MS Support Note. Check that note, and it says “Run WU and you’ll get the update.” So that’s what I did. But WU found zero, zip, nada. Knowing that there’s always another way to grab MS updates I recalled the Download drivers and firmware for Surface page. Sure enough there’s a link for Surface Pro 3 stuff there. It includes two entries of interest — namely a TPM update tool and a Surface Firmware Tool. And that, dear readers, is how I found that manual download works when WU finds nothing.
Items tend to enter this list at the top, so I was pretty sure these two items were what I needed. So I downloaded and installed them.
Proving That Manual Download Works When WU Finds Nothing
Based on the information in the download description, I knew that the BIOS version was 3.11.2450. Using PowerShell and the Get-WMIObject Win32_BIOS command, I was able to confirm that, after applying the update, that’s what version of the UEFI was running.
A quick jaunt into PowerShell confirms that the most current version of the UEFI firmware is indeed running. Success!
So remember: if the news says an update is available, but WU fails to send it your way, there’s almost always some way to grab it in file form and install it manually. That’s what I did here. It’s also what others can do, too, if they check an appropriate source for downloads. For most updates that’s the Microsoft Update Catalog. For Surface PCs, however, it’s the Download drivers and firmware for Surface page. ‘Nuff said.
One week ago today, I blogged about a clean install on one of my Dell PCs (Venue Pro 11 7130). With Fast Ring Builds 17728 and 17730, another of my Dells has forced this manuever again. That machine is a 2014 XPS 2720: i7 4770S mobile CPU, 16 GB RAM, Intel HD3000 graphics, and a Samsung EVO 250 GB mSATA SSD. I’ve been unable to get past the first reboot with either of those two upgrades this past week. None of three approaches worked. Those included: Windows Update, Windows Update MiniTool (WUMT), and a manual upgrade using a mounted ISO. Today, I bit the bullet and did a clean install. It worked like a charm, and took a major load off my mind. This raises the question: how might one recognize when Fast Ring Win10 builds 17728 and 17730 may require clean install. I’ll explain…
How to Tell When Win10 Builds 17728 and 17730 May Require Clean Install
I was never able to get past the first reboot when trying to upgrade to either of those two Builds on the XPS 2720. It would show a “Restart needed” screen in Windows Update. But one or more restarts never triggered “applying updates” and spinning balls before and after the mandatory reboot. This persisted through any number of attempts using Windows Update or WUMT. I also saw something even more mysterious when I used the UUPDump and UUPtoISO tools. I constructed an ISO for Build 17728 (it failed with UUPDump errors for .esd files from 17730). I saw a status window from the Windows 10 installer I’d never seen before. It’s labeled Windows Installer and simply reads “Windows 10 installation has failed.” Not much to go on there, I’m afraid…
This is similar to the more familiar “Something happened” message, but is a new status message from the Windows 10 installer, as far as I can tell.
Neither the message nor the underlying Panther logs gave me much to go on as to causation or cure.
If you attempt a manual upgrade from a Fast Ring ISO and see this message, I can tell you from recent personal experience that a clean install using a bootable version of that ISO will set the affected PC back to rights. I wish I knew more about how or why this was happening. But with only limited time for deep analysis and troubleshooting, after spending more than half a day trying to get to the bottom of the upgrade install issues I theorized a clean install would catch the PC up more expeditiously. Now that I’ve done it, I’m glad I was right!
Ouch! No sooner did I install the latest Nvidia GeForce driver — namely, 398.82 with an 8/1 release date — than my PC threw a bluescreen crash my way. The detail from Reliability Monitor appears below. This leaves me in something of a dilemma. Should I roll back to the previous version, or wait to see if it crashes again? Fortunately, I’ve got my 9AM backup to roll back to on my production PC. Thus, I’m in “wait and see” mode right now. But gosh! Finding myself in the situation of latest GeForce Driver 398.82 bluescreens PC is something I haven’t faced for at least a couple of years now.
This bluescreen crashed my PC hard enough I had to perform a hard reset to return to computing action. Sigh.
When Latest GeForce Driver 398.82 Bluescreens PC, What to Do?
Surprisingly, the crash was hard enough that the PC stuck on the bluescreen for several minutes. I decided to quit waiting, and did a hard reset to return to computing on that machine. So far, I’ve been running for about half an hour without a recurrence. The error message speaks of an “unknown function.” Presumably this was called in the latest Nvidia driver installer so I believe the error is unlikely to recur. That said, there is a mention of bluescreen when using Alt-Tab between a full-screen game and a video in the Netflix Edge Browser (something else that’s not likely to affect me, either). See this discussion at AnandTech for details: Nvidia releases 398.82 WHGL Game Ready Driver.
If, like me, you’re mildly obsessive about keeping drivers up-to-date, consider yourself warned that there’s at least some potential for trouble with the 398.82 release. My system is a pretty run-of-the-mill and hardly leading edge rig. A Z170 chipset, i7-6700 CPU, and a MSI GTX 1070 graphics card is not likely to suffer from bleeding-edge hardware gotchas. Methinks there’s a bug lurking in the Nvidia installer somewhere. Hopefully, they’ll root it out before the next update hits the Internet.
[PS Added 1 Hour later]: I just finished reported my replicable bug experience to Nvidia through their Nvidia Driver Feedback web page. I’ll be interested to see if this provokes any kind of response from them.
The pace of new Insider Preview feature upgrades has picked up lately. I’ve seen a least half-a-dozen in the last three weeks or so. And with increasing frequency, I’ve also encountered an interesting issue during installation. Sometimes, on some PCs, the upgrade proceeds until a first reboot is requested. Then the OS prompts for a restart to get installation going in earnest. The running OS relinquishes control, and turns over the PC to the OS installer for the serious work. Alas, I’ve have at least 3 such upgrades hang up on me. Each time, a restart did not let the installer take over and actually upgrade the OS. Thus fixing Win10 upgrade stuck on Restart has been a preoccupation for me lately. Here, I report on a couple of fixes that have worked for me with varying degrees of success.
Sure, the warning says a restart is required, and the button says restart now. When WU is stuck, repeated restarts don’t help.
1. Fixing Win10 Upgrade Stuck on Restart with WUMT
One of my go-to fixit tools when problems present with Windows Update (WU) is to try a third-party alternative instead. Named the Windows Update MiniTool, and available for download at MajorGeeks.com, WUMT accesses Windows Updates independently of WU functions built into Windows 10. For whatever reason, I’ve learned that it can often (but not always) download and install updates when WU can’t or won’t do the job. It’s definitely worth getting to know, and adding to your toolkit, just in case problems might present with WU itself. It worked to fix one of my three recent “Win10 Upgrade stuck on Restart” incidents, in fact. For more info on working with WUMT, see my Win10.Guru story “Toolkit Item: Windows Update MiniTool (WUMT).”
2. Fixing Win10 Upgrade Stuck on Restart with Cleanup + WU Reset
Even WUMT can’t always prevail in this situation. Sometimes, WU hangs so badly WUMT makes no headway, either. When that happens, I turn to the excellent tutorial (with automated batch file) at TenForums.com to perform a full-blown WU reset. Before that, based on input from my Win10.Guru partner Kari, I also perform a special “deep clean” operation on my OS files.
2.1 The OS Files Get a “Deep Clean”
Like Kari before me, I’ve tried the TenForums tutorial without taking this cleanup step. We’ve both noticed success is more likely when performed as the initial step in a full-blown WU reset operation. The command is quite simple, but cleans up all drives on a Windows 10 system, with special emphasis on the boot/system drive (usually C:). Please cut and paste this command into an administrative command prompt window:
cmd.exe /c Cleanmgr /sageset:65535 & Cleanmgr /sagerun:65535
This will open a plethora of Disk Cleanup windows — one for each drive present on the system — check ALL boxes to remove everything it finds. [NOTE: the Downloads item includes any files you’ve downloaded into your Downloads Library folder. If you want to save any such stuff, copy it into a personal directory of your making before running this command.] There’s a lot going on here, so it could take up to half an hour to complete.
2.2 Performing a Full-Blown WU Reset
The TenForums tutorial Reset Windows Update in Windows 10 covers this in amazing detail. I follow this method because it provides a batch file that you simply download (and unblock if necessary), then run. After restarting your computer, your WU environment will be completely cleaned up and reset. It took about 3 minutes to run this on my most recently affected test machine and worked like a charm. No reason why it can’t do the same for you. Highly recommended!
For most situations, if WUMT can’t set things straight, the WU Reset method explained here will do the trick. If that still fails to produce the required result, that’s not the end of the road. Those seeking to install an upgrade should consult Kari’s TenForums tutorial UUP to ISO — Create Bootable ISO from Windows 10 Upgrade Files. It explains how to build an ISO from the upgrade files that you’ve been unable to get WU to turn into a working installation. It’s more of a “DIY upgrade” scenario, and seldom, if ever fails. If that goes south, the only option left is a clean install from the same bootable ISO you have already created. Make sure you’ve got a current backup of your working installation, before you start making any of these changes. Then you can always roll back if you learn that rolling forward isn’t working. Happy trails!
Sometimes, the march of progress can be both rewarding and infuriating, where Windows 10 is concerned. Case in point: a series of failed upgrades on my Dell Venue Pro 11 recently turned into a clean install. I switched from a default disk layout with the WinRE partition first, to MS’s preferred layout which puts it last. At the same time, a long-standing gotcha on that PC also fixed itself. It was introduced last January, when the first of several firmware patches for Spectre and Meltdown made an appearance. After installing that patch, my system no longer restarted properly. Only with battery removed, and AC power temporarily disconnected then reconnected, would it start back up again. But late last week, a clean install fixes long-standing Win10 restart issue finally banished this problem. If only I knew how or why this happened, I’d be much happier.
After 7 months with no normal restart ability, a clean 1803 install sets things right again!
[Click image to see full-sized view.]
Clean Install Fixes Long-Standing Win10 Restart Issue Remains Mysterious
I can only guess that something in the first firmware update damaged the boot structure somehow. Perhaps it affected the EFI partition. Because I couldn’t restart the machine properly after that, I couldn’t install the A24 BIOS update released in June, 2018, either. That’s because the BIOS installer schedules a rewrite of the BIOS after restart to give it a clean slate to work on. But no proper restart also meant no BIOS update, either.
When I rebuilt the boot environment from scratch, though, restart resumed working normally. This enabled a BIOS update, as shown in the preceding screen capture from System Information. Interestingly, the OS never lost its ability to restart while performing upgrades. Only when the installer returned boot control to the Windows 10 UI did restart cease working properly. So I knew a fix of some kind was possible. As it happens, a clean install did the trick.
Vindicating Conventional Wisdom on Periodic Clean Installs
This machine had previously been through over 100 Windows upgrades, a sequence uninterrupted since I installed a Technical Preview in early 2015, about five months into that program. Conventional wisdom on Windows is that it’s a good idea to perform a clean install on PC’s periodically. It’s viewed as a clean-up for “behind the scenes” buildup of trash and detritus. I see this welcome return to normal restart operation on the Venue Pro 11 as vindication of such wisdom. Kind of makes me wonder why I didn’t try it sooner, rather than later. But better late than never!