Category Archives: Recent Activity

Cool Tools, Insider stuff, Recent Activity, Updates, WED Blog, Windows 11

Timing WinGet’s Update Pipeline

April 29, 2026 Ed Tittel Leave a comment

OK then, I just read at WinAero that a new PowerToys v0.99.0 is out. Checking via WinGet upgrade in PowerShell it’s not yet in the pipeline. Nevertheless, the app itself is happy to grab said update from its GitHub repository, as you can see in the lead-in graphic. I’m now conducting an experiment. I’ll be checking hourly as I work at my desk, to see when that new PowerToys version comes into WinGet’s ken. Should be interesting…

What’s Involved in Timing WinGet’s Update Pipeline?

Behind the scenes, lots of things must happen before WinGet catches up, and offers the PowerToys update:
1. MS publishes the new release on GitHub (that’s done)
2. A Pull Request (PR) is sent to winget-pkgs with info about the new version, URLs, hash values, and so forth (usually automated)
3. Pull Request validation runs: automated checks verify installer hashes, check URL resolution, and validate manifest schema
4. Pull request merges into the WinGet source: a maintainer approves the package and merges it into the public database
5. WinGet CDN propagates: the updated database index appears via the winget source in related commands (show, install, uninstall, etc.)

How Long Does It Take?

Because PowerToys comes from Microsoft, its timeline is about as short as such things get. Turnaround normally takes no less than 12 hours, nor more than 48 depending on timing. If a weekend gets in the way the delay can stretch out. Ditto if issues with the manifest show themselves, or if the software being packaged shows a bug. Thus, for example, PowerToys v.0.99 has a Command Palette crash bug, and may be slowed to accommodate suitable hotfix.

We’ll see how this one goes. There’s already a new V0.99.1 version on GitHub (which includes that very hotfix). It’s in the WinGet pipeline now: let’s see how long it takes to get through, shall we?

Note Added 1:05 Later…It’s HERE!

The original post went up at 1:05PM local time. It’s now 2:10PM and a check on the P16 Gen 1 Mobile Workstation produces the following WinGet output: It’s here…

Notice that version 0.99.1 is on offer. That means the PowerToys team got its hotfixes into the package before sending it off to WinGet. Good job, @ClintRutkas and team. I am impressed.

And, now that I’m running it on the suitably-configured X380 Yoga, I see that the PowerToys upgrade also flashes an icon. Impressed again:

Device drivers, Insider stuff, Recent Activity, Troubleshooting, Updates, WED Blog, Windows 11

Firefox Update Fixes Weird Cursor Ripple

April 28, 2026 Ed Tittel Leave a comment

I’ve got to admit, I was misled this morning. After updating my NVIDIA Studio driver for the 3070Ti GPU, I noticed a strange “ripple” behavior around the on-screen cursor in Firefox. This occurred as I was scrolling inside today’s new posts and threads at ElevenForum.com. After reloading the graphics driver (WinKey+Shift+Ctrl+B), no change. So I asked Copilot: “Do I need to reboot?” “Nope,” it responded, “a Firefox update fixes weird cursor ripple” thanks to a fix for a DirectComposition code path error when using NVIDIA cards. It worked!

How Firefox Update Fixes Weird Cursor Ripple

A well-advised principle in troubleshooting relies on answering the question “What changed?” That’s what had me ready to blame the new NVIDIA driver as soon as Firefox got wonky. After taking advice from Copilot, I noticed further that the cursor ripple was indeed limited only to Firefox. It didn’t show up in Chrome or Edge, nor in other Windows apps. If it had been the GPU driver, all would have been affected.

Thus, I’m glad I thought to ask Copilot rather than start rebooting or rolling back the driver. Turns out the cause was obvious, indeed, but related to the specific program I was running as it interacted with the NVIDIA driver. Here in Windows-World, it’s wise not to overlook the obvious. But it’s also wise to cast a wider net, so as not to blame the obvious when something else could be — and in this particular case, was — at fault.

All’s well that ends well. I’m happily using my updated system. And Firefox — where I usually work to create this WordPress content — is working correctly now, too. Bonus: updating the browser is much faster than a driver rollback, and faster than a reboot. Good-oh!

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

Avoiding Excess Laptop Power Drain

April 27, 2026 Ed Tittel 4 Comments

Over the weekend, I transported one of my ThinkPad P16 Mobile workstations to a neighbor’s house. When I unpacked the unit from its knapsack, I noticed that it was pretty warm (and so was the interior of the bag). “What’s up with that?” I wondered. I’d closed the lid, but hadn’t shut the unit down. That was on me, as a little bit of investigating clued me into what’s needed when it comes to avoiding excess laptop power drain. Let me explain…

Power Options Key to Avoiding Excess Laptop Power Drain

Here’s the skinny: by default, my ThinkPad P16 Mobile Workstations go into S0 sleep but maintain network connection. Here’s how the powercfg /a command reports that state:

Basically, the network connection stays up even though the unit itself is mostly idle. Alas, when moving the unit by walking down the street, I’m entering and exiting WiFi domains at a pretty serious clip. Indeed, I’d bet big money that on Arbor Drive, not a single house has less than one active WiFi domain (I’ve got 4, if you count low- and high-bandwidth channels for SSIDs separately). That kept the NIC kinda busy and didn’t really idle the machine at all.

Hence the item shown as the lead-in graphic for this blog post. If you go into Power Options you can change the “Close Lid” setting to hibernate. That means the network connection goes quiet when the lid is closed, and the usual network traffic that might otherwise wake the machine does likewise.

Moving Around Makes Network Connection Iffy

If a laptop is on the move, making or using network connections is a chancy business. My neighbors may have SSIDs galore, but that doesn’t mean they’re sharing passwords with me. And it looks like most of them are smart enough to require WPA3-Personal these days, so guessing isn’t productive, either.

My point is that the network connection doesn’t really do anything except waste battery power when a laptop is on the move. For transport, that means the “Hibernate when lid is closed” setting shown above makes the most sense. That’s why it’s now my preferred move, before I shove the laptop into a knapsack or briefcase from now on.

All I need to do is remember to switch from hibernate to sleep when I get somwhere I plan to be (or work) for a while, and it’s all good. Here in Windows-World, responding to local conditions is a must, especially when it comes to conserving laptop battery life.

Insider stuff, Recent Activity, WED Blog, Windows 11

MS Kicks Off New Insider Channels

April 25, 2026 Ed Tittel Leave a comment

OK, then, today’s the day. Earlier, MS promised to change up its Insider Channel line-up. This morning, MS published an item to the Windows Insiders blog entitled “We’re moving to Experimental and Beta!…” Amusingly enough, this means that the former Canary and Dev channels are collapsing into a single Experimental channel, while Beta stays Beta (at least, for now). So, of course, I had to download and install the latest Beta onto X380 to see what things looked like, as MS kicks off new Insider Channels. Let’s check…

As MS Kicks Off New Insider Channels, I Wait…

As you can see in the lead-in graphic above, the latest Beta version shows up as a “Windows 11 Insider Preview Quality Update” (Build 26220.8283). It took about 5 minutes to download, but install seems poised to take somewhat longer. It’s been 3 minutes and it’s 12% done, so that means ~42 minutes total? Gosh, I hope that’s wrong… And indeed, it got to the “Restart now” button 27 minutes later. By the time I got through everything and back to the desktop total time elapsed was 35 minutes.

To my great disappointment, the view of Insider Channels from the latest Beta release is unchanged. It still shows Canary, Dev, Beta and Release Preview channels. Here’s what I used to (and still) see:

I guess I need to stand up a Canary PC or VM and see if it shows anything different. Here in Windows-World, I’m often reminded of the old French saw “The more things change, the more they stay the same.” I’m sure change is coming, but it hasn’t made it to Beta just yet.

AI, Cool Tools, Insider stuff, Recent Activity, WED Blog, Windows 11

Testing Catches Copilot Errors

April 23, 2026 Ed Tittel Leave a comment

I’m happy to admit that Copilot makes many of my Windows adventures easier to undertake. It certainly helps a great deal with PowerShell scripting stuff. But just this morning I was reminded that it’s always smart to question — and verify — everything Copilot tells me. In testing a USB4 NVMe enclosure just now, I asked it which of the ThinkPad X12 Detachable Gen 1 left-side USB-C ports is faster, remembering that one is 10Gbps (UASP) and the other 40Gbps (TB4). It replies “the lower port,” so I run CrystalDiskMark on both to check its answer. Once again, I confirm that testing catches Copilot errors. Let me explain.

How Testing Catches Copilot Errors

Simply put, checking what Copilot tells you will either confirm that it’s correct, or show that it’s wrong. As you can see in the lead-in graphic, which places the upper USB-C port left, and the lower one at right, large reads are MUCH faster on the left. That means the upper port MUST be the TB4 one because UASP/10Gbps can’t deliver more than 1,000 – 1,200 MB/s for either reading or writing.

When I showed Copilot the CDM results, it responded as follows:

I had it backwards — apologies for the bad call. The source I pulled from apparently described the ports in board-schematic order rather than physical top-to-bottom position as you see them on the tablet. Your bench test is the definitive answer.

And if you’re seeing typical UASP numbers (~1,000 MB/s sequential) from the lower port right now, that confirms it’s the USB 3.2 Gen 2 controller — exactly what you’d expect at 10 Gbps with protocol overhead.

At least, it doesn’t fight with me when I knock it over the head with contrary results. And when it writes scripts, the PowerShell mostly either works or it doesn’t. In the latter case, Copilot may fumble around for a while but it eventually gets things right.

Trust, But Verify

It’s not unreasonable to believe much, or perhaps even most, of what Copilot tells you. But if you don’t check its work, you’re setting yourself up for trouble. It’s good at finding stuff and presenting theories and explanations. It’s by no means infallible, as I have just shown. Take that into account, when you start leaning on it for help…

Insider stuff, Recent Activity, Secure Boot, USB devices, WED Blog, Windows 11

Making Boot/Recovery Media CA-2023 Compliant

April 21, 2026 Ed Tittel Leave a comment

OK, I confess. I’m more than a little OCD in keeping my Windows PCs updated. That applies to Secure Boot as much as anything else. And recently, in bringing my mini-fleet here at Chez Tittel up to snuff, I’ve found myself with old boot UFDs and current PCs. Yesterday, I blogged about that in a post about “Checking Boot/Recovery Media…” Today, in reading the ElevenForum threads I learned that Garlin’s check script now includes boot media status. I also learned how to make my dozen or so bootable UFDs current.

Bootloader Is Key: Making Boot/Recovery Media CA-2023 Compliant

As you can see in the lead-in graphic the file named bootx64.efi is key to compliance. If the file is signed with CA-2023, it’s good; if it’s signed with CA-2011; it’s banned. Fortunately replacing a banned file with the good version is pretty straightforward. But because Windows doesn’t keep the C:\Windows\Boot\efi folder synched to what’s actually in the EFI partition, boot files are best garnered from the latter, not the former.

The steps in the process to provide a CA-2023 signed bootx64.efi therefore go best as follows:
1. Mount the EFI partition as an accessible drive: mountvol /S S:
2. Rename the existing UFD file to .old:
rename g:\efi\boot\bootx64.efi bootx64.old
3. Copy the CA-2023 bootloader into place:
copy S:\efi\boot\bootx64.efi to G:\efi\boot\bootx64.efi
4. Unmount the EFI partition for cleanup:

Note: On Macrium Reflect rescue disks you want to copy the CA-2023 version of bootx64.efi onto bootmgfw.efi instead.

Check Your Work: Run Garlin Script

You can use the latest version (be sure to download before use) of the Garlin Check_UEFI-CA2023.ps1 script to check your work. The correct syntax for this invocation reads (be sure to Unblock in advance):

.\check_UEFI-CA2023.ps1 -bootmedia -verbose

If all goes well the output should (nearly) match what you see in the lead-in graphic. If status shows BANNED, not ALLOWED, then the bootloader is signed with CA-2011, not CA-2023.

It’s pretty easy to fix, though. Hopefully you can do what I just did and bring all of your boot media into compliance. Cheers!

Backup/Restore, Cool Tools, Insider stuff, Recent Activity, Secure Boot, WED Blog, Windows 11

Checking Boot/Recovery Media CA-2023 Status

April 20, 2026 Ed Tittel Leave a comment

Here’s an interesting consequence of the switchover in the Secure Boot chain of trust from CA-2011 to CA-2023. Once that occurs, you can’t boot from install, repair and recovery media that doesn’t support CA-2023. The PC firmware will reject it as “non-compliant.” What that means is with the revocation of CA-2011 upcoming in June, it’s time to start checking boot/recovery media CA-2023 status. When you can, it’s also time to replace older non-compliant media with newer, compliant versions.

I had Copilot write me a PowerShell Script that did 3 key things:
1. It checked to make sure drive G: (default letter for my UFDs) was present and accounted for
2. It showed me the top-level directory so I could see what I was dealing with (handy to distinguish installers, repair tools, etc.)
3. If it found EFI files, it reported Yes/No on their CA-2023 compliance.

After Checking Boot/Recovery Media CA-2023 Status, Then…?

The TL;DR answer to this question is: replace it if needed, keep it otherwise. I also used this opportunity to label my UFDs so I would know what I had in the future. I found all kinds of interesting stuff, including:

An MSI flash drive for my “new” MAG Tomahawk B550 mobo, a UEFI updater for v 2.90 on the ASRock B550 Extreme4+
Multiple Macrium Reflect and Hasleo Backup Suite rescue UFDs
A copy of the Windows DaRT (Diagostics and Recovery Toolset)
Multiple Windows Installer UFDs, mostly via MCT, some from UUPDump

Here’s the interesting thing: NONE of these items is CA-2023 compliant. Copilot says, in fact, that MS has not yet released an installer or repair ISO that includes the CA-2023 boot files in the EFI partition (see lead-in graphic bottom portion). I’d planned to update my dozen or so bootable UFDs today if I could. Looks like I’ll be waiting a while…

Key Takeaway

If you revoke CA-2011 support on any or all of your Windows PCs, you put yourself in the position of having to go into UEFI and turn off Secure Boot sometimes. When might that be? Whenever you want or need to use media to boot that PC for repair, recovery or installation. Good to know! That’s not the kind of thing I’d like sprung on me as a total surprise. Bet you feel the same way, too…

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

Flo6 Gets Unghosted, Loses 183 Drivers

April 17, 2026 Ed Tittel 1 Comment

When I switched my production PC, Flo6, from the ASRock to the MSI motherboard on March 21, I left a large crew of ghosts behind. In this case, a ghost is a no-longer-used driver that remains in the driver store even though it’s out of service and irrelevant to the new installation. Thankfully, Copilot helped me remember and find Uwe Sieber’s outstanding Device Cleanup Tool. It specializes in identifying and removing such ghosts. After using the tool, Flo6 gets unghosted, loses 183 drivers (!), and gets considerably slimmed down.

How Flo6 Gets Unghosted, Loses 183 Drivers

At first I tried a tool named GhostBuster. It showed me I had 399 drivers installed on Flo6, of which up to 193 could be removed. But I couldn’t actually make it remove anything. So I asked Copilot for a different option, among which I recognized Uwe Sieber’s aforementioned tool. It worked, too!

Sieber’s Device Cleanup Tool shows ONLY drivers that may be removed. So I removed all of them. Of the 194 in that collection, 11 came back after a reboot (you can see them in the lead-in screencap). That’s how I got to the 183 number for the count of drivers removed from Flo6 overall. I used PowerShell to calculate before and after sizes for the DriverStore. It started out at 10.63 GB, and dropped to 7.87 GB after cleanup. I like that!

One of the consequences of moving from one mobo to another without a clean install is that this kind of cleanup is needed. One of the advantages of that swap is that I didn’t have to clean install the OS. What can I say? I was in a hurry! Here in Windows-World, these are the trade-offs and the consequences we must learn to accept.

Insider stuff, Networking, Recent Activity, Remote Desktop (RDP), Troubleshooting, WED Blog, Windows 11

Power Outages Mung LAN Addressing

April 16, 2026 Ed Tittel Leave a comment

With clear skies yesterday, our house nevertheless took two power hits yesterday. The first lasted 15 minutes, the second 11 (had to reset certain appliance clocks both times). When I tried to remote into the ThinkStation P3 Ultra this morning, RDP wouldn’t connect. So I tried pinging the host name (Tsp3Ultra2) and got “destination host unreachable.” Pretty conclusive proof that power outages mung LAN addressing, since that very string worked fine yesterday.

If Power Outages Mung LAN Addressing, Then?

For the time being I’ve got Advanced IP Scanner open, and am using the “Tools” option for each network node to call Remote Desktop Connection. That tells me which PC I’m trying to get at, and uses its IP address to make things work. Good enough for now, I guess.

I’ve observed that the name table will gradually correct itself over a 24-hour period. Since our last outage happened just before 5 PM yesterday, that means I can return to using machine names for remote access later this evening. In the meantime, I have a decent workaround.

A quick check tells me that only some PCs were affected by the outage. Not surprisingly, the laptops (kept alive by batteries durng the outage) retain their machine name-to-address relationships. The desktops and mini-PCs (except Flo6, which is on a UPS) have all been renumbered.

Here in Windows-World, it’s always something. Yesterday, it was a quick pair of power glitches. Who knows what’ll hit me today?

Note Added Next Day

As I had suspected (or hoped), the machine names are now all working again. As is typical here at Chez Tittel, a 24-hour period is long enough for DHCP to work itself into usable shape. Now I know that a power glitch (or two) can upset that delicate balance. I’ll probably be reminded again sometime soon, now that thunderstorm season here in Central Texas is getting started. This time, I think the glitch came from construction work at the edge of our neighborhood where power goes from overhead to underground lines.

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

Pondering UEFI Updates

April 15, 2026 Ed Tittel Leave a comment

I’m still getting settled in with my new production desktop environment. ICYDK, it’s built around an MSI MAG Tomahawk B550 mobo, with Ryzen 5800X, NVIDIA 3070Ti GPU, and 64GB DDR4 RAM. This morning, I started digging into the MSI Center app that orchestrates other system utilities, and handles updates for drivers and firmware. In my investigation, I discovered a “new” update for the mobo firmware. In turn, that has me pondering UEFI updates.

Where Does Pondering UEFI Updates Take Me?

I had to figure out that MSI’s once-standalone “Live Update” utility now sits beneath its top-level Support tab (top middle of option bar in the lead-in graphic). Then I had to figure out that UEFI updates appear only when one clicks the “Advanced” button, rather than the more pedestrian “Scan” button (which scans only for driver updates).

As you can see in that graphic, the company shares its guidance in eye-catching red text at the head of the MB BIOS list. That guidance reads: “MSI does not recommend to update BIOS when system has no issue” in somewhat fractured English. However rough the wording might be, the guidance is still pretty good. Let me explain…

If It Ain’t Broke, Don’t Fix It!

The reason why I recently rebuilt my Flo6 desktop stemmed from UEFI problems with the previous ASRock B550 Extreme4 mobo. It kept sticking halfway between Secure Boot old/updated data sets. That resulted in extreme boot requirements, when I might sometimes have to reset CMOS just to get the PC to boot.

Most of the time I had to shut it down, and cut power, then wait a while to bring it back to life. That went on for weeks before I made the switch to the MSI board. Since then, boot and update operations have been blissfully boring. Things just work, and I can use all of the various boot options and related keyboard options to do exactly what I want.

Reading over Copilot’s summary of what UEFI v2.A0 brings me, as compared to the running v2.90, I don’t see anything I need. Nor do I see anything that would improve Flo6’s currently rock-solid and dependable, fully caught-up Secure Boot Status.

Hence my decision: I’m not going to update. Nothing is causing problems. Everything is working dependably and reliably. Secure Boot is golden. This time, I’ll pass… Maybe next time?