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!
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.