OK, I admit it. I got tired of waiting for Microsoft to offer my production PC the May 2019 Update (aka 1903 upgrade). Last Friday, I broke down and used the Update Assistant instead. Despite my original plan to wait for WU to make an offer, I caved. Here’s a brief chronology of events leading up to production PC gets 1903 upgrade:
5/21: MS publishes “How to get the Windows 10 May 2019 Update”
5/21 (and later): MS begins offering May 2019 Update to a limited set of PC through WU
5/22 & 23: I successfully use the Update Assistant to update 4 other PCs to the May 2019 Update
5/22 (thru May 31): I check WU daily to see if my production PC
5/31: I lose patience, and run the Update Assistant on the production PC, too
If you, like me, get tired of waiting for MS to clear one or more PCs for the May 2019 Update through WU, use the Update Assistant instead.
[Click image for full-sized view.]
OK: Product PC Gets 1903 Upgrade. Then what?
I confess: The history of upgrade offers for 1809 is what spooked me. Even with the May 2019 Update trickling out to certain PCs, some PCs are still running 1803. That’s because WU has yet to offer them the 1809 upgrade. And in fact — as I explain in a Win10.Guru story I wrote last week — for many such PCs MS Plans to Skip Over 1809 to May 2019 Update. The 1803 to 1809 transition demonstrated that an upgrade offer through WU could be months away. With my patience exhausted, I used the Update Assistant. Instead of waiting longer, I clicked the “Update now” button shown above. This let me upgrade on my schedule, having decided I was ready.
All this said, my upgrade experience with the half-dozen machines I’ve upgraded has been uniformly positive. I did encounter a couple of hiccups on two such installations — namely on my Lenovo T520 and X1 Extreme laptops. But ultimately, the install on both machines proceeded to a successful completion without anything more than a retry on the T520.
That’s because the Windows 10 installer incorporates some visible new enhancements and error-handling capabilities, as I reported in another Win10.Guru piece: May 2019 Update Shows Improved Installer. After the T520 fell prey to the well-known install failure that sometimes happens on PCs with SD cards or external USB drives attached, it asked me if wanted to pick up where I left off after I removed the offending device. Even more amazing, the X1 Extreme experienced a BSOD during Post-GUI installation, but automatically recovered itself afterward and the install proceeded to a successful outcome without any action from me.
As far as I’m concerned, unless MS specifically warns users of certain hardware or applications away from an immediately upgrade to the May 2019 update, it’s OK to take the plunge right now. All of my experiences have been good. Hopefully yours will be the same. If you’re in any doubt, check the Microsoft Known Issues List for Windows 10 May 2019 Update version 1903.
I’ve got a somewhat temperamental driver for my otherwise excellent Samsung ML-2850 network printer. Every now and then, the driver goes sideways for no obvious reasons. When that happens, I simply use Devices & Printers to remove the device, and then use its TCP/IP address to reinstall it. This works just fine, but it tends to leave various stale printer objects around. So now, I’ve learned that PowerShell clears stale printer objects away. This lets me spruce things up after I go through the “remove printer — reinstall printer” dance with relative ease. Here’s what things looked like in PowerShell this morning, when I used the Get-Printer cmdlet (in table format) to see what was what:
Notice that table rows 3-5 are all for the same printer: a Samsung ML-2850 device.
[Click image for full-sized view.]
How PowerShell Clears Stale Printer Objects
As a somewhat mangled PowerShell version of the old saw goes: “There’s a cmdlet for that!” The name of that cmdlet is Remove-Printer, and it’s part of the family of PowerShell cmdlets known as PrintManagement. I will observe that the whole family is worth getting to know for general printer and related port, job, and driver handling, even though I’ll focus here on Remove-Printer and Get-Printer exclusively.
The simple syntax for using Remove-Printer is to use its -name parameter. Because I’ve decided to remove all of my Samsung printers and create a new entry, the removal is dead simple. (I’ll use Add a Printer in Devices & Printers to add a new entry after removing the ones shown above. I’ll name it “SamsNWP2850” to put maker, type [NetWorked Printer, or NWP], and model number in that name.])
Here’s the syntax:
Remove-Printer -name "Samsung*"
That’s it. Pretty simple and straightforward, eh?
After a New Device Is Incarnated
Remember, I named that reincarnated Samsung ML-2850 printer as “SamsNWP2850.” By no coincidence whatsoever, it shows up at the first entry in the table format output from Get-Printer:
Now that the duplicates are gone, you can easily see the entire list of current printer definitions. Most of them I never use (Snagit, OneNote, Nitro PDF, XPS doc writer and fax).
[Click image for full-sized view.]
This kind of clean-up is worth conducting any time printer definitions get updated or replaced. OTOH, you could make it a semi-annual or yearly checkbox item, and perform clean-ups only when needed.
Here’s an interesting note from the Windows Support team (most recent update: 5/24/2019). It’s entitled “You cannot restore the system to a restore point after you install a Windows 10 update.” And indeed, it confirms that recent Windows 10 updates kill built-in restore facility — in some cases, anyway. Consider the scenario it describes:
- Install Windows 10 on a clean computer.
- Turn on system protection, and then create a system restore point that is named “R1.”
- Install one or more Windows 10 updates.
- After the updates have finished installing, you restore the system to the “R1” restore point.
This is an entirely typical and predictable use of Windows 10’s built-in Restore Point facility,. Alas, it blows up after some recent Windows 10 updates. In fact, the symptom of this issue is the Stop error (0XC000021A). When this happens as you attempt to restart the computer to apply the restore point, the system won’t boot. Retries don’t help, either.
Instead of reloading the OS from the restore point after bootup, you get a boot failure instead. It won’t go away upon subsequent retries, either.
[Click image for full-sized view; Image source: Phoneweek.]
What’s Up with Recent Windows 10 Updates Kill Built-in Restore Facility?
MS explains the issue as follows:
During the system restore process, Windows temporarily stages the restoration of files that are in use. It then saves the information in the registry. When the computer restarts, it completes the staged operation.
In this situation, Windows restores the catalog files and stages the driver .sys files to be restored when the computer restarts. However, when the computer restarts, Windows loads the existing drivers before it restores the later versions of the drivers. Because the driver versions do not match the versions of the restored catalog files, the restart process stops.
Thus, it’s your basic Catch-22. You can’t restore the OS because the drivers aren’t the right ones, and you can’t complete the boot operation for the same reason. Sigh.
Working Around Restore Point Error 0XC000021A
To solve this problem, Microsoft instructs users to restart their PCs multiple times (usually takes 3 tries) until it boots into WinRE (the Windows Recovery Environment). Once inside WinRE, the fix is pretty straightforward. Here’s the recommended sequence of actions:
- Troubleshoot → Advanced Options → More recovery options → Start settings: Select Restart now
- Inside startup settings: Select Disable driver signature enforcement (MS observes “You may have to use the F7 key to select this setting”)
- Allow the startup process to continue. Once Windows restarts, the system restore process should complete successfully.
Avoidance Beats Cure!
I’d suggest that readers simply stop using the built-in Restore Point facility. Any recovery mechanism worth its salt has to be unshakeable and unbreakable. That’s why I’ve switched to Macrium Reflect (MR) instead of using built-in Restore Points and the old-fashioned built-in Backup and Restore (Windows 7) facility. Both are subject to occasional gotchas, hiccups and issues — like the one reported herein. I’ve been using the Free version of MR for going on 4 years now, and I’ve never had a single restore operation fail on me once, over hundreds of uses. Personally, I’m of the opinion that Windows 10 users should switch over to a more reliable and well-behaved backup-restore mechanism.
MR (including the Free version) backs up and restores Windows 10 images quickly and effortlessly. It also includes a nearly fool-proof Rescue Disk from which users can boot their systems to restore MR image backups when OS boot issues present themselves.
Reading over recent TenForums threads, I was reminded that the Snipping Tool is slated for retirement in a future Windows release. How? A worried user asked how to keep using it even after it’s gone from future code bases. Turns out this is fairly easy to accomplish as long as you take certain preventive steps in advance. OTOH, if you maintain access to an older backup, you can perform those steps when that backup is mounted and its files are accessible. Yes, fellow geeks, it is possible — easy, even — to rescue old Windows 10 applications from oblivion. I’ll explain how below, but here’s where the concern about the Snipping Tool originates, straight from its opening screen:
Note the euphemistic language for retirement/removal: “moving to a new home.” Ha!
How-to: Rescue Old Windows 10 Applications from Oblivion
Turns out, two key elements work inside all built-in Windows applications. Element one is the executable code that makes the application work; Element two is the UI information that provides labels, messages, and info to users in their chosen UI language while the application is running. Both pieces are necessary, but the language piece must reside in a specially-labeled folder dependent to the folder in which the .exe file lives. Let’s use the Snipping Tool as our example to show how this can be accomplished.
Grab the .exe file you need
Find the .exe file name. Again, we’re using Snipping Tool as our example, but you can use this technique for any Windows executable you wish to preserve. Thus, right-click Snipping Tool in the Start menu, then open its Properties window. There, on the Shortcut tab, you’ll find the following data for its Target field:
On most PCs, the environment variable %windir% resolves to C:\Windows, so that really means that the .exe file resides in C:\Windows\system32. So that’s where you want to go to grab that .exe file. Let’s say you put it on your D: drive in a folder named OldSnipTool (for Windows, this translates into D:\OldSnipTool, as a directory path).
Grab the corresponding .mui file
Next comes the UI file, which takes the extension .mui. This stands for Multilingual User Interface, and provides the resource files that Windows uses to deal with the UI in some specific language or another. Finding this file requires two bits of information. First, you must know that language name for your chosen UI language. Look for that as the folder name for the dependent folder from which you’ll grab the corresponding .mui file. It has the same name as the executable file, and ends with a .mui extension. Thus, given an .exe file named SnippingTool.exe we’re seeking a file named SnippingTool.exe.mui. A quick hop into Explorer file search (or my personal fave, Voidtools Everything) can find this for you quickly, and will show you the language label(s) that you’ll need for the second bit of information. It (or they) will name your subsidiary folder(s) [I include the optional plurals here because some people may need more than one UI language for some installations].
Thus for example, the version of this file that I want shows up with the following directory path: C:\Windows\System32\en-US\. Note that I bolded the language version I need — namely en-US. This stands for English-US, or the version of English spoken/written/read in the USA. Microsoft calls these names Language Code Identifiers (LCIDs) and maintains a set of complete references for such things if you want to see their take on it. I usually use search to show me in my current Windows install what I need to think about instead. In this case that’s en-US.
Copy the Files into Appropriate Folders
Based on my example set-up, SnippingTool.exe goes into D:\OldSnipTool. Next, I need to create a new folder therein named \en-US. Then, I copy the corresponding.mui file into that folder. This produces the following file structure, as shown in File Explorer:
It takes two File Explorer windows to show contents of parent and child folders. Here you see the .exe in the parent, and the .mui in the properly-labeled child folder.
[Click image for full-sized view.]
Now, if you visit the parent directory and double-click the .exe file, the application should launch as expected. I just tried it on the files I set up for this example, and it works as expected. It should do likewise, with any pairs (or sets) of .exe and one or more corresponding .mui files. Each of the latter, of course, must be ensconced in a properly-labeled language identifier-based child folder. With all that in place, you should be good to go.
I can’t complain about Windows 10 Version 1809. A quick look at Reliability Monitor (aka Relimon, easily run as perfmon /rel) says why. Right now, my production PC shows a perfect Win10 Relimon score 10 days straight and counting. In past months, that score has dipped below 5 numerous times. That usually indicates multiple runtime errors, including forced shutdowns, application failures and more. For 21 of the past 30 days (including 5/11 through today) this PC shows a perfect reliability index of 10. Check it out:
Previous Windows builds have shown far lower Reliability Index values. But this latest version seems uncommonly stable and robust — for me, at least.
[Click image for full-sized view.]
What Does a Perfect Win10 Relimon Score 10 Days Straight Mean?
On this same PC, running earlier Windows 10 builds, I’ve seen much lower Reliability Index values. And most of the score-lowering impacts involved have come from MS or OS components themselves. These have included Internet Explorer (which I don’t use much anymore as a consequence), but also File Explorer (a key and constant OS component), a variety of UWP apps including Skype (responsible for all of the Warnings shown in the preceding screen capture), and more. Failed Windows Updates can, and sometimes will, also impact the Reliability Index, too.
But for some reason, I’ve had a great run of reliability scores on 1809 since mid-April. In fact, my current Reliability Index measurements go back only to April 19. But I’m in the habit of checking these scores on a least a weekly basis, so I have a good sense of the longer term history as well as the current record available to me. Based on what I’m seeing now, and what I’ve seen in the past, I’m impressed enough with the way Windows 10 is presently working to write about it. Based on my experience with the current 1809 release on 5 PCs here on my local network, and what I’ve seen and heard elsewhere, I’m inclined to slant my impression of 1809 pretty positively overall. Let’s hope that when the 1903/19H1/May 2019 Feature Upgrade shows up — probably around month’s end — it will keep this lucky streak alive and well!
In 2017 I wrote a post entitled “Win10 Volume Shadow Copies May Need Cleanup.” I’ve just learned that useful PowerShell cmdlets do likewise. They provide analogs to various VSSADMIN command line functions. In fact, PowerShell handles Windows 10 Restore Points nicely. Plus, the reporting side of things is simpler and easier to understand. Let me illustrate, by comparing two similar sets of command output. Look at
VSSADMIN list shadows versus
Not only is the PowerShell output more compact (one line versus 10 per entry), it’s also a LOT easier to suss out!
[Click image for full-sized view.]
Because PowerShell Handles Windows 10 Restore Points Nicely, Use It!
There is some debate nowadays whether or not Restore Points are worth acquiring and using. One school of thought avers that it’s better to make regular image backups, and rely on those instead. Another school of thought asserts that Restore Points are worth trying as an early step in recovering from OS issues. Personally, I make a daily image backup of my production machines, and weekly backups of all other machines. I also enable Restore Points for the OS drive on all of my Windows PCs. Does this make me wishy-washy? I don’t think so. When it comes to protecting my desktop PCs, I prefer to regard this as more of a “belt and suspenders” approach to protection. In that same vein, I’ll also observe that I backup my production systems into the cloud once a week, and other systems likewise once a month, for additional coverage off-site.
Restore Point Related PowerShell Commands at MS DOCS
For more information about the afore-cited Get-ComputerRestorePoint and related cmdlets, check out these MS DOCS links:
Good stuff, all the way around. Slowly but surely I’m trying to migrate my Windows 10 command line smarts into PowerShell. Hopefully, these posts of mine will help others do the same. Cheers!
OK, then: here’s a new one on me. Yesterday, May 14, was Patch Tuesday. In keeping with usual practice, MS released a number of updates, including KB4494441. The subtitle for that CU, BTW, is “(OS Build 17763.503).” I downloaded the updates and installed them, without apparent difficulty. But when I checked my Build number, it was 17763.475 (not .503, as promised in the KB subtitle). A quick return to the TenForums thread on KB4494441 informed me that those who’d successfully made it to 17763.503 had invariably installed KB4494441 twice. I jumped back into Settings → Update & Security → Windows Update and checked for updates. Sure enough, it offered KB4494441 for install again. And that, dear readers, is why I warn you to “Install KB4494441 CU twice!”
Notice that two installs for KB4494441 show up in the install history. What’s up with that, I wonder?
Why Must We Install KB4494441 CU Twice?
Good question! I wish I knew the answer. The afore-linked Windows Support note about the CU says nothing about doubling up on installation. I don’t recall enountering this kind of behavior on other, older updates either, CU or otherwise. But indeed, on 4 of the 5 of the PCs running the Current Branch version of Windows 10 right now I had to double-install KB4494441 to get to Build 17763.503. That’s also, without exception, what the several dozen other individuals who posted to the TenForums.com thread mentioned previously reported as well. Thus, it’s my observation and belief that this double-update requirement applies generally to everyone who wants to get to Build 17763.503.
Do please let me know (comment here, or send me an e-mail through EdTittel.com) if your experience provides a possible counter-example. Something interesting is happening here, and I’d like to figure out what that might be. With your help and input, I just might be able to do that. TIA for your help and support!
[Note] Thanks to TenForums members khanmein and IronZorg for quoting my first thread in the KB4494441 discussion. Ultimately, this is what alerted me to the need for double install. Thanks also to member ddelo who opined that the new Servicing Stack Update might have been installed on the first try (as the Support Note says is necessary), making a second try to actually install the CU necessary. Upon further reflection and consideration, I’m inclined to think this may indeed be the case. I’ve got one more machine here that needs KB4494441 installed. I will try manually applying the SSU first and see if indeed subsequent installation of KB4494441 goes straight to .503 in that case. Stay tuned!
An interesting post popped up on TenForums this morning. Entitled “SSD is 50% Consumed with ETL files,” it requests help in separating keepers from losers. It also asks for guidance on getting rid of unnecessary ETL files. To begin with, ETL stands for Event Trace Log. It is a binary file format that captures log info from a wide range of built-in Windows tools and diagnostic utilities. Windows 10 usually keeps a lot of them around. Using Voidtools Everything, I found ETL file counts of between 700 and 2,000 on my various Win10 machines. When it comes to examining Windows 10 ETL files — and perhaps even deleting some of them — I offer some tips to ponder. But first, here’s what Everything says about ETL files on my production PC, where it finds just over 800 in residence:
If you rank them by size, you’ll see most ETL files are at or under 2K in size. Deleting big ones gets the best bang for your buck!
[Click image for full-sized view.]
Tips When Examining Windows 10 ETL files
Here’s a short list of rules to live by when deciding the fate of ETL files:
- You don’t have to keep ETL files around. If you have a lot of them, you may have an interesting time figuring out where logging got turned on (and what should be turned off).
- Most ETL files are protected or live in protected directories. Run Explorer (or Everything) as Administrator, and you’ll be able to kill almost all of them. If all else fails, boot to alternate media and kill ’em from the command line there.
- I like to rank ETL files by size. Most are small, a very few can be quite large (I’m showing 2 in my screencap of about 1 GB in size). You get more space back by killing 1 big one than 500 small ones, in my case.
- If any ETL files are older than a week or two, or predate your most recent feature upgrade, you probably won’t get any use out of them anyway. They can go!
- If in doubt (and I’ve never been in a situation where I needed or wanted to recover a deleted ETL file), back them up before you delete them on your Windows drive.
Yesterday, May 9, Nvidia released a new GeForce driver – version 430.64. “Gosh!” I thought “haven’t there been a LOT of them lately?” Indeed, the search tool reveals 10 released for 2019. Because May 9 falls in the year’s 19th week, that’s an update every two weeks. Of those 10 drivers, I’ve had problems with 3. Two caused “black screens” that required a reboot to resume normal operation. Rolling back to the preceding driver version in Device Manager fixed them. The third issue was more insidious. I lost DisplayPort access to my monitors. I temporarily switched to HDMI cables (which I keep around for testing and tomfoolery). Then, I had to run Wagnardsoft’s Display Driver Uninstaller (DDU) program to remove all traces of the problem driver. A clean install of the preceding version restored DisplayPort access to my monitors. These recent experiences have me musing about Nvidia driver update frequency.
Where Does Musing About Nvidia Driver Update Frequency Lead?
Games drive driver development at Nvidia. Thus, the Game Ready heading for the 430.64 driver explains it “[p]rovides the optimal gaming experience for RAGE 2, Total War: Three Kingdoms, and World War Z.” This is great for gamers in general, especially for gamers who’ve plunked down their hard-earned cash to such games. In general, gamers seem pretty keen to stay on the leading/bleeding edge so they can milk the most out of their GPUs for advanced rendering, 3D, and other high-end graphics effects to boost game play performance and experience. I, however, am not a gamer. I don’t need these frequent tweaks, bells or whistles to do the kinds of things I do, which are almost entirely two dimensional and involve no games that need anisotropic filtering, anti-aliasing, ray-tracing, and so forth and so on.
Nvidia: A Modest Proposal
Here’s my suggestion to Nvidia: Create two GPU driver forks. Leave the current one as-is, and label it “Gamers and High-end Graphics Effects.” Create another fork and call it “Non-Gamers.” This second fork need be updated only once every six months or so, and can act as a kind of cumulative update for changes introduced in the preceding half-year interval. It can also be extensively tested and vetted to avoid the kinds of hiccups I described in the lead paragraph here. Ideally, Nvidia would time it to coincide with, or follow shortly after, Windows 10 Feature Upgrades so that non-gamers could expect a new OS version to encompass a new graphics driver as part of the upgrade experience. This lets non-gamers avoid the occasional issue that requires messing around with the occasional, but seemingly inevitable, ill-behaved drivers with which they must now content.
I wonder if anybody at Nvidia is listening, and might respond to this suggestion? Let’s see!
In the past day or so, I’ve found myself on the horns of an interesting dilemma. Upon trying to remote from one 18890 (Skip ahead) PC to another using RDP, I found myself unable to log in. I could ping one PC from another, and see it on the network, but when I tried to consummate the RDP login I’d get an error. That error informed me my login password didn’t work (even though I could use that same password to log into the target PC locally). Nothing I tried to fix the situation helped. Ultimately, I activated the built-in Administrator account. That got me an RDP session from one 18890 PC to another. It also raised an interesting question. Given limited time and energy to devote to troubleshooting, was I willing to settle for a Windows 10 workaround versus fix? You bet!
Even though I *KNEW* I was using the right password, my RDP login kept throwing this error message. Sigh.
Which is Better? Windows 10 Workaround Versus Fix
I’m not sure I can make that call myself. For me, it’s as much about how much time and energy it takes to solve a problem, as it is about figuring out and implementing a perfect fix. Consider these two givens. One, I was working on beta software for 20H1. Two, the problem only occurred when the beta software was involved (as a target). My production PC, traveling laptops, and family PCs (all running the latest Current Branch build for 1903/19H1: 17763.175) all worked fine. That is, all could RDP into the target PC without issue. Only when I tried to RDP from one 18890 PC into another did I experience this problem.
That’s what makes a workaround perfectly acceptable to me in this situation. Another build will come along sooner or later (I’ve installed 18894 on one of those machines while writing this blog post, in fact). I’m hopeful but not convinced that the problem has already fixed itself. But I did find a viable workaround: as long as I log in with a local account using RDP, I can get into the machine I want to access remotely. For these test machines, that’s good enough for me!