Device drivers, Insider stuff, Recent Activity, USB devices, Windows 11

USB Ports Need More Storage Bandwidth

2 Comments

In reading over Computex coverage I’m impressed by an array of newer, faster computing platforms and storage technologies. At the same time I’m depressed that USB-attached storage is not swimming in this rising tide of increased performance and capability. Simply put: USB ports need more storage bandwidth so they can hold up their end while ushering in a brave new world of performance computing. Let me explain…

Why USB Ports Need More Storage Bandwidth

Thunderbolt 4 tops out at 40 Gbps — that’s a theoretical ceiling of roughly 5 GB/s, and real-world storage transfers run well below that. It was impressive when it arrived. It isn’t anymore. Thunderbolt 5 moved the needle, pushing up to 120 Gbps on the read side and 40 Gbps on writes. Indeed, its asymmetric bandwidth design delivers somewhere in the neighborhood of 6–7 GB/s of actual storage throughput under optimal conditions.

That’s a real boost, and to give credit where it’s due: Intel’s Thunderbolt 5 is the current high-water mark for USB-attached external storage performance. But here’s the problem — “high-water mark for external” and “keeping pace with internal” are two very different things. Alas, the gap between them is widening fast.

Phison’s PCIe 5 Controllers: Lapping the Field

Let’s talk about what’s happening inside the box right now. Phison’s E26 controller — the flagship PCIe 5.0 x4 part — pushes sequential reads up to roughly 14 GB/s and writes near 12 GB/s. That’s not a roadmap promise. That’s shipping silicon, today, in drives like the Crucial T705 and Seagate FireCuda 540. And the reason those numbers are possible is that PCIe 5.0 x4 delivers approximately 32 GB/s of raw bus bandwidth — a figure Thunderbolt 5’s best-case scenario can’t remotely approach.

I’ll be blunt: Thunderbolt 5 running at its theoretical maximum is still less than a quarter of PCIe 5’s available bus bandwidth. External storage users are working with a narrow pipe while internal NVMe users are drinking from a fire hose. And here’s what makes it even more galling — PCIe 5 SSDs themselves are already hitting their ceiling and looking nervously at what comes next. The interface they’re starved for is PCIe 6, which is already coming down the pipe.

Phison PCIe 6 Controllers: Next Tier Is Here

Computex 2025 was where Phison first made the PCIe 6.0 future feel real, and the momentum has only built from there. The next-generation Phison controller roadmap targets PCIe 6.0 x4 — an interface that theoretically delivers around 64 GB/s of raw bandwidth per slot, thanks to PAM4 signaling running at 64 GT/s per lane. Real-world sequential read targets are north of 20 GB/s.

Think about what that means for Thunderbolt 5’s ceiling. A single PCIe 6 SSD — one drive, one M.2 slot — could in principle saturate nearly five simultaneous Thunderbolt 5 connections running flat out. The Thunderbolt bandwidth ceiling doesn’t just look inadequate at that point; it looks comical. External storage users are so far behind that “catching up” is a massive understatement. Instead, designs must condider a completely different approach.

What Needs to Change?

USB4 Gen 3×2 sits at 40 Gbps — identical to Thunderbolt 4, still not enough. USB4 v2 bumps that to 80 Gbps, which helps at the margins but still lands less than a third of PCIe 5’s bus bandwidth, let alone PCIe 6’s. These are incremental improvements on an interface that needs a fundamental rethink, not a spec bump.

The industry needs a paradigm shift. Either Thunderbolt 6 or USB5 — whatever we end up calling it — must arrive with dramatically higher bandwidth, we’re talking 200+ Gbps as a floor, not a ceiling. Alternatively, PCIe tunneling over external cables needs to mature to the point where it can fully exploit NVMe speeds without  overhead that kills performance today. One or the other. Probably both, eventually.

Until one of those paths becomes real and shipping, external storage users are locked in a performance ghetto. Internal SSD buyers are sprinting ahead with every product generation. The storage industry owes external storage users a credible, substantive answer. I’m not talking about another incremental spec revision, not another narrowly defined workaround. Computex 2026 is the right venue and this is the right moment. USB silicon designers need to envision, then deliver something worth getting excited about. So far, I can’t see it. Let’s hope for something amazing, shall we?

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Secure Boot, Security, WED Blog, Windows 10, Windows 11

Explainer: Secure Boot Chain of Trust

1 Comment

Here’s an uncomfortable, seldom considered truth: your operating system isn’t the first thing that runs when you power on your PC. The firmware goes first. Then the bootloader. Then the OS kernel. Malware creators figured this out a long time ago. Get in early enough — before the OS loads — and you can own a machine invisibly, surviving reboots, reinstalls, and even antivirus scans. All this explains why the secure boot chain of trust is vital to modern Windows security.

The threat is real and it’s present right now. BlackLotus, a UEFI bootkit sold on criminal forums, made headlines in 2023 for bypassing Secure Boot on fully patched Windows 11 systems. BootHole exposed a critical flaw in GRUB2’s boot process that affected both Linux and Windows. PKFail (2024) revealed that dozens of device vendors had shipped products using a leaked “do not ship” test Platform Key — meaning the root of the entire trust hierarchy was compromised straight out of the box. Then, in January 2025, ESET researchers disclosed CVE-2024-7344: a Microsoft-signed UEFI recovery application that could silently load unsigned bootkit code — on any UEFI system, regardless of whether Secure Boot was enabled. Microsoft pulled the vulnerable binaries in the January 14, 2025 Patch Tuesday update.

Boot-time attacks aren’t theoretical. They’re happening. Under-standing Secure Boot’s chain of trust is the first step toward knowing whether your defenses are actually holding.

Understanding the Secure Boot Chain of Trust

Think of the chain of trust as a series of checkpoints at the border. Each checkpoint must vouch for the next before anything is allowed through. No vouching, no entry, and the boot process stops dead.

In technical terms: every component in the boot sequence verifies the digital signature of the next component cryptographically before handing off execution. The firmware checks the bootloader. The bootloader checks the OS kernel. The kernel checks drivers. If any link in that chain can’t be verified — wrong signature, no signature, a signature that’s been revoked — the process stops. Your PC refuses to proceed rather than run untrusted code. That’s the whole point. Always safe means never sorry, even if it also means a PC that won’t fire up and run.

The chain only works, of course, if the first link is trustworthy. That’s where the UEFI key hierarchy comes in.

The Key Players: PK, KEK, db, and dbx

UEFI Secure Boot manages trust through four interlocking databases baked into your firmware. Get familiar with them — they come up constantly whenever something goes wrong at boot time.

Key / Database Full Name Role
PK Platform Key Root of trust. Set by the hardware manufacturer. Controls who can update KEK.
KEK Key Exchange Key Authorized to update the signature databases (db and dbx).
db Signature Database Hashes and certificates of trusted bootloaders allowed to execute.
dbx Forbidden Signatures Database Revoked signatures and hashes. Anything here is blocked unconditionally.

The PK sits at the top. Your motherboard manufacturer owns it. Below the PK, the KEK authorizes who gets to update the lists of trusted and forbidden signatures. In practice, Microsoft functions as the de facto Secure Boot Certificate Authority for the consumer PC ecosystem. Nearly every machine you buy ships with Microsoft’s certificates pre-loaded in db — exactly why CVE-2024-7344 was so broadly dangerous. A legitimately Microsoft-signed binary became a usable attack vector!

Worth Knowing: PKFail and the Test Key Problem

In 2024, the PKFail vulnerability revealed that over 200 device models from multiple vendors shipped with a Platform Key originally marked “DO NOT TRUST” — a sample key from AMI’s reference firmware that was never meant to leave the lab. When your PK is public knowledge, the entire root of trust collapses.

How the Chain Is Created at Boot Time

Power on your PC, and here’s what actually happens — fast, invisible, and mostly taken for granted.

  1. The UEFI firmware initializes hardware and activates Secure Boot mode.
  2. The firmware reads the bootloader from the EFI System Partition and checks its signature against db. It also checks against dbx — if it’s there, execution stops immediately.
  3. The signed bootloader (Windows Boot Manager, for example) takes over and verifies the OS kernel’s signature using its own embedded certificates.
  4. The kernel loads and verifies signed drivers. On Windows, this is enforced through Driver Signature Enforcement — unsigned kernel-mode code is blocked by default.

Every handoff is cryptographically verified before it happens. Compromise any link — plant an unsigned binary, exploit a signed-but-vulnerable loader, sneak past a misconfigured dbx — and an attacker owns your machine below the OS waterline. That’s precisely the attack surface that BlackLotus, BootHole, and CVE-2024-7344 each exploited in different ways.

Maintaining a Strong Chain of Trust

Secure Boot isn’t a “set it and forget it” control. Maintaining a healthy chain of trust requires ongoing attention from both Microsoft and from you.

The most important maintenance lever is the dbx — the blocklist. When a bootloader is found vulnerable (as happened with a batch of 2011-era Microsoft-signed binaries in 2023, and again with the CVE-2024-7344 binaries in January 2025), Microsoft issues dbx updates through Patch Tuesday. Your firmware then refuses to execute those specific binaries even if they’re somehow placed on the system. Keeping Windows Update current is how those revocations reach your PC.

Firmware updates matter just as much. Vulnerabilities in the UEFI firmware itself require OEM-supplied updates delivered via Windows Update or manufacturer tools. The NSA and CISA have both issued guidance recommending that organizations periodically audit their Secure Boot configuration — confirming the correct keys are enrolled, the dbx is current, and no rogue Platform Keys are in place (a lesson PKFail drove home hard).

Complementing Secure Boot is the TPM’s Measured Boot capability. While Secure Boot enforces what can execute, Measured Boot records cryptographic measurements of everything that did execute into TPM Platform Configuration Registers (PCRs). Remote attestation tools can then verify those measurements after the fact. Think of Secure Boot as the bouncer at the door; Measured Boot is the security camera logging who actually got in.

Why the Chain of Trust REALLY Matters

Secure Boot isn’t perfect — BlackLotus, BootHole, PKFail, and CVE-2024-7344 all proved that. But “not perfect” is a long way from “useless.” It raises the cost and complexity of boot-level attacks significantly, and when the ecosystem keeps the revocation databases current, it closes known attack paths quickly.

Do yourself a favor: open System Information (msinfo32), find BIOS Mode (should read UEFI) and Secure Boot State (should read On). If either is wrong, fix it. Keep your firmware updated. Keep Windows updated. The chain of trust is only as strong as its weakest, most-neglected link — and that link is usually sitting right between the keyboard and the chair. Here in Windows-World keeping track of key security concerns is darned important. The Secure Boot chain of trust should be at the top of everyone’s list.

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Secure Boot, WED Blog, Windows 11

Another Toolset for Secure Boot Checks

Leave a comment

Yesterday, I read my way through the latest AskWoody newsletter. In Susan Bradley’s article “Check Those Browsers” I found reference to Secure Boot checks: “If you merely need to run a script to check the UEFI KEK, DB, and DBX Secure Boot variables, you can use this one.” Because the source wasn’t directly named, I followed that link to access cjee21’s scripts entitled Check-UEFISecureBootVariables at GitHub. And there, I found another toolset for Secure Boot Checks — and a good one, too.

Why Grab Another Toolset for Secure Boot Checks?

You can (and probably should) visit GitHub to grab cjee21’s Check-UEFISecureBootVariables. At the time of writing it’s sitting at 226 stars and was updated two days prior — such active maintenance on a niche diagnostic utility is a good thing. This is the tool you want when your first question is “What do I actually have on this machine?”

Its orientation is forensic and inspection-first. It surfaces everything inside the UEFI Secure Boot variable store: PK, KEK, DB, DBX, event logs, and XML dumps of the full variable contents. Most people working a CA-2023 compliance problem have never actually looked at those variables directly. This tool makes that straightforward.

Two specific components stand out for CA-2023 work:

  • Check EFI file info.cmd — This is the direct answer to what Get-AuthenticodeSignature lacks. Point it at an .efi file and it explicitly tells you which CA signed it (CA-2011 or CA-2023), along with the SVN, SBAT level, and raw version data. That’s the specific question you must answer, and this specific tool answers it.
  • Scan ESP for revoked files.cmd — This one scans EFI binaries on a drive against the live Microsoft DBX revocation list. If you’re checking USB boot media for compliance — a Ventoy stick, a WinPE drive, a rescue environment — this is the fastest way to know whether anything on it has been revoked.

Don’t Forget the Garlin Scripts (ElevenForum)

Cjee21’s scripts show and tell you what you’ve got. Garlin’s ElevenForum Scripts tell you what to do about it. This pair of scripts: Check_UEFI-CA2023.ps1 and Update_UEFI-CA2023.ps1, are action-oriented where cjee21’s tool is inspection-oriented. At 38 GitHub stars it’s a smaller project, but it was updated approximately two weeks before writing and recent commits show active refinement, including a fix for a bug in SVN signature data ordering. The associated forum thread is VERY active, and usually gains 2-3 pages per day.

The workflow is deliberately linear and guided: run Check_UEFI-CA2023.ps1 to assess your current CA-2023 status, then run Update_UEFI-CA2023.ps1 to fix whatever it finds. The scripts source certificates from \Windows\System32\SecureBootUpdates and the official Microsoft Secure Boot Objects repository, so you’re not pulling from unofficial or unverified sources.

A few things make the Garlin scripts especially helpful:

  • USB removable media support — It handles boot file updates for USB recovery media like Macrium Reflect drives and similar tools. This is a gap that most documentation quietly ignores.
  • Broader architecture coverage — x64, x86, arm64, and arm are all supported, which gives it wider applicability than you might expect from a community script.
  • Accessible for non-specialists — The guided, opinionated workflow means you don’t need deep UEFI expertise to use it. The script makes the decisions; you confirm them.

Complementary, Not Competitive

Again: the cjee21 scripts show you what’s what with Secure Boot on a Windows PC, at a deep level of detail. More than many of us want to know, in fact. The Garlin scripts tell you what to do about your current status, and help you set things right on installed systems and for bootable media.  A great combination, well worth exercising. Give them a try, if you haven’t already.

Facebooklinkedin
Facebooklinkedin
Cool Tools, Copilot+ PCs, Insider stuff, Recent Activity, WED Blog, Windows 11

MS Readies Copilot Key Remap

Leave a comment

How often do I use Copilot? Multiple times a day, sometimes for hours at a go. How often do I use the Copilot key on a Copilot+ PC to access same? NEVER (I tried it out on an early laptop, saw it worked, and never used it again). I’m pretty sure most other users work the same way. Thus it came as no surprise and something of a relief to read news that MS Readies Copilot key remap in some upcoming Windows 11 update.

Why MS Readies Copilot Key Remap

This plan surfaced in a recently published Microsoft Support Note entitled ” Understand updates to the Copilot key on Windows devices,” Copilot finds no publication date for this item, but guesstimates it appeared on May 18  (yesterday, as I write this post).

Here’s how that note starts out:

Starting in 2024, hardware manufactures released new Windows 11 devices that include a dedicated Copilot key that provides quick access to Copilot experiences in Windows. This Copilot key sometimes replaces the Right Ctrl key or Context Menu key on select devices.

Customers who rely on the Right Ctrl key or Context menu key for keyboard shortcuts or assistive technologies (such as screen readers) experienced some challenges to their workflows when using these devices.

The important info comes next, and explains how things will work once this update appears:

A Windows 11 update will ship later this year that will add a setting option to let you remap the Copilot key to act as the Context menu key or Right Ctrl key. When available, you can find this setting in: Settings > Bluetooth & devices > Keyboard

What Does Copilot Key Remap Mean?

It’s an implicit ACK from MS that some (or many) people don’t use the key. Better, however, it’s a means for those who need the key that used to sit where the Copilot key now rests will get an official way to restore it (or rather, its functions as the Right CTRL or Context menu key) on their keyboards. Good enough for me!

When will this appear? MS isn’t saying yet. But they wouldn’t dangle it out there if they weren’t already working on it. My best guess is months, not longer. I’ll keep an eye on things and let you know when more news is available.

And here’s a concluding irony: I’m current working on a Logitech  Wave Keys keyboard on the Flo6 desktop. No Copilot key here, and I don’t miss it at all, not even one little bit.

Facebooklinkedin
Facebooklinkedin
Cool Tools, Device drivers, Insider stuff, Recent Activity, WED Blog, Windows 10, Windows 11

Intel DSA Remains Driver Install Clickmeister

1 Comment

I just realized that DSA was MIA on my ThinkPad X12 Gen 1 Detachable Tablet. So I installed it, then ran it. It found 3 drivers in need of updates on that device: Wi-Fi, Bluetooth, and (Xe) Graphics. In updating them, I observed that the  Intel Driver and Support Assistant (Intel DSA) remains driver install clickmeister supreme. Let me explain…

Why say: Intel DSA Remains Driver Install Clickmeister?

It’s long been my observation that using DSA requires lots of mouse clicks. This time around, installing the three drivers shown in the lead-in screencap required at least 24 mouse clicks. For the record, those drivers were (numbers at right count clicks for each one):

  • Wireless Bluetooth Drivers (9)
  • 11th-14th Gen Processor Graphics (10)
  • Wi-Fi Drivers (5)

This time around it actually took me 4 additional mouse clicks to get from item 2 to item 3, because I was installing the GPU driver for the first time. Thus, I had to reboot my system, because DSA got “stuck” on “installing” for item 2, and wouldn’t advance to item 3. Sigh. I didn’t count those “extra” clicks in my reported total.

Achieving Intel Driver Update Silence

Believe it or not, that’s the title of a blog I posted on April 27, 2023. That was another time when the sheer number of clicks involved in running DSA hit me hard. It remains noticeable. Today, it struck me as excessive. So I’m formulating this plea to the Intel DSA developers:

Please add a silent mode switch to DSA. Let users tell the tool to run the installs without requiring minutes of babysitting to get through routine maintenance.

I wonder if anybody is listening. Then, I wonder if they’ll respond. Here in Windows-World the silence can sometimes be deafening. Let’s see what happens, shall we?

 

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Secure Boot, WED Blog, Windows 11

MCT Now Delivers CA-2023 Bootloader

Leave a comment

There’s the thing about working in Windows IT long enough.  You develop a finely tuned instinct for when something sounds simple but absolutely isn’t. Microsoft has been gradually rolling out Secure Boot CA-2023 support, and the boots-on-the-ground question I needed to answer was about as plain-English as it gets: is the bootable USB drive sitting on my desk actually CA-2023 compliant, or not? A yes-or-no question. It took me a while, but I finally got the answer: As of 4/30/2026, MCT now delivers CA-2023 bootloader and compliant WIM (or, in this case, “split WIM” aka .swm) files.

Determining That MCT Now Delivers CA-2023 Bootloader

At first, I got sidetracked by Copilot. It recommended the PowerShell command Get-AuthenticodeSignature to check status. Alas, the bootloader is “dual-signed” which means it’s signed with BOTH CA-2011 AND CA-2023 certificates. And because the 2011 gets picked up first, the PS command reports it ONLY as signed with the older certificate. It was indeed signed with CA-2023 (and compliant) but my check couldn’t tell me that. Sigh.

So I changed gears and used Garlin’s wonderful (and entirely accurate) Check_UEFI-CA2023.ps1 script from ElevenForum. You can see its output in the lead-in graphic. In a nutshell, it shows the USB stick as CA-2023 compliant. Flo6 ditto, with CA-2011 revoked.

But First, You Must Be Punished…

I dithered around with Copilot for an hour or so trying to “replace” the CA-2011 bootx64.efi file with a CA-2023 compliant version. Until I switched to the Garlin script, I didn’t realize already WAS CA-2023 compliant. That’s when I figured out that indeed MCT now provides CA-2023 compliant bootloaders and image files.

How so? That definitive answer comes from the afore-named PowerShell diagnostic script  — a tool specifically designed to tell you, clearly and unambiguously, whether your Windows system and its boot media are CA-2023 ready. The syntax for that check is:

.\check_UEFI-CA2023.ps1 -bootmedia -verbose

My recommendation: run the Check_UEFI… script to check your system, and bootable USBs. Even if you’re confident that your MCT media is fresh and your system is current, Garlin’s script is the only way to get a clean yes-or-no on your specific configuration. Think of it as the verification step that turns “I think I’m good” into “I know I’m good.”

Between MCT now generating compliant media by default and a trustworthy diagnostic tool available to confirm it, the CA-2023 story is getting meaningfully less murky. We’re not all the way there yet — but for once, things are actually trending in the right direction. I’ll take it. Here in Windows-World, that’s about as good as it gets!

 

 

 

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, Troubleshooting, WED Blog, Windows 11

Troubleshooting Flo6 S3 Sleep Oddities

Leave a comment

Now that I’m back to a normal work pattern, I couldn’t help but notice that the power button on my Flo6/MSI B550 Tomahawk PC was blinking this morning. That means it’s sleeping and needs a touch to wake itself back  up. Indeed, that blinking power button is the unmistakable signature of S3 sleep — Suspend to RAM — where the system cuts power to everything except memory. Nobody asked it to do that. Time to find out why it thought that was a good idea. Hence, I found myself troubleshooting Flo6 S3 sleep oddities.

Troubleshooting Flo6 S3 Sleep Oddities: Step 1

My first move with any uninvited sleep behavior is to open an elevated command prompt and run powercfg /a. This dumps a plain-English summary of every sleep state the OS currently considers available — and, crucially, tells you which ones are actually enabled. The lead-in graphic shows what Flo6 reported.

That told me everything I needed to know at a glance. S3 was alive and well. Hibernate was also active. Windows had a full menu of power-down options available to it, and apparently it was helping itself. The next question was: what power plan setting was pulling the trigger?

Step 2: Drilling deeper

To see exactly what the current power scheme was telling Windows to do with sleep, I queried the sleep sub-group directly with powercfg /query SCHEME_CURRENT SUB_SLEEP. The output is verbose, so here’s the relevant section I was hunting for:

0x00004650 is 18,000 decimal — 5 hours on AC power. So Windows was faithfully sleeping Flo6 after 5 hours of perceived inactivity, exactly as I’d told it to in recovering from a recent, ill-advised troubleshooting test that reset all my sleep options. Nothing malicious, nothing mysterious. Just a setting I’d explicitly configured sitting where I’d put it, also wrong. Time to kill it.

Pulling the Plug on the Sleep/Wake Timers

I wanted three things gone: the Sleep After timer, Hybrid Sleep, and Wake Timers. Setting any timeout value to 0 disables it. I ran the following commands, covering both AC and DC (battery) power states for completeness, even though Flo6 is a desktop that will never run on battery:

As a belt-and-suspenders measure, I also went into Device Manager, expanded the Universal Serial Bus controllers node, and for each USB Root Hub, opened Properties > Power Management and unchecked Allow the computer to turn off this device to save power. USB Selective Suspend has a well-documented history of nudging systems toward sleep states in ways that aren’t immediately obvious from power plan settings alone. Worth the two minutes it takes to disable it across the board.

The EC Reset: Clearing the Firmware’s Memory

OS-level changes are necessary, but they don’t always flush stale power-state data that’s been cached at the firmware level. The MAG B550 Tomahawk MAX has an Embedded Controller that can hold onto a previous power state even after you’ve changed every relevant Windows setting. The fix is straightforward: shut Flo6 down cleanly, flip the PSU switch off, unplug the AC cord, then hold the case power button for 15 to 30 seconds. This drains the residual charge and forces the EC to reinitialize from scratch. Reconnect everything, power on, and let the board POST fresh. It’s a small step, but it closes a gap that software alone can’t address.

Verdict: Flo6 Should Stay Awake

Hopefully, Flo6 makes it through the night — and several nights after that — without a single uninvited nap. No blinking power button at 6 AM, no dead monitors, no manual wake required. For extra confidence, I’ve got a scheduled Task Scheduler job logging system uptime to a text file every hour overnight. If S3 ever comes back uninvited, I’ll have a timestamp trail to work from. IMO, one week’s worth of clean logs is good enough for me to call this one closed.

If I’ve missed anything, the blinking power button will be back. I hope not, but here in Windows-World anything is possible. If it’s not “case closed” I’ll report back with an addendum here. Fingers crossed that won’t be needed…

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Updates, WED Blog, Windows 11

Resuming Work After Week-long Absence

2 Comments

OK, then. We dropped onto the runway about 20 minutes early last evening. Wife Dina and I returned from a trip to Boston, to watch son Gregory trot across the stage at Emerson College’s Wang Theater to pick up his diploma and graduate. It was quite a trip in many ways. This morning, I’m back at my desk, resuming work after week-long absence. So far, it’s mostly two things: catch-up and clean-up. Let me explain…

What’s Involved: Resuming Work After Week-long Absence

Here’s the drill:
1. run winget upgrade –all — include-unknown to catch all pending updates that winget can handle (7 items)
2. run PatchMyPC Home Updater to catch other stuff that WinGet doesn’t (Revo Uninstaller, in this particular case)
3. run PC Manager deep cleanup (3.2GB found/1.1 GB cleaned) and unCleaner (2.5 GB found, 2.1 GB cleaned)
4. Because today is Patch Tuesday for May 2026, I also applied all pending monthly updates (2 for Defender, 1 for .NET Framework, and the usual monthly MSRT).

All that stuff is pretty easy and straightforward. I did have to reboot, though, because updates via WinGet and PatchMyPC didn’t proceed properly. Something apparently gummed up my runtime. Fixed with the tried-and-true strategy of “Try a reboot, if Windows is balky.” Add a second restart after the Patch Tuesday updates completed, just for grins.

Now, the Real Work Begins…

Next I have to plow through about a thousand email messages that piled up while were off having fun and making family history. That will probably take me the rest of the day. Then I can start updating the rest of the fleet. Wish me luck!

To cap things off, here’s a photo of Gregory proudly presenting his diploma amidst absolute chaos on Boston Common (across the street from Emerson College) after the ceremony ended. Cheers to him, and all of us!

 

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, WED Blog, Windows 11

Troubleshooter Test Wrecks Sleep/Wake Settings

Leave a comment

I have to laugh. I was poking around yesterday trying to see if MS had updated the old Microsoft Support Diagnostic Tool for power options. It hasn’t so I accidentally fired off the old tool and let it run. Upon completion it told me it had “fixed” some things. This morning my experiment bit me on the hindquarters. Instead of starting up after a keyboard press or mouse click, I got …. nothing. I had to press the Power Button to wake up the system, after which all worked as expected. Alas, my troubleshooter test wrecks sleep/wake settings, and I had to go into Power Options to make things right again. Sigh.

Why Say: Troubleshooter Test Wrecks Sleep/Wake Settings?

What the troubleshooter “fixed” flew in the face of how I wanted my system to behave. When I asked Copilot what happened, it explained it as a kind of “own goal” resulting from running the tool. Its explanation is illuminating and a little humiliating for yours truly:

…the troubleshooter on its way out the door silently overrode a deliberate user setting, caused a real problem, and left no log entry explaining what it changed. That’s a tidy illustration of why automated “fixers” that don’t disclose what they’re changing are a liability.

True enough. Fixing the problem took only a few seconds:

1. Select Power Options from Control Panel
2. Click “Change advanced power settings”
3. Navigate to “USB Settings,” then “USB selective suspend setting”
4. Change both “On battery” and “Plugged in” from “Enabled” to “Disabled”

This keeps mouse and keyboard awake so either can wake the PC when it does something. That’s what I want. That’s what I got. And alas, that’s what the troubleshoot undid for me when it ran yesterday. It wanted to save power and that’s what selective suspend does.

Here in Windows-World there’s enough going on that I don’t need to create problems for myself. But that doesn’t stop me from doing it occasionally anyway. But now it’s fixed and I’m aware that I shouldn’t run msdt.exe unless I really need it. My exploration/experiment reminded me that some investigations require cleanup. Sigh again.

Facebooklinkedin
Facebooklinkedin
Uncategorized

Windows Defender May Delete PowerShell Scripts…and More!

Leave a comment

Here’s a fun way to start a Monday: you fire up a PowerShell script you’ve run many times — maybe it provisions a batch of AD accounts, maybe it sweeps stale GPOs — and it simply vanishes. No error dialog. No event log entry. Quarantine warnings not provided, either. The file is just gone, like it offended someone. Which, as it turns out, it did.

The culprit? Recent changes to Microsoft Defender’s Attack Surface Reduction (ASR) rules — specifically, tightened enforcement arrived with Windows 11 23H2. And it has only grown more aggressive in 24H2/25H2. If you manage Windows endpoints for a living, this one deserves some notice.

How and Why Windows Defender May Delete PowerShell Scripts

Microsoft has been steadily ratcheting up ASR rules over the past couple of years. Two rules in particular have become dramatically more assertive: “Block execution of potentially obfuscated scripts” and the newer “Block execution from known script interpreter paths” (rule GUID 9e6c4e5a-1037-4377-92f4-2db0f7e629e7). The latter now matches elevated execution paths that have nothing to do with user shell startup, which means your perfectly legitimate admin scripts can get caught in this net.

Here’s the insidious part. Starting with the 23H2 and 24H2 Defender sensor updates, script-blocking ASR rules are now enforced at the kernel driver layer (via WdFilter.sys, Defender’s minifilter drive) — before process creation even occurs. That means scripts launched via WMI, COM+, or scheduled tasks can be silently killed or quarantined without generating an event log entry. You get no breadcrumbs. The script just doesn’t run, and the script file itself may disappear.

This has caused a wave of false positives hitting legitimate PowerShell scripts, SCOM monitoring agents, Active Directory management tools, and enterprise deployment scripts. If you experienced déjà vu reading that, you’re not wrong. In January 2023, a faulty Defender signature update (builds 1.381.2134.0 through 1.381.2163.0) caused the “Block Win32 API calls from Office macro” ASR rule to go haywire and mass-delete Start menu and taskbar shortcuts across enterprises. Microsoft had to ship a dedicated recovery script (AddShortcuts.ps1) and a taskbar repair utility to clean up the mess. Consider this the sequel — quieter but just as disruptive.

How to Recover Deleted or Quarantined Files

If Defender has eaten your scripts, don’t panic. Work through these steps in order:

  1. Check Defender’s quarantine via the GUI. Open Windows Security → Virus & threat protection → Protection history. Filter by “Quarantined Items.” If your script is there, select it and choose Restore.
  2. Browse the quarantine folder directly. Quarantined files live in C:\ProgramData\Microsoft\Windows Defender\Quarantine. They’re encrypted, but they show that Defender took them.
  3. Use PowerShell for deeper inspection. Run Get-MpThreatDetection and Get-MpThreat to list recent detections and see exactly which ASR rule fired. To restore from the command line, use MpCmdRun.exe -Restore -ListAll followed by MpCmdRun.exe -Restore -Name <ThreatName>.
  4. Add targeted exclusions. Use Add-MpPreference -ExclusionPath “C:\Scripts” or configure per-rule exclusions via Intune or Group Policy to prevent recurrence.
  5. Restore from backup. If the file is gone from quarantine entirely, fall back to File History, system restore points, or your backup solution of choice.
  6. For enterprise environments: check the Microsoft 365 Defender portal’s quarantine and Action Center — detections from managed endpoints often surface there even when local logs stay silent.

That leads to what I’ll call a “Pro tip” for admins to consider. Before enabling any new or aggressive ASR rule, set it to Audit mode first (value 2) rather than Block mode (value 1). Audit mode logs what would be blocked without actually deleting anything. Run it for a week or two, review the results in Event Viewer under Microsoft → Windows → Windows Defender → Operational (Event IDs 1121 and 1122), and then flip to Block. This single practice would have prevented most of the heartburn described above.

You Win Some, You Lose Some…

Let me be clear: Defender’s tighter ASR rules are genuinely good for security. Blocking script execution at the kernel level before a process even spawns is a meaningful defense against fileless malware and living-off-the-land attacks. But Microsoft badly needs to improve logging transparency when scripts get blocked at the kernel driver layer. Silent enforcement with no audit trail isn’t “defense in depth” — it’s “debugging in the dark.”

Until that gets fixed, the playbook is straightforward: keep good backups, audit before you block,  and test ASR changes in a staging ring before pushing to production. Remember: your antimalware solution is only as smart as its latest signature update. As the January 2023 shortcut debacle proved, even Microsoft’s own rules can bite the hand that feeds them. I think these just bit me. Don’t let it happen to you!

But Wait! There’s More…

In my usual ElevenForum readover this weekend, I stumbled on a thread that mentioned scripts — and an encrypted password file — disappearing from the poster’s Windows 11 PC. As I responded to that thread “This is deeply disturbing.” It just doesn’t seem right that Defender can cause scripts (and more) to vanish via rule enforcement. You need to steer around this pothole until it gets filled. Not an unfamiliar strategy, alas, here in Windows-World.

Facebooklinkedin
Facebooklinkedin

Author, Editor, Expert Witness