I’ve belonged to the Insider Program for Windows 10 since it kicked off in October 2014. In the intervening 47 months, I’ve installed or upgraded Windows 10 hundreds to over a thousand times. Along the way, I’ve learned a few things about what to do right after you perform a Windows 10 upgrade. With the October 2018 release due sometime next month, I thought readers might benefit from a recommended checklist of such activities.
One Pre-Upgrade Item on the Win10 Post-Upgrade Checklist
Before making major system changes it’s always a good idea to back up your system. An upgrade counts as a major system change, so it’s smart to back your current system up just before you fire the upgrade off. I use Macrium Reflect for this purpose. It’s fast, compact and effective. It also includes a bootable rescue media facility that lets you build, then boot from a flash drive.
Upon booting to the rescue media you can restore any backup that Reflect can access. (That’s why I always back up to an external USB drive.) The rescue media also includes a terrific boot repair utility. It’s just what the doctor ordered if an upgrade leaves your system inoperative or unable to boot!
Win10 Post-Upgrade Checklist, step-by-step
The following items can (mostly) be performed in any order you like, except for the next upgrade. It should come right after you boot your upgraded system for the first time. The rest of the items described here can be executed in any order –except for the last upgrade. It takes a snapshot of your tweaked and cleaned-up system, so it should be the last step in this sequence. Think of these two backups as bookends, and you’ve got the right idea.
Make another backup. This provides access to a system image that you can roll back to the previous Windows version, if you like. It’s also as close to pristine as a Windows image gets. If something goes wonky in the following steps you can use it to start over AFTER the upgrade has completed.
Microsoft’s built-in Disk Cleanup utility can remove all kinds of files, including the remnants of previous Windows installations. Because you’ve got a backup, you don’t need the rollback capability that Windows.old provides to users. Type “clean” into the search box, then right-click Disk Cleanup and select the “Run as administrator” option. This opens the tool into system cleanup mode. Next, you’ll want to select the following checkboxes among the Disk Cleanup options (at a minimum):
• Windows upgrade log files
• Temporary Internet Files
• Delivery Optimization Files
• Device driver packages
• Previous Windows installations
• Temporary files
On most of my upgrades, this single operation recovers 25-30 GB of disk space on my system disk. Definitely worth doing.
Device Driver Cleanup
With each upgrade, Windows 10 loads a new set of device drivers. Sometimes, duplicates or multiple versions of drivers can appear. It’s always a good idea to check your drivers after an upgrade and, if necessary, to remove unneeded or obsolete items. I use and recommend the excellent open source Driverstore Explorer tool for this purpose (RAPR.exe, run as administrator). You can use the “Select Old Drivers” button to tag old or duplicate drivers for easy deletion. I’ve recovered up to 2 GB from this maneuver in some cases. That said, modern Windows 10 versions do a terrific job of identifying and installing the right device drivers 99% of the time.
Additional File System Cleanup
As good as Disk Cleanup is, it’s not the only tool worth using to take out file trash. I also use Josh Cell Software’s free and capable UnCleaner package to root out and remove what Disk Cleanup misses. On a recently installed 19H1 Skip Ahead Preview on a test PC, for example, it found 167.6 MB of trash files after I’d run Disk Cleanup. When it did its thing, UnCleaner reported a mere 17.8 MB of trash files remaining. That’s an 89% reduction in trash space!
Check/Reset Network Status
Sometimes, for no discernable reason, a Win10 upgrade will reset local LAN connection status from Private to Public. Because I use Remote Access, and it doesn’t work on Public networks, I’ve learned to check this after the upgrade completes. Click Start → Settings → Network & Internet. Check the graphic that shows Network status. If it reads “Public network,” click “Change connection properties,” then click the radio button labeled “Private.” If you encounter issues in seeing or accessing other PCs on the LAN, you might also want to check settings under “Change advanced sharing options,” too.
Check/Rest File Explorer Options
Also sometimes, a Win10 upgrade will reset File Explorer Options selected in the Control Panel utility of that name. Thus, for example, I sometimes need to change these items on the View tab to let me see everything I want in File Explorer:
• Show hidden files, folders and drives (radio button should be selected)
• Hide extensions for known file types (I want to see these in Explorer, so it must be unchecked)
• Hide protected operation systems files (I want to see these, so it must be unchecked)
Your preferences may differ from mine, but if they diverge from the defaults, you may need to reset them after an upgrade. Thus, you’ll want to check them to make sure they’re set as you’d like them to be.
Each of us uses certain Windows utilities, apps and applications that come with their own settings. Over time you’ll notice which of these might be disarranged by an upgrade. If you add them to this checklist, you’ll be able to check and fix them if necessary as and when the next Win10 upgrade happens.
When you’ve completed the preceding steps, you’ll wind up with a Windows 10 installation that’s tweaked and set just the way you want it to be. For ordinary restore situations, this is the image you want to backup. So please, run one more backup, and label it carefully (I’ll use 1809-customized for mine, so I can recognize that it’s the cleaned-up and tweaked image). Then you can restore that image in the future should you need to get back to a fresh, clean start on that build.
Last Thoughts and Observations
If you create and follow such a checklist, you’ll be able to surmount the upgrade process with grace and panache. I’ve learned to do this the hard way, though taxing trials and sometimes painful errors. Please benefit from my experience, build your own checklist, and make things easy on yourself.
As somebody who’s always chasing current PC hardware and standards, I sometimes forget not everybody else is the same way. Case in point: newer PCs boot to UEFI on GPT disks; older PCs boot to BIOS on MBR disks. There’s a lot to unpack here, so I’ll try to explain what’s up with GPT vs MBR disks. Older style disks use a Master Boot Record (MBR) which gives that type its name. Newer ones use a GUID Partition Table (GPT). GUID stands for “Globally Unique IDentifier” and differentiates all such disks from one another using a 32-digit hexadecimal number (a whopping 512 bits worth of data). By contrast, MBR disks use an identifier that consists of only 8 hexadecimal digits (128 bits worth of data). You can see this difference in the following screen cap from Win10’s built-in DISKPART utility:
GPT disks show an asterisk in the “List Disk” table, and it’s easy to distinguish long GPT unique IDs with dashes and curly braces from MBR unique IDs with just 8 hex digits.
[Click image for full-sized view.]
Why GPT vs MBR Disks Matters
The big difference between these two disk layouts is nicely explained in a Microsoft Docs item entitled “Convert an MBR disk into a GPT disk.” Aside from the BIOS versus UEFI distinction, two key points emerge therein:
- GPT disks support more than four partitions per physical disk (MBR disks support up to four, but no more).
- GPT is required for disks that are greater than 2 TB in size.
Many disks are bigger than 2 TB nowadays. And in fact, Windows 10 uses 4 partitions by default. Thus, it’s no surprise that GPT disks are widely, if not exclusively used on newer PCs (2010 or younger). Win10’s default partitions occur in this order: Recovery–EFI–MSR–OS. They appear in this screen grab from the excellent and helpful MiniTool Partition Wizard. (Alas, the built-in Disk Management tool declines to show the MSR partition even though it’s real and present.)
The MSR appears in the layout in the third block from the left.
MSR stands for “Microsoft (MS) Reserved.” It’s a partition set up for possible OS use for purposes that are either mysterious or opaque. I can’t find any documented uses for this partition myself. OTOH, there’s an interesting article about it on Wikipedia: see “Microsoft Reserved Partition.”
Converting Between MBR and GPT
Microsoft’s built-in DISKPART (disk partition) utility will happily convert a disk from MBR to GPT format. It will even go the other way (from GPT to MBR) should that be necessary. That said, this conversion entails a low-level and destructive reformat of the whole drive. If you want to preserve any of the partitions on a drive slated for conversion, you must back them up before conversion, after which you can restore those you’d like to access once again after the conversion is done. Otherwise, all files and data will be lost.
File this post under “Windows Weirdnesses,” if you like. In the wake of a recent Cumulative Update, I’ve been unable to invoke the Reliability Monitor in my usual way on one of my Win10 production PCs. Until that release came along, I simply typed “Reli” into the search box, and “View reliability history” popped up in my selection menu. But last week, if found myself finding another path to Reliability Monitor because I saw this instead:
The error message is mysterious, but the real clue is in the top line where the string “Start10Ctrlpnl” appears. It’s not Windows, it’s my menu replacement program: Stardock’s otherwise excellent Start10 is the culprit!
[Click image for full-sized view.]
What Has Me Finding Another Path to Reliability Monitor? Start10!
Turns out that this is related to specific URI (Uniform Resource Identifiers) that Windows 10 uses as shortcuts to access specific system functions. With the release of 1803, MS changed some of these assignments. There’s a pretty complete list in a TenForums thread entitled “Settings Pages List of URI Shortcuts in Windows 10 Customization” (2/27/2017). These won’t work properly until Stardock (the maker of Start 10) fixes discrepancies. It’s been six months now, so I’m no longer holding my breath on this.
I’m looking for alternatives instead. My current favorite is to call Reliability Monitor through the built-in Performance Monitor tool. Thus, if you type “perfmon /rel” into the search box on PCs with Start10 installed, you’ll get the desired result. Please note that if your fingers, like mine, want to type “perfmon /reli” instead, this won’t work. How do I know? My fingers did it by force of habit and an error message that reads “The parameter is incorrect.” pops up, instead of the Reliability Monitor.
A longer path to Reliability monitor is also available, for those more inclined to click on stuff, rather than typing text into a search box. Here’s the click sequence: Control Panel → Security and Maintenance → Maintenance → View reliability history. I’m nowhere near patient enough to take that path myself. But hey! If that’s your thing, there it is.
Remember: Windows 10 ALWAYS Offers Many Launch Paths
The key here is to remember that if one launch technique in Win10 quits working, there are always other ways to get there from here. For me, the string “perfmon /rel” is my new go-to. This may work for you, or it may not, but there is always more than one way to launch the tool and read its tea leaves. Hopefully, you can find one that works for you, too.
If you’re anything like me, you watch for news about Windows Updates as they’re released. Two of my favorite sources for such info are Twitter and TenForums. On Twitter, the Windows 10 Team is pretty good about posting info for updates and upgrades (e.g. #WindowsInsider and @donasarkar). At TenForums, the Windows 10 News forum is my go-to resource: they usually pin new postings about updates or upgrades within minutes of release. When I saw news about new Intel microcode updates for Spectre last week, my first thought was to check if they’d been installed on certain target machines. My second thought was “Gosh! I bet there’s a PowerShell (PS) cmdlet for that.” Sure enough, I was right. If you feed it a KB article identifier, the PS Get-HotFix cmdlet checks update status quickly and easily. Here’s a screencap with a pair of examples:
For updates it finds, Get-Hotfix tells when it installed. If not you’ll get an error message instead.
[Click image for full-sized view.]
When PS Get-HotFix Cmdlet Checks Update Status, What Does It Say?
Look at the preceding screencap. If Get-HotFix finds an update, it reports its presence. It also shows date/time when the item appeared. That was the case for a recent Intel microcode update, KB4100347 added on 8/21/2018 to the target system. On the other hand, if a KB item is missing, Get-HotFix produces an error message. It reads “cannot find the requested hotfix…” I deliberately used a made-up, bogus KB identifier, KB4100300, to provoke the error message you see above. Actually, this is also what you’d see if you asked the command to check for a legit KB item that was absent from the target PC.
What All This Means To You
Get-HotFix makes it extremely easy to tell what’s present and what’s absent, as long as you can identify specific items of interest explicitly. To produce a list of all installed updates, simply enter the cmdlet name with no arguments instead. As long as you can remember the cmdlet’s name, you can use this handy little tool any time you like. Great stuff!
[Note] Here’s a shout-out to Mike Robbins, whose May 18, 2017 blog post clued me into this useful PS cmdlet. It’s entitled “Use PowerShell to Determine if Specific Windows Updates are Installed on Remote Servers.” He also explains an expeditious trick to run the command on remote machines (which should interest admins greatly). And for those who like such stuff, here’s a link to the MS Docs page on Get-HotFix.
On August 21, Microsoft released a spate of Intel-validated microcode updates for various Spectre exploits. These cover the following new items:
- Spectre Variant 3a (CVE-2018-3640: “Rogue System Register Read (RSRE)”)
- Spectre Variant 4 (CVE-2018-3639: “Speculative Store Bypass (SSB)”)
- L1TF (CVE-2018-3615, CVE-2018-3646: “L1 Terminal Fault”)
In fact, KB 4093836 summarizes August 2018 Spectre Microcode Updates, and provides pointers to specific KB items for Windows 10 1803, 1709, 1703, 1607 and the LTSC version.
WU Should Apply Updates from KB 4093836 Summarizes August 2018 Spectre Microcode Updates
Here’s the table of information from KB 4093836. On most affected systems, Windows Update should apply the relevant updates automatically. It did so on all but one of my 8 systems. But the various Win10-specific KB articles that appear in the table also provide links to Windows Catalog items when WU doesn’t pick things up (all entries in column 1 beneath the heading row are hyperlinks; they don’t appear in color because of WordPress weirdnesses).
|KB number and description||Windows version||Source|
|KB4346084 Intel microcode updates||Windows 10, version 1803, and Windows Server, version 1803||Windows Update, Windows Server Update Service, and Microsoft Update Catalog|
|KB4346085 Intel microcode updates||Windows 10, version 1709, and Windows Server 2016, version 1709||Microsoft Update Catalog|
|KB4346086 Intel microcode updates||Windows 10, version 1703||Microsoft Update Catalog|
|KB4346087 Intel microcode updates||Windows 10, version 1607, and Windows Server 2016||Microsoft Update Catalog|
|KB4346088 Intel microcode updates||Windows 10 (RTM)||Microsoft Update Catalog|
Source: KB4093836; table markup reproduced verbatim.
Who’s Got the Update Ball, This Time?
For previous Spectre (and Meltdown) updates responsibility has ping-ponged around among Intel (and AMD), Microsoft, and motherboard makers. That’s because these exploits occur at the microcode level. Thus, they work on machine-level instructions executed by the processors to exploit certain vulnerabilities. Finally, Microsoft is taking the lead in driving Intel (and AMD also, presumably, and perhaps also ARM as well). They work on patches, then get chipmakers to validate them for new exploits. For now, I’m hopeful this means MS will continue to make new patches as new exploits are discovered. In the ongoing game of “cops-and-robbers” that often characterizes cyber security, somebody has to make sure things stay current!
If you check the individual KBs for specific Windows versions in the preceding table, you’ll soon see if your CPUs are included. If they are, but the corresponding patch doesn’t appear in the update history for related PCs, you’ll want to visit the Microsoft Update Catalog to grab and apply the relevant patch manually.
Note Added Later on 8/24: Intel L1TF Benchmark Results Ban
ZDNet reports in an article entitled “Intel ‘gags’ Linux distros from revealing performance hit from Spectre patches” that the L1TF patch may cause significant enough performance hits that it enjoins software license agreement signatories from publishing benchmark results to document or describe the impact. Guess that means the company’s claim that “there has been no meaningful performance impact observed as a result of mitigations applied” may be in some doubt, eh? You’ll want to keep an eye on this as and when you apply the latest round of microcode updates. But then, you’d planned on testing them in limited in-lab deployment before rolling them out to your users, right?
Note Added 8/25: Users Reporting Patch Targeting Errors & Runtime/Boot Issues
Check out this MSPowerUser.com story: “Windows 10 KB4100347 Spectre patch causing serious issues.” It details some apparent patch targeting errors that lead to boot and other problems at runtime. If this happens to you, remember that you can boot from a recovery disk. Then, use DISM to remove the problem package on the offline image. That works, even if the OS isn’t running well enough to permit an overt uninstall through Windows Update. Wow!
Among a surprisingly complex and interesting collection of advanced features, Windows Defender blocks PUAs. PUA stands for “potentially unwanted application.” According to Trend Micro, PUAs are best understood as follows:
Potentially unwanted application or applications (PUAs), classified as grayware, refer to applications installed in a mobile device or a computer that may pose high risk or have untoward impact on user security and/or privacy. It may also contribute in consuming computing resources. It may be unwanted by the user even if it is installed with users’ consent. Most often than not, PUAs do not explicitly and completely state their functions and purpose. The impact the application causes may either inadvertently or simply be a part of its design. PUAs are created by legitimate or illegitimate software publishers.
Trend Micro goes on to explain (and my own experience confirms) that PUAs often involve bundling. This describes other stuff that comes along for the ride when a user installs some specific application. PUAs may also display oodles of ads, collect user information without notification and/or consent, issue exaggerated or bogus notifications (“scareware”), provide little or no control to users, run unwanted processes or applications (coin miners, for example), and require unorthodox or difficult uninstall processes. The “unwanted” moniker is pretty easy to understand, in light of all these potential gotchas.
How Windows Defender Blocks PUAs
Turns out that a variety of mechanisms permit Windows Defender to turn on a PUA blocking function. In enterprise environments, this might happen using InTune or System Center Configuration Manager (SCCM). Microsoft’s Windows IT Pro Center offers specific guidance on this process. A July 2018 article entitled “Detect and block Potentially Unwanted Applications” provides all the necessary details for using either of these tools. In addition, a single PowerShell command run with admin privileges can also enable (or disable) the appropriate setting. Here’s a screen capture that shows the “enable” command:
The command string is Set-MpPreference -PUAProtection Enabled. The following Get-MPPreference command shows Defender security settings currently in effect.
[Click image for full-sized view.]
The precise syntax for this command (for easy cut’n’paste) is:
Set-MpPreference -PUAProtection Enabled
To view all current Windows Defender security settings, use the following command:
In the preceding screencap, the information of interest appears in the next-to-last line. It reads "PUAProtection : 1", which means that PUA blocking is turned on. A zero (0) value means PUA blocking is off. Thus, the command to disable PUAProtection is:
Set-MpPreference -PUAProtection Disabled
Bypassing Windows Defender’s PUA Protection
Occasionally, one may wish to run a program that Windows Defender blocks. All blocked programs go into Quarantine, where you can access them quickly and easily. Just follow these steps:
- Click Settings → Update & Security → Windows Security.
- Select Virus & threat protection.
- Click “Threat History,” the click the item you wish to run, and click the “Restore” button.
Most of the time, it’s just that easy. If you can’t find the threat in this location, click “See full history” and look for it in the complete list of items there. Enjoy!
[Note: Here’s a shout-out to Martin Brinkman at Ghacks.net. His excellent 8/20/2018 story “How to enable Windows Defender’s potentially unwanted programs protection” inspired and informed this blog post. Vielen Dank, Martin!]
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!