The other day, I had Windows Defender scan all of my disk drives. This action artificially provoked a performance alert on one of my Lenovo laptops. While it was running it reported 8 malware items on my D: (Data) drive. Please note: all of these are categorized as “HackTool” items. MS correlates them with specific malware items and known exploits.  After overcoming my initial alarm, I looked where those items were found. All resided under parent directory D:\NirLauncher. Immediately, certain things became clear. Every one of the suspect elements is a password sniffing and capture tool in Nir Sofer’s collection of Windows Utilities. In fact, he’s got a category within that collection of 200-plus tools called “Password Recovery Utilities,” which comprises 20 items (see below). All of them popped up here. Aha!

Once it found these items, Defender forced me to have it ignore these threats to retain access to them.
[Click image for Full-Sized View.]

If Certain Legit Tools Generate Windows Defender False Positives, Then What?

Once Defender finds something suspect, you must remove that item from its clutches before you can use it again. That meant I had to open Windows Security → Virus & threat protection, then click on each item it found. Next, I clicked “See details,” and then explicitly told it to ignore each threat one at a time.

As you might expect, there’s a better way to deal with this kind of thing if you prepare in advance. If you click “Manage settings” inside the Virus & Threat protection pane, you’ll find an Exclusions setting right below Controlled folder access. Click “Add or remove exclusions” and you can instruct Defender to bypass specific files or folders. I simply added an exclusion for the D:\NirLauncher folder and it will now be ignored in future complete system scans (the Quick Scan option only accesses the Windows C: drive anyway).

Pre-emption Beats Reaction Whenever Possible

Currently, I use several utilities that Defender flags as threats. In addition to NirSoft’s password utilities (which NirLauncher includes amidst its collection of tools), I’ve had to exclude Gabe Topala’s System Information for Windows (siw.exe). In days of yore, before I started using Superfly’s ShowKeyPlus, I used a tool called Magic Jelly Bean Finder that likewise got flagged. I excluded it, too.

The moral of the story is this: if you’re planning to install (or copy standalone) tools that find passwords or keys, chances are pretty good that Defender will flag them as Hacktools. If you take steps to exclude them in advance, you can avoid having to “Ignore” them later on. But please: make sure you run any such software through VirusTotal to be doubly darn sure it’s safe before allowing it to take up residence on your PC. Such tools can indeed be used for malefic purposes, as well as legitimate ones. Be safe out there!

You know, there are more benefits to keeping software up-to-date than just avoiding security vulnerabilities. They even go beyond the pleasures of good housekeeping. When I couldn’t run Albacore’s excellent Disk Cleanup reaplacement (mdiskclean.exe) on my Lenovo X220 Tablet this morning, I started troubleshooting. Along the way, I found it ran just fine on my X380 Yoga (my other Fast Ring test machine). “Hmmm,” I said to myself, “let me compare the file dates.” And sure enough, I was running an April 2019 version of the project. However, the X380 was running a newer, May 2019 version. A quick online check confirmed that May 2019 is the latest and greatest version. Thus, I concluded that old MDiskClean.exe throws System.InvalidOperationException error. Those details appear in the lead-in graphic above.

If Old MDiskClean.exe Throws System.InvalidOperationException Error Then Update!

Indeed, my next move was to grab a copy of the current version. I replaced the old, outdated April 2019 version with the current May 2019 version. Then I ran the program again. This time, it worked like a charm. There was nary a trace in the Reliability Monitor of its passing, either. Sometimes, the easy fix is also the right fix. I’m glad to report that this is one of those times. The problem is solved.

With the current (05.2019) version running and working, mdiskclean.exe looks exactly like Disk Cleanup, except it lets you show all available selections at the same time.

Disk Cleanup limits the display area to 5 items, so you have to scroll like mad to get through a big list.

If you should run into application level errors in Reliability Monitor, it’s smart to check the application itself first before taking troubleshooting further. In this case, that was as far as I needed to go. Had that not helped, my next move would have been to run the system file checker (sfc /scannow) and to perform a DISM componentstore health check (dism /online /cleanup-image /checkhealth). Normally, that would be as far as one would need to go at the application level. Beyond that, though, comes an in-place upgrade repair install (TenForums Tutorial) and finally a clean (re)install (TenForums tutorial). Glad I didn’t have to break out any of that heavy artillery. Cheers!

I’m a big fan of Reliability Monitor. This is actually a strange and useful offshoot from Performance Monitor (aka perfmon or perfmon.exe). As I will explain, little gotchas from tales of two Relmons actually shed more light on system health than a straight-line perfect 10 rating across the board.

That’s what makes the tale of the second relmon (the first appears at the head of this story) more informative, in fact. Interestingly, type perfmon /rel into the search or run boxes for a quick launch method. Reliability Monitor (RelMon) does a good job of tracking and reporting on errors that occur in day-to-day Windows operation.

Over the years, I’ve learned to rely on RelMon (a) to check on the general health of my systems, and (b) as a place to look when noticeable errors or crashes occur. Those red Xs provide a strong visual clue when something isn’t right. Also the details RelMon delivers to back things up are helpful. They often provide important clues in deciding if a problem needs addressing, and if so, how one might start down that path. Here’s the second of the two RelMon outputs I’d like to present today:

This report from my production X380 Yoga, shows minor niggling errors. Most come straight from Windows 10 components or apps, in fact.
[Click image for full-sized view.]

Little Gotchas from Tales of Two RelMons Show Perfection Is Over-Rated

My first instinct when looking at “red X” detail in RelMon is to see what kind of software or other system component threw the error. Most of them, as with the preceding screencap, appear in the “Application failures” line. That means they report some kind of application or app error.

In general, I’m a lot less worried about those than I am about Windows failures (line 2) or Miscellaneous failures (line 3). That said, let’s look at what caused a nearly 3 point dip on March 27. Two errors are reported. One is a Lenovo software component (probably associated with Lenovo Vantage, which I use for driver and BIOS updates). The other is the Settings application itself. The Lenovo item shows up as an Explorer shell extension: the problem event name BEX64 is quite familiar. In the other error, the Settings app stopped communicating with Windows and was closed. In other word, Settings hung for one reason or another. No big deal: happens sometimes, but not often. An explorer restart fixed this: read all about it at Win10.Guru.

When RelMon Spurs Me to Act

In contrast, let me recite a recent list of items from RelMon that have spurred action and repair maneuvers:

• A repeated driver crash on iahStorA.sys (part of Intel’s Rapid Storage Technology) helped me decide to uninstall RST on that PC. It’s required for RAID, which I don’t use.
• When CCleaner started throwing errors on a couple of PCs, it too got uninstalled. The makers have changed to a “more friendly” UI, and I don’t like it much anymore.
• A long series of MoAppCrash errros from Outlook led me to the Microsoft Support and Recovery Assistant. It fixed my problem and is a valuable addition to my Windows toolkit.
• When the Skype UWP app started crashing every two-three days, I used PowerShell to remove it. Never used it, either (plenty of laptops with microphones and webcams for online action).

Most of the time, when a RelMon error calls for action, you’ll be able to figure that out quickly. Sometimes, if it’s an essential Microsoft component, all you can do is report the error via Feedback Hub, and hope for a speedy patch or fix. But with time and experience, these things will sort themselves out. If something you don’t need, use, or perhaps even want causes a problem, it may just be best to uninstall or remove it.

One week ago today (March 30), MS released an optional update KB4554364 through the Microsoft Update Catalog. This update is discretionary (though it will probably get rolled up into the next Update Tuesday on April 14). The update was released specifically to address reported issues with certain VPNs and with Internet connectivity problems for certain applications. If one has no such problems, it’s not necessary to install KB4554364. I just went ahead and did it anyway on one of my PCs. Why? Because the process of installing KB455364 illustrates MS Catalog Update install actions and behavior. That’s the subject for today’s blog post, in fact.

To begin the process, one must download the update from the MS Update Catalog. The entry for the 64-bit 1909 version of this item provides the lead-in illustration for this story. If you click the download link at the far right, you’ll be prompted to confirm that download in a pop-up window. Note: this download is named windows10.0-kb4554364-x64_0037f0861430f0d9a5cea807b46735c697a82d0c.msu. The file extension at the end of the file name — .msu — indicates it will call the Windows Update Standalone Installer to install itself. Careful inspection of the filename shows it identifies numerous aspects of the update involved:

• windows10.0 identifies the operating system target as Windows 10
• kb4554364 identifies the governing knowledge base article that describes this particular update
• x64 identifies that the update is for 64-bit OSes
• the long string of digits is a globally unique identifier (GUID) for this particular self-installing update file
• the .msu file extension, as already mentioned, indicates that this file calls on the Windows Update Standalone Installer to apply the update(s) it contains. Some updates come in the form of cabinet (.cab) files. I’ll explain how to install those in the concluding section of this blog post

Step 2: KB4554364 Illustrates MS Catalog Update Install with Installer Start-up

To launch the self-installing update file, double-click it in File Explorer, or right-click and select “Open” from the pop-up menu. This launches the Windows Update Standalone Installer, depicted in the following screencap:

When the Windows Update Standalone Installer starts up, it asks you to confirm installation of the targeted update (KB4554364, in this case). Click “Yes” to fire off the update process.

Step 3: KB4554364 Illustrates MS Catalog Update Install with Update Installation

First, a status window appears that indicates the Windows Update Standalone Installer has begun its work. As you can see it report that is is “Initializing installation…”

Once the intialization phase is complete, the Standalone Installer reports that it is installing the specified update (KB4554364)

This takes some time to complete, but eventually you’ll see a report that the update installation has completed

At this point, the update won’t take effect until the host PC is restarted. Thus, you have the option of forcing an immediate restart (click the “Restart now” button). OTOH, if you have unsaved or unfinished work on that system, or aren’t yet ready to restart, click the “Close” button and keep on computing. You can manually restart later at a more convenient time, or the PC will automatically restart when the next eligible restart time window comes around.

Installing Cabinet Files from the Windows Update Catalog

You can use the DISM command to install .cab files downloaded from the catalog. I find it easiest to shift right-click the download entry in File Explorer, then use the “Copy as path” option from the pop-up menu. As an example, I just did so with the .cab file named "C:\ProgramData\Package Cache\{CE83D0BD-418A-F3D1-D6CE-687E96D1EBD0}v10.1.17763.132\Installers\ff8dd5a961e46b5d05906ac4b7a5ba37.cab" purely for illustration. The proper DISM syntax is:

dism /online /add-package /packagepath:path-spec

Thus, for the preceding path specification, this becomes:

dism /online /add-package /packagepath:C:\ProgramData\Package Cache\{CE83D0BD-418A-F3D1-D6CE-687E96D1EBD0}v10.1.17763.132\Installers\ff8dd5a961e46b5d05906ac4b7a5ba37.cab

If the path specification includes any spaces, leave the quotation marks around that string. Otherwise, as you see above, it’s OK to remove them. This will apply an update-package in .cab format to your current, running Windows image.

Cheers!