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!
I just clean-installed Windows 10 1803 on one of my test machines. In that install’s wake, I found myself unable to RDP into that machine. “Oho!” I thought to myself “I bet the network is set Public, not Private.” Although my presumption was correct, I had trouble figuring out how to make that change in Settings. A quick visit to Google informed me that a command-line remedy could do the trick in PowerShell (PS). I immediately put it to work. Here’s what that looked like, as a PS cmdlet turns Win10 networks Private:
You need Get-NetConnectionProfile to see what’s up with your network profiles. This drives use of Set-NetConnectionProfile to make the appropriate profile Private.
[Click image to see full-sized view.]
How a PS Cmdlet Turns Win10 Networks Private
Because Win10 PCs can have multiple network profiles — think WiFi and Wired, plus one or more virtual switches for VMs — it’s important to target the right one when making the switch from Public to Private. That’s where Get-NetConnectionProfile comes into play. Use it to target the InterfaceIndex whose NetworkCategory value needs to change accordingly.
PowerShell cmdlets use a verb -noun stucture. The cmdlet’s name represents a verb, or action, that does something. Get-NetConnectionProfile is a verb that lacks a required noun. That’s because it looks stuff up that the system already knows. For Set-NetConnectionProfile, on the other hand, one value identifies a specific profile, and one or more others make changes to associated value(s).
Here’s more detail on Set-NetConnectionProfile syntax, using text from the preceding example. (If the following string breaks across multiple lines, it should appear as a single line in PowerShell):
Set-NetConnectionProfile -InterfaceIndex 17 -NetworkCategory Private
Set-NetConnectionProfile is the verb that indicates we’re going to set one or more values associated with a specific network profile.
-InterfaceIndex 17 identifies the specific network interface whose profile gets a value change. For this PC, the index is 17. It will vary on other machines, including yours.
-NetworkCategory Private assigns the NetworkCategory (Public/Private) the value “Public” for the designated interface index.
It’s pretty darn simple to do this, so worth getting to know.
But Wait: There’s IS a GUI Way to Do This, Too!
After a bit more poking around online, I did eventually find a way to make the necessary change in the GUI as well. By clicking Start → Settings → Network & Internet → Change connection properties, you get to a Settings page with a “Network profile” section at the top that includes radio buttons for Public and Private. It looks like this:
Settings does provide a path to this control, though it isn’t intuitively obvious (or wasn’t obvious to me, anyway).
Given how easy this is, why I did blog about the PS cmdlet alternative? Because I had trouble finding the GUI element myself, and because some people have reported being unable to access the Network profile control through the afore-mentioned sequence of interface clicks. In Windows, there are always multiple ways to get things done. This is one case where having another way can make the difference between completing a desired task, and leaving it undone. When it comes to using RDP with my battery of machines, the latter possibility is intolerable, so I *HAD* to find another way…
Found myself in a bit of a pickle yesterday. Downloaded the 1803 ISO using the Windows ISO Download Tool from HeiDoc.Net. Quickly learned that it includes 13 different Windows 10 images (see below). After I used Rufus 3.0 to build a bootable installer, for some odd reason it installed the first image. Athough an OS pick window should appear, none did. Instead, it installed Windows 10 Home. I fixed that by upgrading Home to Windows 10 Pro. But I also wanted to learn how to extract the right image from a portmanteau ISO. That’s how I learned that DISM Export-Image grabs selected image installer, easily used to update the bootable USB Flash Drive (UFD) that Rufus built.
Notice that Windows 10 Home appears in first place, but Windows 10 Pro in sixth (Index:6).
[Click image for full-sized view.]
Use DISM Mount-Image Grabs Selected Image Installer to Build Bootable UFD
Once I figured out that I needed the Windows Pro image from position 6 in the 1803 ISO file, I needed to do two things. First, I needed to access the install.wim file I wanted. And second, I needed to copy that image onto my prepared UFD. Both things turn out to be fairly easy.
Use DISM Export-Image to Make Its Files Accessible
This particular DISM command exports a specific image standalone. As already noted, I wanted the image with Index 6. On my system, the ISO file named Win10_1803_English_x64.iso lives in L:\MSDN. To access its WIM file, I simply mount the ISO. To do that, right-click the ISO file in File Explorer and select Mount from the resulting pop-up menu. (If that doesn’t work, click “Open with” and select File Explorer from the list of applications.)
On my system, the mounted image shows up as drive M. The file I’m after takes this specification: M:\Sources\install.wim. In my case, I created a folder named WIMTest on the I: drive to receive the desired install.wim file.
Here’s the syntax for my system, which I’ll explain in generic form, too:
DISM /Export-Image /SourceImageFile:"M:\Sources\install.wim" /SourceIndex:6
Note: Even though this line breaks in this blog post, it’s actually a single instruction and should be entered as such in PowerShell or Cmd.exe.
Now, let’s explore the DISM command elements involved.
/Export-Image: Tells DISM to export the designated image file.
/SourceImageFile:"M\Sources\install.wim": identifies the windows image file from which the chosen image is exported.
/Index:6: identifies the index or position of a specific image file in the overall sequence (6, in this case) for export.
/DestinationImageFile:"I:\WIMTest\install.wim": identifies the file for the exported image.
Copy the Result File Over the Old Image File
The Rufus-created UFD has the drive letter O: on my system (YMMV, replace accordingly). All I had to do now was to over-write the old install.wim in the O:\Sources folder with the newly-exported install.wim from the I:\WIMTest folder. Now, booting the installer automatically installs Windows 10 Pro instead of Windows 10 Home. Of course, even though my system is installed the UFD is useful for repairs, too. Problem solved!