Last month, I wrote a blog post here about co-called “corrupt file” messages originating in SFC /scannow. On Friday, August 16, Microsoft published a support note on this issue. It not only explains and acknowledges the problem, it also promises a fix. The good news is that fix will take the form of a new Antimalware Platform update. Specifically, it will carry version number 4.8.1908. The bad news is that the fix is not yet in. I couldn’t even find a download source for that promised next version. A quick check of my Win10 machines, including current-version 1903 PCs and various Insider Previews, shows most of them at version 4.8.1907. That’s why I entitled this post Defender PowerShell hash mismatches fix coming.
What Causes Defender PowerShell Hash Mismatches?
MS offers an explanation and scope for this issue in the Support note entitled “System File Checker (SFC) incorrectly flags Windows Defender PowerShell Module Files as corrupted.” It points specifically to the Windows 10 folder %windir%\System32\WindowsPowerShell\v1.0\Modules\Defender. In the original Windows image, such files use catalog signing. But Windows Defender’s newest manageability component uses an out-of-band (OOB) update channel.Original files give way to updated versions that use a trusted Microsoft certificate instead. Because this differs from the original signing mechanism, file hashes do not match. Thus, SFC flags them as potentially damaged or corrupted with the annotation “Hashes for file member do not match.”
When Is the Defender PowerShell Hash Mismatches Fix Coming?
The Defender update code needs to change to avoid this new and different, but still valid, update mechanism for Windows Defender elements. The note says: “Once this change is implemented, SFC will no longer flag the files.”According to Microsoft, “[t]his issue is fixed in the version 4.8.1908 of Windows Defender. After this update is applied, PowerShell files that are part of the Windows image are not changed, and the SFC tool no longer flags these files.”
MS goes onto recommend the same mitigation/workaround that I described in my previous blog post on this topic. Running dism /online /cleanup-image /restorehealth will replace the new Defender-supplied PowerShell files with the originals from the installed Windows image. Then, SFC /scannow will be able to repair the files it scans on a first pass thereafter, and provide a clean bill of health on the second following pass.
When is 4.8.1908 coming?
We’re talking about the version associated with the antimalware engine for Windows Defender. You can tell what version is running by inspecting the contents of a specific Windows 10 folder:
%ProgramData%/Microsoft/Windows Defender/Platform. The names of its subfolders match the version number. As shown here, the highest numbered folder represents the current antimalware engine version for Windows Defender (see red arrow):
The higher numbered folder (41.18.1907…) represents the current running antimalware platform version
[Click image for full-sized view.]
Of course, as fate would have it, the current version is one level BELOW the promised version that will fix this problem. I checked my Insider Preview and other Win10 PCs (the preceding screen cap is from a Win10 Pro 1903 PC running Build 18362.295). All are running that version, except for Win10 Enterprise 1903 Build 18362.295: it’s running version 4.12.17007.18011-0, dated January 20, 2018. Who knows when MS will drop the new version that will fix the issue? We’ll all be finding out, I guess — hopefully sooner, rather than later!
Yesterday, in the wake of the August 13 KB4512508 update, I noticed some of my local PCs were devoid of Internet access. Upon further investigation, I discovered a few things. First, only wirelessly connected PCs fell prey. Second, only PCs that had Hyper-V enabled were off the Internet. Third, by uninstalling Hyper-V, those PCs immediately resumed their Internet connections. Apparently, the latest CU disturbed my local network topology. Because removing Hyper-V fixed the problem I wrote it off to 1903 Hyper-V networking interference. What was going on, really?
Undoing 1903 Hyper-V Networking Interference
Armed with this knowledge, I had to step through Hyper-V configuration one more time. On my trusty Lenovo X380, I turned Hyper-V back on. This time, wireless Internet access kept working. I noticed that the Default Switch was set up automatically as its name indicates, and that it worked properly. On my previous installation, I’d set up a new and separate virtual switch. And this time around, as soon as I set up a test virtual switch named Hyper-V WLAN Switch (see below), Internet access immediately vanished.
A new switch definition explicitly targets the Wireless NIC for network access
[Click image for full-sized view.]
The proper connection type is indeed “External network,” but the resulting network is labeled Public. Consequently, Internet access vanishes. That’s because the network topology changes. I had to go into my VM settings, and change the Network Adapter to point to the proper virtual switch. I selected “Hyper-V WLAN Switch” from the pull-down menu under the “Virtual switch” item. That did the trick!
As soon as I picked the right “NIC” (virtual switch, actually), LAN access expanded to include the Internet.
Apparently something in the latest update reset the Network Adapter as “Not connected.” As soon as I pointed to my new virtual switch, everything went back to normal. Go figure! Not a difficult fix, but upsetting to have it affect multiple desktops at the same time. One might be happenstance or coincidence; multiples is a conspiracy. That said, I’m glad it’s fixed.
In my last post, I wrote about cleanup as a technique to get PCs to cool off a bit. Since then, I’ve found myself in an investigation that shows determining PC temps can be a tricky business. In fact, using three different toolsets, I get three different sets of temps for my Lenovo T520. Thus I find myself grappling with too many different Win10 temperatures. Which one’s right? I can only lean on research from Tom’s Hardware to find the most accurate and reasonable temp monitoring utility. Based on recommendations from Tom’s that turns out to be Martin Malik’s HWiNFO utility. They recommend that users grab the tool in its portable form, and run it in sensors-only mode. Otherwise, you’ll end up wading through lots of other good system info that’s irrelevant to temp tracking.
What Does Too Many Different Win10 Temperatures Mean?
Alas, it means that the tools I picked to check temps didn’t agree with each other. That’s why I went looking for a recommendation as to which one — namely HWiNFO — bears the closest relationship to real temperatures measured with a probe thermometer. Look at this side-by-side comparison (SIW Pro left, HWiNFO center, Core Temp via CPU Usage Gadget right).
Notice that SIW Pro and HWiNFO are close, but Core Temp is WAY OFF
[Click image for full-sized view.]
For those who don’t want to click the image, and see it in readable form, here’s a tabular version of some of what appears in the preceding graphic (the important temps):
|Core 0||Core 1||CPU Pkg|
As you can tell with a single quick inspection, Core Temp is running around 33 to 34 degrees Celsius lower than the other two utilities on my T520. So now, I auto-correct for this gap by adding 32 to what I see it displaying. The funny thing is, HWiNFO agrees within 1 degree Celsius with Core Temp for the i7-6700 CPU on my production desktop. I’m going to have to conduct a PC-by-PC comparison on the rest of my machines to see how things diverge. All I can say at this point is “Very interesting!”
Putting PC Temps in Context
The afore-linked Tom’s Hardware item includes an interesting chart that it describes as “the nominal operating range for Core temperature.” It also emphasizes that “Core temperatures above 85°C are not recommended.” and “Core temperatures below 80°C are ideal.” Here’s the chart:
Note that my recommended and observed ranges are well within tolerances.
Check out the rest of CompuTronix’s post to the Tom’s Forum thread. Definitely worth reading.
My Lenovo T520 sits on a stand atop a small filing cabinet at the left end of my office desk. I can access it by rotating my desk chair to the left. Mostly, I remote into it from my main production PC right in front of me. Over the weekend, my wife came into the office to talk to me. She stood right at the end of that filing cabinet, right where the fan exhausts heat from that system. “Wow!” she said “That’s some pretty hot air.” I stuck my hand over the same spot, and couldn’t dispute her observation one bit. A quick glance at the CPU Gadget on the T520’s desktop showed the machine was running in the high 60s to high 70s (Centigrade: that’s 140° F to 158° F). Too hot indeed! That led me directly to the idea that a clean-up cools down T520 laptop.
I picked this little vacuum cleaner up from Newegg a few years back. It’s compact and powerful.
[Click image for full-sized view.]
How Clean-up Cools Down T520 Laptop
Normally, laptops run hotter than desktops anyway. My production PC is loafing along in the high 30s to mid 40s right now. The XPS 2720 is idling in the same range (nice for an All-in-One which is more like a laptop than a tower case desktop). My almost-new Lenovo Yoga 380 is idling in the mid 40s to low 50s, which is kind of what I expect from a compact laptop. But for the T520 to be running in the 60-70s is a little alarming.
That got me to thinking: “When was the last time I cleaned the air intakes and outlets on this laptop?” Because it’s been long enough that I honestly can’t remember, I whipped out my DataVac. It’s a special SFF (small form factor) vacuum cleaner designed for sucking up and blowing out dust from electronic gear. I sucked air out of the fan exhaust port for a minute or two. I also took off as many panels from the buttom of the unit as I could using my handy jeweler’s Phillips-head screwdriver. Most of them also serve as air intakes. Sure enough: I saw visible dust inside most of them and vacuumed that up, too.
Cleaning Leads Directly to Better Cooling
Take a look at the output from the CPU usage gadget on the T520, which incorporates temperature readings from the Core Temp utility. Now, temps are ranging in the 50s, which is just what I expect from this older laptop. My 2014 vintage Surface Pro 3 runs a bit hotter, though: it usually idles in the mid-50s to low 60s, and I’ve seen it run as high as 80-plus under heavy load. Just one reason why I keep a small box fan in my office, so I can provide extra ambient cooling for any PC that might need it.
Keeping PCs cooler isn’t just good for the local heat load. Circuitry lives longer when run at lower temperatures. Given that this laptop was purchased in 2012 or 2013 it’s near its end of life anyway. But that’s no excuse for not keeping things clean — and cool! I recommend that desktop and notebooks get dusted and cleaned out at least once every six months or so. More often, if used in dusty environments.
I’ve got half-a-dozen machines that I use to test Windows 10 Insider Previews. Just yesterday, I upgraded my Dell XPS 2720 (Haswell i7-4770S, 256 GB SSD, 16 GB RAM) to Build 18956. After an upgrade I always clean up the PC, update anything that needs it, then make a pristine image backup. One update item popped up from Dell’s SupportAssist application. I needed to update my BIOS from version A15 to A16. In running same, I noticed Dell uses the well-known WinFlash utility. You can launch the BIOS update process from inside the Windows OS. It then schedules a restart after which the heavy lifting is handled in the UEFI shell. So I fired it off, and it reported successful completion. After another reboot, however, the screen remained black and emitted a perpetual sequence of three short beeps followed by a pause. After messing with PCs since the 1980s, I know that post BIOS upgrade beeping means trouble.
If Post BIOS Upgrade Beeping Means Trouble, ‘Sup?
One thing worth noting is that beep codes are not standard, but vary from vendor to vendor (system or motherboard maker). At the Dell site, I quickly learned that even their PC families have unique beep code tables. I did, however, find the XPS beep codes for XPS desktops pretty easily. (The XPS 2720 is an All-in-One and though it’s built like a laptop it’s still classed as a desktop.) Here’s what that table looks like:
Read the 3 entry to see what’s up this time.
[Click image for full-sized view.]
When something like this happens, the first thing is to avoid panic. Second, because you won’t know if the problem is transient or real until you try to reboot again, press and hold down the power button to turn the machine off. When a PC’s BIOS is beeping, you must press and hold that button until the PC turns completely off. Then, after crossing your fingers, press the power button (briefly) to start the PC up again. In this case, the error was transient because the PC booted all the way into Windows 10 without further issues.
Afterward, a quick check of the BIOS in Speccy shows the right date and version number (A16).
A quick check in Speccy shows the BIOS update “took” to Version A16. Whew! What a relief . . .
What If a Reboot Produces More of the Same Beeps?
In my case, code 3 means possible problems with one of the chipsets on the motherboard. For Intel mobos that means potential issues with NorthBridge or SouthBridge chips. If indeed the problem had persisted, a motherboard swap would have been necessary. That’s because these chips are invariably soldered, rather than socketed. Thus, replacing just the chip — and not the whole motherboard — isn’t really an option. It could be done in the right repair facility, but would undoubtedly cost more than a new mobo (I see prices online from $159 to $300 as typical).
On the other hand, it might just be the BIOS itself that’s misbehaving. So before you start buying motherboards, disassembling your PC, and replacing old with new, there’s another thing to try. Motherboards generally include a coin battery. (It’s usually called the CMOS battery, because it keeps the BIOS configuration intact with just a trickle of current.) Sometimes, that battery dies. They only cost $2-3 each, so it’s a worthwhile repair step. Even should a motherboard replacement actually prove necessary, it won’t set your budget back very far to do this first. And who knows? It might fix the problem and put your PC back to work for only minimal cost and effort.
Is a Motherboard Replacement Worth Doing?
When a motherboard replacement really is called for, it’s also time to do some “economic analysis.” If you can do the repair work yourself, it may be worth trying. But if you have to take into the shop and let a professional do the work, your costs will probably be $600 or higher. You can buy a new Dell Inspiron 7000 27″ All-in-One for $800. Rather than spending $600 to bring a 5+-year-old PC back to life, I’d rather spend a couple hundred dollars more to get a new one with roughly the same specs (I’d probably upgrade the RAM and add an SSD myself, though).
That’s what I’d do. Should you ever find yourself in this boat, you’ll have to make that call for yourself. If so, my condolences: it’s never easy to lose a PC, or to have to fork over noticeable amounts of cash to repair them. But so it goes, sometimes, in Windows World.
Part of my job as a Windows Insider MVP means working with — and on — Insider Preview releases. Last Wednesday (July 31) the Insider Team dropped its latest Fast Ring + Skip Ahead release (20H1: Build 18950). I run that software on three machines here at my office. One runs on a Dell XPS 2720 (Haswell i7-4770S CPU), another on a Lenovo X220 Tablet (Sandy Bridge i7-2640 M CPU), and the last one on a home-built desktop (Haswell i7-4770K). So far, I’ve upgraded 2 of those 3 machines completely. Things could have gone more smoothly, though. There’s been a bit of the old “two steps forward, and one step back” along the way. Hence, the description as Insider Preview 20H1 upgrade follies. Let me explain further . . .
The top lines from the MS Flight Hub list show that 18950 joined the Fast Build Ranks on 7/31/2019.
[Click image for full-sized view.]
About Those Insider Preview 20H1 Upgrade Follies
It’s traditional for Insiders to whine, moan, fret and complain about unexpected and untoward things they experience during a Preview’s many and frequent upgrade installs. I hope my tone here isn’t that strident or negative. But I will be observing some surprises that have bitten me, sometimes in tender places, during this latest upgrade round. Some of the usual litany for upgrades include:
- lengthy download times (this one wasn’t too bad: under 5 minutes);
- long install times (none of the three completed in under an hour; one took over 2 hours); and
- strange behaviors during and after the upgrade process.
This latter topic describes most of what I’m writing about today, in fact. You can also glean a lot useful information about this release from the forum members’ comments among the 179 comments currently posted at TenForum’s 18950 announcement thread. So far, I haven’t experienced some of what others are reporting, but everything I report here is also covered there, too.
When the Going Gets Weird, the Weird Turn Pro
Older readers (including your humble correspondent) will recognize this heading as a quote from the Father of Gonzo Journalism, Hunter S. Thompson. And indeed, a strong element of this attitude is necessary for those who deliberately tackle beta software as complex as Windows 10. I can’t say I enjoy being bewitched, bothered, and bewildered by the doings of this sometimes tempestuous and capricious operating system. But I can say, I’ve gotten used to it, and have learned to cope with or work around many of its vexations.
First things first: if you’re going to install Insider Previews on PCs to see what happens, be prepared for the worst. I use Macrium Reflect as my backup tool, and I have Rescue Media for all of my Insider Preview test machines. I always have a reasonably current backup of those machines, and the Rescue Media handy, should an upgrade result in an inoperative or overly hinky system. That hasn’t happened to me with 18950, but I was certainly thinking about booting to the Rescue Media and restoring a backup once or twice along the path I’m about to describe.
Weird Thing #1: Looping/Cycling Install Progress
To my way of thinking, the Windows 10 install process falls into two major parts. One, there’s a GUI install piece, which describes the part happens before the first reboot. Actually, this is the part of the upgrade/install process where the old/previous OS is running the Windows installer. It’s handling the “getting ready,” “downloading,” and “installing” activities that Windows Update reports while they’re underway. Sometimes what TenForums members call “cycling” occurs during the GUI portion of the install. Often, the path from these three activities occurs in the order just described: Getting Ready → Downloading → Installing. Cycling occurs when the process goes back to Getting Ready after showing Downloading or Installing. This happened with 18950 on two of my three test machines.
Two, there’s the post-GUI install when the kernel of the new OS takes over and you see a solid-blue screen. It reads “Working on updates,” and shows a percentage of completion. The same screen also quite correctly says “This could take a while.” It usually does.
For all three of my 18950 test machines, the completion percentages bounced around while post-GUI install was underway. A typical sequence is to see a reboot at around 30% complete, another reboot at 64% complete, and another reboot in the 80s (either 82 or 84% on my test machines). This time, things got whacky in the 40-80% range. My X220 Tablet rebooted three times at 72%, 74% and 80%, then showed 64% complete after the last of those three reboots. Decidedly weird!
All three test machines got entirely through the upgrade process and booted into 18950. But the i7-4700K desktop immediately showed alarming symptoms, which led me to restore the previous version. The Settings path for this goes: Settings → Update & Security → Recovery → “Go back to the previous version of Windows 10.” Therein also likes the “next weirdness” about 18950: networking oddities. I am, however, happy to report that my second upgrade attempt completed successfully.
Weird Thing #2: Wireless Networking Shenanigans
The desktop includes an ASUS 802.11 AC-56 PCIe (x1) wireless adapter that I installed in that machine. It’s right above the Spectrum WiFi WAP in our master bedroom closet, in my son’s bedroom. It gets great bandwidth, up to 400-450 Mbps when the LAN is otherwise quiet. But after the 18950 upgrade, the NIC wasn’t working. A quick trip into Device Manager explained “A driver for this device is not installed.” Also, for some reason, Airplane mode was turned on for this PC. I wrassled around with the driver just long enough to understand that something odd was up with this particular Win10 install. Not only was I unable to install the driver, but the machine was running incredibly slowly and fitfully. That’s what decided me to roll back to 18941 (the previous build on that PC) and try again.
Initially, I wrote this off to issues with the specific WiFi NIC on that PC. Then as I was writing this piece, I fired up the X220 Tablet after the GUI install phase had completed, to restart the PC and let phase 2 get underway. I immediately noticed that it, too, had Airplane mode turned on. (Easily turned off through the notification panel.) It also showed the Network Globe icon in the notifications instead of the more typical WiFi symbol. (This also reappeared when Airplane mode was turned off.) Fortunately, this machine had no other networking issues with the upgrade, either during or afterward. I didn’t get that on the Dell XPS 2720 but then, it’s connected via GbE wired Ethernet, not WiFi.
All’s Well That Ends Well
Some Win10 Insider Preview releases are better than others. This one took me about two hours longer to transit than a problem-free upgrade does. But I keep watching what’s going on, and learning what I can along the way. That’s what beta-testing a big, hairy, complex piece of software like Windows 10 is like. Mostly, I enjoy it.
Sometimes, the Windows 10 upgrade installer blocks 1903 upgrade attempts. As reported in the Windows 10 Known Issues list on August 1, users running Intel RST version 126.96.36.1992 through 188.8.131.523 will get a message from the Installer (see following graphic) that tells them to upgrade to version 184.108.40.2064 or newer (today’s current version is 220.127.116.111, dated July 10, 2019 as I write this blog post). According to the MS remediation info, version 18.104.22.1684 is recommended for affected devices. But in certain cases, Intel RST stymies 1903 upgrade once the new driver is installed! Fortunately, there’s an easy fix should that happen.
Sometimes, this error recurs after an IRST driver update.
[Click image for full-sized view.]
If Intel RST Stymies 1903 Upgrade After Current Driver Installed, Do This!
Thanks to alert and savvy users on TenForums, I learned about this problem and its fix at the same time. As documented in the thread entitled “I updated RST drivers, still get the 1903 error,” user Rafaboss explains that deleting or renaming the old driver version named iastora.sys (he suggests iastora-old.sys) will let users take advantage of the “fix” button that the upgrade installer now presents for 1903 when something goes wrong on a previous install attempt. The target directory for this operation is the default Drivers directory (C:\Windows\System32\drivers). Other users correctly observe that you can use the Open Source DriverStore Explorer (RAPR.exe) tool to do the same thing. Either approach will do the trick, and allow the 1903 Upgrade Installer to proceed to a successful completion.
Thus, there’s no need to stay stymied, if Intel RST stymies 1903 upgrade on any of your PCs. ‘Nuff said!
Last November, I wrote about force deleting Windows.old from one of my PCs. I just ran into the same thing again today, and was pleased to put that information to work yet again. As sometimes happens, I’d already run Disk Cleanup (and its more powerful Open Source counterpart, mdiskcleanup.exe from the Comet project at GitHub). After the cleanup, a Cortana app related bit persistently hung on in the Windows.old directory. But when I tried to delete it using normal methods, it resisted. That’s when I discovered that my old trick still kills persistent Windows.old.
What Old Trick Still Kills Persistent Windows.old?
The command comes from the old-fashioned command line, and its syntax is:
rd /s /q %systemdrive% \Windows.old
I ran it using the standard C: moniker for my system drive, so that became rd /s /q C:\Windows.old. Inspecting my C: drive, I discovered that the Windows 10 Upgrade assistant was also still resident on this machine. So, just for grins I also executed rd /s /q C:\Windows10Upgrade. I’m pleased to report that this cheerfully and quietly did away with that folder and its contents as well. The screenshot to the left illustrates the “before” and “after” directory listings, showing I successfully removed Windows10Upgrade from my desktop PC.
[Note: If the screenshot is too small to read, click the image for a full-sized view. Then click the back-arrow in your browser to return to this post’s text.]
The Old Trick Works for Other Root-level Folders, Too
That’s what allowed me to get rid of Windows10Upgrade, as I explained earlier. But you’ll want to be careful using this command. You could also easily do away with necessary parts of the OS, such as Program Files, Users, or even Windows itself. If you can’t recover that stuff from the Recycle Bin, you’ll be left with a broken Windows installation. That’s among the many reasons why I back my production system up with an image backup in Macrium Reflect at 9:00 AM every morning. Don’t mess around with root-level system drive stuff unless you have a current image backup, too!
My Surface Pro 3 (vintage 2014) is still chugging gamely along in my office. I use it as an Insider Preview Slow Ring test machine. Each time I upgrade the OS (about weekly, these days), I clean up Windows.old and make a backup of the newly installed OS. Entirely routine and ho-hum. But this morning, when I went to check my backups on that machine, I found none for the past couple of months. By looking at the dates available on the Insider Flight Hub, I can tell it’s been failing since Build 18908. That’s ultimately how I figured out that protecting backup card proves essential, too. Let me explain . . .
The source of the problem on this dual mSATA USB card was electrical, and my own stupidity.
[Image Source: Newegg SYBA Dual mSATA RAID Adapter]
Why Protecting Backup Card Proves Essential
Operator error can strike in strange ways. First, I have to explain that the backup device on my Surface Pro 3 (SP3) is a dual mSATA USB card. (See preceding image link for details). It’s just a naked circuit card. It’s attached via a short connector cable into a USB3 port at the rear of the Surface Pro 3 dock. By happenstance, I’ve got the SP3 on a baker’s rack next to my office desk. Turns out that the SYBA card somehow moved (the Boss dusts my office regularly) from its usual place on the plastic covered dock base onto the metal shelf on which the dock rests. I can only speculate that at least two of the contacts on the back of the circuit card must’ve made contact with the metal wire shelving. Result: a short that prevented the circuit card from doing its job (and the backup from completing).
Sigh. It’s always something. I could fix the problem permanently by putting the card (which has the same form factor as a SATA laptop drive) in an enclosure. I may very well do so. But for now, the card is back up on the dock and working perfectly (I just made a successful backup). I’ll ponder adding something like the Inatek 2.5″ USB 3.0 Hard Disk Enclosure (FE2002) to my next Newegg order. Heck: it only costs about US$18 and will prevent future backup failures. I probably should have done this in the first place!
DPC is Windows shorthand for “deferred procedure call.” As explained at Resplendence.com (makers of the outstanding, free LatencyMon tool) the Windows thread dispatcher (aka “the scheduler”) handles prioritization of threads scheduled for execution on a given processor. Assume a high-priority thread works its way into the scheduling mix. Then, lower-priority calls for service get deferred and higher-priority threads run sooner. If that results in audio services delay, this can cause “stuttering” in sound output. And that, in fact, is what causes DPC Latency. (Literally, this term measures the amount of time it takes for a deferred procedure call to finally get a turn at the processor — and playback for audio.) That’s why learning that KB4505903 fixes DPC latency issue is good news, especially for those with affected PCs. Here’s a tweet from MS Engineer Pete Brown from Saturday, July 27:
Tweet Proclaims That KB4505903 Fixes DPC Latency Issue
As the preceding tweet capture shows, KB4505903 gets credit for fixing DPC latency spikes in Win10 1903. That’s good news for those with PCs suffering from audio latency issues. If this applies to PCs in your care, use LatencyMon to make before and after measurements. These should show visible (and audible) improvements in audio behavior. LatencyMon is a good tool for troubleshooting PC audio issues. It’s worth adding a copy to your admin toolbox for that reason. Who knows when another Windows 10 version or update may once again introduce audio delays, clicks, pops, or whathaveyou? I’ve dealt with such stuff personally since the Windows 8.x era, and repeatedly with various Win10 versions, too. Better safe than sorry!
For more information on symptoms of and resolution for this issue, see these various TenForums threads: