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!
Today I learned something I should’ve known years ago. PowerShell command line zip handling is simple and easy, thanks to the built-in Compress-Archive and Expand-Archive cmdlets. Turns out these are extensively documented in the PowerShell 6 Scripting docs (see previous links). They are also easy to learn and use.
Using PowerShell Command Line Zip Handling
Mostly the two command use the same syntax and support the same parameters. And invariably those parameters are optional, so you can use ’em (or not) as your needs dictate. I’ll provide a couple of simple examples, to help show how things work.
Lifted from the afore-linked references, these diagrams show basic parameters for both commands.
[Click image for full-size view.]
For grins, I renamed a recent ZIP file to Test.zip and created a trio of simple text files named test<nn>.txt, where nn was 01, 02 and 03. These were all placed in a directory whose complete path specification was H:/TestPSZipStuff, as shown here:
I set up a bogus directory with a ZIP file and some text files to play around with.
[Click image for full-size view.]
Example: Compress txt files into a ZIP archive
This makes short work of grabbing all text (.txt) files up into a single ZIP file.
[Click image for full-size view.]
Notice that I also used the CompressionLevel parameter. This is explained in the afore-linked doc as telling the command how much compression to apply when creating the ZIP file. Acceptable values include (quoted verbatim from the cmdlet info):
- Fastest. Use the fastest compression method available to decrease processing time; this can result in larger file sizes.
- NoCompression. Do not compress the source files.
- Optimal. Processing time is dependent on file size
Example: Expand ZIP file into subdirectory
Here’s a screencap that shows me expanding the contents of Test.zip into a subdirectory named TestZipFiles. I include a couple of dir commands to show a new directory inside the home directory TestPSZipStuff, and then to show the contents of that directory (another subdirectory inside which the executable and other files for ShadowExplorer reside):
Notice the use of the current directory as “./” and the default supply of .zip as the file extension.
[Click image for full-size view.]
I you play around with these cmdlets and learn the ins and outs of their parameters and syntax, it won’t take long to get comfortable with them. Good stuff!
[Note Added May 8, ’19; circa 4 PM Central] Microsoft Insider MVP Luigi Bruno reminded me, quite correctly, that these particular PowerShell cmdlets are available only in PowerShell versions 5 and higher. If you’re running a relatively current Windows 10, they’ll work for you with the built-in version. If you’re running an older Windows version (including 7 and 8.1) you’ll need to upgrade PowerShell to gain access to these cmdlets and their capabilities. Thanks Luigi!
I’m running the upcoming Release Preview here at Chez Tittel on a couple of PCs. On one of them — the now-venerable Surface Pro 3 purchased in November 2014 — I found myself bitten by an interesting but well-known bug this morning. I was trying to upgrade to Build 18362.30. It would download from WU, then get into the GUI install. Each time I tried (and re-tried), it would hang at 25%. Eventually it would pop up a Window saying it had to check a few things. Fairly quickly thereafter WU would pop up a “PC can’t be upgraded to Windows 10” error window that explained I would have to wait for another build to try again. Here’s what you’ll see, if the 19H1 Release Preview bug bites one of your PCs:
If you see this warning while trying to upgrade to 19H1, an SD card may be getting in the way.
[Click image for full-sized view. Source: PCWorld.com]
If 19H1 Release Preview Bug Bites, Then What?
As explained in this MS Support note, there may be easy fixes. It’s entitled “This PC can’t be upgraded to Windows 10” error on a computer that has a USB device or SD card attached. Apparently something happens during the upgrade process that causes “inappropriate drive reassigment” (different drive letters, one presumes) vis-a-vis the usual setup. That’s what causes the error message that mentions “keep your Windows settings, personal files, and apps.” If you pop the SD drive (and/or external USB-attached drives, according to some) out and try again, the install runs to completion without difficulty.
That’s how it worked for me anyway. I’m glad I keep up with this kind of stuff (thanks to daily forays at TenForums.com). I pretty much recognized the error message and knew what fix to make before trying again. And fortunately, it did the trick! And so it goes, here in Windows World.
On April 30, the trading day ended with Microsoft’s valuation above US$1 Trillion, at $130.60 per share. According to MarketWatch, this makes “Microsoft the second U.S. company to hit the trillion-dollar valuation after Apple, which has since retreated below $1 trillion.” Other sources identify MS as $1T Company number three, behind Apple and Amazon. Wow! In fact, this makes MS one of the most valuable companies around (arguably the most valuable at the time of this writing). As MS valuation hits trillion dollar mark, what does this say about the company and its offerings?
Over the past year, MS stocks had some ups and downs, but the overall trend continues upward.
[Source: Nasdaq MSFT info; Click image for full-sized view.]
MS Valuation Hits Trillion Dollar Mark, Now What?
Not surprisingly, a quick look at the company’s third quarter FY 2019 results shows where its growth and strength originate. Highlights include the following:
- Revenue of US$30.6B, up 14% year over year.
- Operating income of US$10.3B, down 25%.
- Net income US$8.8B, up 19%.
- Diluted earnings per share of $1.14, up 20%.
- Share buybacks and dividends to shareholders totaled US$7.4B (and explain operating income declines).
- Productivity and Business Processes revenue was US$10.2B, up 14%. This included gains in Office Commercial (12%), Office Consumer (8%), LinkedIn (27%), and Dynamics (13%).
- Intelligent Cloud revenue was US$9.7B, up 22%. This included server products and cloud services (27%), enterprise services (4%).
- More Personal Computing revenue was US$10.7, up 8%. This included Windows OEM (9%), commercial products and cloud services (18%), Surface (21%), and more.
Things are jumping upward all over, apparently. MS forecasts this behavior to continue for the rest of calendar 2019 and beyond. The real growth (and driver for future growth) comes from Azure, and its increasing mind and market-share for cloud-based and -enabled tools, technologies and platforms. As a long-time Microsoft follower and fanboy, it’s odd to think of the Colossus of Redmond as a true colossus indeed, even in financial markets. But that’s where and how things stand right now. Given Apple’s rise and subsequent fall from such grace, one hopes MS can hang in there and keep up the good work for some time to come.