Category Archives: WED Blog

AI, Cloud PC, Insider stuff, Recent Activity, Thoughts & concerns, WED Blog

Can Googlebook Occupy a Real Niche in the Computing Landscape?

Leave a comment

Today, September 21, Google fired off its Googlebook platform. Five tier-one OEMs (namely, ASUS, Acer, Dell, HP and Lenovo) are all launching “premium” laptops into this newly defined space. Thus, asking “Can Googlebooks occupy a real niche” is a serious question. On the one hand the computing landscape is already carved into deeply entrenched players. On the other, that carving leaves gaps, and Google is betting it has found one it can occupy, and prosper from.

Who Already Occupies the Landscape?

Each major platform has staked out its territory clearly. Windows dominates business, enterprise, and line-of-business applications. It owns Active Directory, Microsoft 365, and decades of legacy software compatibility. That’s an enormous moat to cross.

Apple Silicon Macs own creative professionals and developers. Xcode, Final Cut Pro, and Logic Pro anchor a loyal, high-spending ecosystem. ChromeOS owns the education budget tier, shipping hundreds of millions of units into classrooms globally. Linux serves the hardcore developer and sysadmin community (and runs on 75+% of global Web and enterprise servers) with precision and flexibility.

Each of these niches is deeply entrenched. Therefore, the question is serious: does Googlebook find a gap, or does it create a new one? Those are very different challenges, and only one of them is easy.

Can Googlebook Occupy a Real Niche Amidst 3B Android Carriers?

This is Google’s best proposition. There are roughly 3 billion active Android devices globally. Most of their users have never found a laptop that felt native to this ecosystem. That’s a genuinely underserved market, and Google knows it.

Googlebook OS merges Android’s app stack with ChromeOS foundations. It adds phone-to-laptop handoff via “Continue On” and “Cast My Apps.” These features mirror Apple Handoff and iPhone Mirroring directly. In short, Google is attacking Apple’s continuity story head-on.

PCMag’s Brian Westover is cautiously optimistic. He called Googlebook “Google’s biggest hardware gamble to date,” but added that he is “betting on Google to reinvent the laptop again” (PCMag). He also noted: “This is probably the worst version of the Googlebook, it only gets better from here” (PCMag). The Android continuity story is real. Even so, it has to work, and not just in demos.

What Do Experts Say? Pros and Cons

Not everyone is convinced. Oflight’s enterprise analysis is frank: “Real-world software compatibility and platform stability will only be provable after the fall 2026 launch. Early adoption carries meaningful validation risk” (Oflight). That’s an outright caution for would-be enterprise buyers.

Consider further that Google’s hardware track record is mixed. The Pixelbook line is dead. Stadia is gone. Pixel Slate never took off. Enterprise buyers have long memories, and Google’s history of platform abandonment is a nagging concern.

On the upside, Oflight also notes that Googlebook inherits Chromebook’s low IT management overhead. It runs on the same Google Admin Console. For schools and SMBs already using Google Workspace, the upgrade path is smooth and familiar (Oflight).

PCWorld’s Ben Patterson frames the AI divide well. He describes it as “NVIDIA RTX Spark, which delivers local AI, versus Google Gemini Spark, which bets on the cloud” (PCWorld). Googlebook bets the cloud. RTX Spark bets local compute. Both bets make sense, but both can’t win (though both can lose).

NVIDA RTX Spark Arrives Oct 7

Mark October 7, 2026 on your calendar. That’s when NVIDIA’s RTX Spark platform hits. RTX Spark is a serious high-end play: up to 128 GB unified memory, 6,144 Blackwell CUDA cores, and 1 petaflop of FP4 AI performance. Pricing runs $2,000 to $3,500 and up.

RTX Spark doesn’t compete with Googlebook directly. However, it does apply real pressure at the top of Googlebook’s $899-to-$1,299 range. A buyer at $1,299 could pause. For $700 more, RTX Spark delivers local AI processing with full Windows app compatibility. That’s a considerable counter-offer.

Gzmato’s TCO analysis finds only 5 to 10 percent of buyers truly need that kind of comuting power (Gzmato). But that buyer group includes developers, researchers, and AI pros. Those are the very users Googlebook is trying to recruit. PCWorld’s Patterson captured it cleanly: “2026 is shaping up to be [NVIDIA] Spark versus [Gemini] Spark, and only time will tell” (PCWorld).

Rating Googlebook’s Odds of Success

Where does this leave Googlebook? The following table scores some key factors. Note further that strength alone does not guarantee a niche. Execution, timing, and staying power all matter. Google must prove it will not abandon this platform the way it abandoned others.

Factor Assessment
Android ecosystem leverage Strong: 3B+ active devices and a vast Play Store
OS credibility at launch Unproven: validation risk is real
AI feature differentiation Solid, but cloud-dependent vs. RTX Spark’s local story
Price positioning Competitive vs. MacBook; exposed vs. RTX Spark
OEM commitment Genuine: 5 tier-1 partners is no soft launch
Google’s staying power The biggest wildcard, given previous history

The niche is real but not yet earned. Android users without a native laptop have nowhere good to go right now. That is a genuine market. And it’s way larger than any hardware niche Google has targeted before. Alas, the computing landscape does not reward goodwill: It rewards execution.

Googlebook ships today, October 4. RTX Spark ships October 7. The next six months of reviews, compatibility reports, and developer adoption will answer the question analysts can’t answer today. Can Googlebook occupy a real niche in the computing landscape, or will it become another chapter in Google’s long list of hardware near-misses? Lots of people will be watching closely, including yours truly. I’ll also be wondering if this could pose a real challenge to Windows-World, given my own focus and interests. We’ll see!

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

Doing the Recovery Drive Rebuild

Leave a comment

If you’ve been following Microsoft’s ongoing Secure Boot shenanigans, you already know the company has been rolling out a series of Secure Boot certificate revocations. This is a deliberate effort to invalidate boot signatures tied to older, potentially vulnerable boot components. The practical consequence is both important and easy to overlook. Boot media you created even last month may now carry BANNED boot files. That’s what had me doing the Recovery Drive rebuild this morning, in fact. Let me explain…but first look at the lead-in graphic from Garlin’s check_bootmedia script to see why I’m doing it.

Why I’m Doing the Recovery Drive Rebuild

The lead-in screencap shows the results of the Garlin script against the Recovery (G:) disk I built after last month’s Patch Tuesday (August 11). As you can see, it’s sadly out of date, BANNED across the board.

Alas, after this month’s Patch Tuesday (September 8) the G: drive features a boot manager or Windows Recovery Environment image signed with certificates that  on Microsoft’s revocation list. On a fully-patched system with current DBX (Forbidden Signatures Database) entries loaded into firmware, that old recovery drive simply will not boot.

It fails Secure Boot validation with a “Secure Boot Violation” error from UEFI, leaving you with nothing but a blinking cursor when you need help most. Fortunately, a community member named Garlin created a PowerShell script called check_bootmedia.ps1 that diagnoses your boot media in seconds and tells you exactly which files are ALLOWED and which are BANNED. I’ve been running it across machines in my lab, and the results on my production desktop (named) Flo6 tell a very clear story.

Before the Rebuild: BANNED Rules!

Working from last month’s Recovery (G:) UFD, I ran Garlin’s check_bootmedia.ps1 against it. The output was unambiguous,but not in a good way. It appears as the lead-in graphic above. Indeed, this script reports that Flo6’s existing recovery drive is running WinRE.wim at build 26100.9168, with a File Version of 28000.352 and a SVN (Security Version Number) of 9.0. Every boot file examined — the boot manager and the WinRE image alike, comes back flagged as BANNED.

That designation is not positive: it means those files carry Secure Boot signatures that Microsoft has since explicitly revoked. Any PC with current DBX entries loaded into its UEFI firmware would refuse to execute those files at boot time. In other words, if Flo6 hit a serious failure tomorrow and I reached for that recovery drive, it simply wouldn’t boot on a fully-patched machine. Not acceptable!

After the Rebuild: ALLOWED Everywhere

I rebuilt Flo6’s recovery drive using the built-in Windows “Create a recovery drive” wizard. This requires no third-party tools, nor manual WIM manipulation, just theRecoveryDrive.exeutility. Once that process finished, I ran check_bootmedia.ps1 again. Take a look:

Everything that was BANNED before, is now ALLOWED. Good!

The transformation was total. The new drive reports WinRE.wim build 26100.9444, File Version 28000.367, and SVN 11.0. Every boot file now shows ALLOWED. The drive is clean, current, and will boot cleanly on any fully-patched Secure Boot system. The SVN jump from 9.0 to 11.0 is especially noteworthy: that’s two full security version increments, reflecting two distinct rounds of certificate revocations that have rolled through since the original image was created. Each SVN increment represents a deliberate decision by Microsoft to bar an entire generation of signed boot binaries from executing. Flo6’s old drive had missed both of them.

Why Did This Take SOOOOOOOOOO Long?

The recovery drive rebuild on Flo6 took well over an hour. If you’ve ever watched the progress bar crawl through a drive creation and wondered whether something was wrong, the answer is almost certainly: no, this is normal. Sigh. Here’s why.

These three main contributors to that long interval are worth understanding:

  1. USB write speed. Flo6’s target drive is a SanDisk SDC2340 UFD. Even though it’s a USB 3.x device, flash writes, especially the large, sequential writes that a WinRE.wim deployment demands  are constrained by the drive’s NAND controller throughput and its write-endurance headroom. Consumer-grade flash storage routinely delivers sustained write speeds at a fraction of the peak specifications. Those rated speeds represent brief burst perfor-mance under ideal conditions, not multi-gigabyte sequential writes the wizard performs.
  2. WinRE.wim compression and decompression. The Windows Recovery Environment image is stored in compressed WIM format. The wizard decompresses it, processes its contents, and then recompresses it to the target drive. That’s a full double-pass operation.Thus, it’s CPU-intensive on the decompression side, and I/O-intensive on both sides. This step alone accounts for the majority of the elapsed time on most systems.
  3. Verification. The wizard doesn’t just write and walk away. It verifies written blocks after the write completes. That adds another full sequential read pass across the whole drive. On a slow UFD, that additional pass adds 15 to 25 minutes by itself.

On a faster USB 3.2 Gen 2 drive with a quality controller (something like a Samsung Flash Drive or a Kingston DataTraveler Max)  the same operation takes 15 to 20 minutes. On Flo6’s SanDisk SDC2340, over an hour is entirely too normal. Slow, but not broken.

Check Your Boot Media!

Here’s my recommendation. After any Windows Update CU, run Garlin’s check_bootmedia.ps1 against every bootable UFD you have.  A recovery drive that passed muster six months ago may now carry BANNED files. That’s because the DBX doesn’t stop growing, and Microsoft shows no sign of slowing its revocation cadence.

The fix, as Flo6 demonstrates, is simply to rebuild. It costs you a USB drive, an hour of clock time, and nothing else. Flo6 is my production desktop, but the same process and the same stakes apply to every Windows 10 and Windows 11 PC you manage.

Maintaining a current, bootable recovery drive is table-stakes Windows hygiene. Also, it’s the kind of thing that feels unnecessary right until it’s the only thing that matters. Now, thanks to Garlin’s script, you have a fast, reliable way to prove yours is good. There’s no excuse not to check. Here in Windows-World, I call those “marching orders.” Start walking…

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

Removing Stubborn Acrobat Pin

Leave a comment

I keep learning more and more about hidden wrinkles in WinGet. I guess that’s because I use it every day, and notice when things get hinky. Today, I noticed my pin on Adobe Acrobat got stuck like Schrodinger’s cat: it was there and not-there at the same time. Ultimately, this had me removing stubborn Acrobat pin, as normal methods couldn’t do their job. Let me explain…

What’s Involved When Removing Stubborn Acrobat Pin?

Take a look at the WinTerm screen capture that starts off this blog post. After running winget upgrade ... I got a message “1 package(s) have pins that prevent upgrade.” Flo6 has 2 pins right now and one of them has no internal version number (GNU Backgammon) so I knew the affected package must be Adobe Acrobat. You can see both packages as output to the winget pin list, in fact.

But as you can see in the next two lines, neither winget list --id... nor winget pin remove recognized Adobe.Acrobat.Reader.64-bit as a valid package name. That’s decidedly odd, because that’s the name that shows up in winget pin listoutput shown earlier.

Turns out that’s a thing. It’s a short form versus long, explicit form discrepancy.

Why the Short Form Fails

When you run winget pin remove without explicit flags, winget uses positional argument matching. It tries to match the string Adobe.Acrobat.Reader.64-bit against its installed packages database first. It does not go straight to the pin store.

If WinGet cannot find a recognized installed package entry for that string, it stops. It bails out before it ever reaches the pin database. The pin record sits untouched.

This mismatch happens for a specific reason. Adobe Acrobat was likely removed through Windows Settings or Add/Remove Programs, not through winget uninstall. Winget never got the chance to clean up its own records. So the installed-package record disappeared, but the pin record survived in winget’s separate pinning.db database file.

That gap between the two databases is the root cause of the error. The fix is to route Winget around that gap entirely.

The Fix: Explicit Flags

The solution is to be explicit with WinGet. To do that, add two flags to the command: –id and –source. Together, they change how winget searches. Use this exact command:

winget pin remove --id Adobe.Acrobat.Reader.64-bit --source winget

Here’s how this works: The --id flag forces WinGet to look up the package by its exact manifest identifier. The --source flag tells WinGet to look specifically in the winget source. Together, they bypass the installed-package correlation step and go straight to the pin store.

The output confirms it works. You see “Found Adobe Acrobat Reader (64-bit) [Adobe.Acrobat.Reader.64-bit]” followed immediately by “Pin removed successfully.” Run winget pin list one more time to confirm the pin is gone. It will be.

This is the cleanest way to use winget pin remove whenever a package no longer has a matching installed record. Keep those flags in your back pocket.

Take the Long Way Home

When winget pin remove fails with “No installed package found,” the short form is matching against the wrong database. Adding
--id and --source redirects it straight to the pin store, where it needs to go. Always uninstall packages through WinGet when you can. That keeps its databases in sync and prevents this mismatch from happening in the first place. A little discipline now saves a lot of troubleshooting later, and now you know exactly what to do when things go sideways despite your best efforts. A not unfamiliar sensation to those who, like me, run in the halls of Windows-World.

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

WinGet Mistakenly Reports Discord as Pinned

Leave a comment

Here’s a scenario many Windows users will recognize. You open a terminal and run winget upgrade to freshen up your apps. Everything looks normal — until you spot Discord sitting there labeled “pinned.” You never pinned it. You have no idea why it shows up that way. Sound familiar? Turns out that WinGet mistakenly reports Discord as Pinned for its own, somewhat murky reasons.

This WinGet Discord pinned situation surprises a lot of people. It looks wrong, or like WinGet won’t update a much-used app. Neither is true.

Take a breath. Discord is fine. WinGet is fine. There’s a perfectly logical explanation — and once you see it, the whole thing makes complete sense. Let me fill  you in…

Why WinGet Mistakenly Reports Discord as Pinned

WinGet uses the “pinned” label for two very different situations, and it doesn’t distinguish between them visually. The first situation is one you control: you run winget pin on a package, and WinGet holds that app at its current version. That’s an intentional, user-driven pin.

The second situation involves the app’s own manifest. Package maintainers can set a field called RequireExplicitUpgrade to true inside their installer’s YAML file. When WinGet sees that flag, it skips the package during bulk upgrade runs. Then, it labels it as “pinned” in the output.

Discord’s manifest resides in the winget-pkgs repository. ICYDK, that’s the Microsoft community Windows Package Manager manifest repository on GitHub. There, its manifest carries RequireExplicitUpgrade: true across many versions, including 1.0.9005, 1.0.9166, and 1.0.9188. WinGet groups both user-set pins and manifest-driven flags under the same display label. That shared label is the root of all this kerfluffle.

Why Discord Sets RequireExplicitUpgrade

Discord ships with its own built-in auto-updater. Most of the time, Discord updates itself quietly in the background without you lifting a finger. It doesn’t need WinGet’s help to stay current. It runs by default each time you open the app (or restart your PC).

Setting RequireExplicitUpgrade: true in the manifest tells WinGet to stand down during bulk winget upgrade runs. This prevents WinGet from downloading and launching a full installer that could interfere with Discord’s own update mechanism. Two updaters competing for the same app can be a recipe for trouble.

This is actually a smart, deliberate design choice. Thus, it’s not a bug, nor an oversight. The Discord team and the winget-pkgs maintainers made a deliberate call to keep things tidy. WinGet and Discord each do their own job, without stepping on each other.

How to Check the Discord Manifest

Want to see Discord’s package details for yourself? Start with this command:

winget show --id Discord.Discord

This output gives you useful metadata — the current version, publisher, installer URL, SHA256 hash, and release date. What it does not show is the RequireExplicitUpgrade field. winget show surfaces display metadata, not every field in its YAML manifest.

The file Discord.Discord.installer.yaml does not exist on your local PC. It lives only on GitHub. To find it, go directly to this URL in your browser. (Swap in whatever the current version number is for 1.0.9258 if needed.) Once there, look for RequireExplicitUpgrade: true in the YAML. That single line is what tells WinGet to treat Discord as a skip-by-default package during bulk upgrades. You can see it highlighted in the lead-in graphic at line 16 of that YAML file, in fact.

Upgrading Discord Through WinGet Anyway

Maybe you want WinGet to handle the Discord update on your terms. No problem. You can override the RequireExplicitUpgrade flag with a single targeted command:

winget upgrade --id Discord.Discord --force

This tells WinGet to update Discord explicitly, bypassing the manifest flag just for this one run. It’s a clean, safe way to push a WinGet-managed update when you want one.

That said, most of the time you won’t need to bother. Discord’s own updater does its job reliably and quietly. The WinGet Discord pinned label looks alarming, but your Discord client is almost certainly already up to date. Check the app’s version in its settings if you want confirmation.

WinGet Category Conflation Explains All

The “pinned” label WinGet shows for Discord is not a real user-set pin. Again, you did nothing wrong, and nothing is broken. It reflects the RequireExplicitUpgrade: true field baked into Discord’s own manifest That tells WinGet to step aside and let Discord’s built-in updater do its thing. Once you understand the distinction, WinGet’s behavior makes perfect sense. This behavior is simply misreported as “pinned” not “RequireExplicitUpgrade.”

Now that you know what’s going on, you can look at that “pinned” label and nod knowingly instead of scratching your head. That’s what understanding tools is all about. That makes you a sharper and better-informed inhabitant, here in Windows-World.

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

OOB KB5129195 Impacts LAN

Leave a comment

Imagine my surprise this morning when I sat down at Flo6, my trusty B550-based homebrew desktop. Instead of taking me to the desktop, I faced a login prompt. “Hmmm,” I thought to myself, “Looks like an update came through.” Sure enough, when I checked I found MS pushed one yesterday to fix issues following last week’s Patch Tuesday. And indeed, OOB KB5129195 impacts LAN access via RDP to at least one of my machines. Let me explain, and provide more details.

How OOB KB5129195 Impacts LAN

When I tried to RDP into the ThinkStation P3 Ultra Gen 2 (aka TSP3Ultra2), the machine name wouldn’t resolve. Using Advanced IP Scanner, however, I was able to get in through its IP address. I quickly determined that the update had toggled the Network type from “Private” to “Public” (in that latter situation, Machine Names don’t work). Resetting the toggle to “Private” put things back in the pink.

TLDR: OOB KB5129195 in Brief Bullets

  • OOB KB5129195 shipped September 14, 2026, outside the normal Patch Tuesday schedule, to hit my PCs last night.
  • It fixes RDP instability, Hyper-V folder sharing, USB audio failures, and a partially unpatched privilege escalation flaw.
  • Five of my eight home PCs received and installed the update.
  • Two machines required manual restarts; only one flipped its LAN profile from Private to Public afterward.
  • Fixing the profile flip takes about two minutes in Settings;be sure to check for it.

The OOB Release Trigger

September’s Patch Tuesday update, KB5122880, introduced several nasty regressions. Remote Desktop Services became unstable, causing RDP failures and server hangs. That alone would justify an emergency fix. Hyper-V Plan9 folder sharing also broke for Linux VMs, a real headache for developers. USB Audio Class 1.0 multichannel playback went sideways on some affected systems too.

On top of all that, a privilege escalation flaw, CVE-2026-62721, was only partially patched in the original release. That flaw lives in the Windows User-Mode Power Service. KB5129195 addresses all  these regressions. After installation, Windows 11 24H2 machines move to build 26100.9457. Windows 11 25H2 machines land on build 26200.9457. Eventually.

The Upgrade Hit 5 of 8 PCs Here at Chez Tittel

I run eight PCs in my home lab here in Round Rock. Five of them flagged KB5129195 as applicable and pulled it down. The other three were unaffected, likely due to differing configurations. The five affected machines automatically downloaded the update. Microsoft’s documentation puts installation time at roughly ten minutes. That tracked closely with what I observed across my fleet.

Auto-restart systems finished cleanly: Three of my five affected PCs are set to auto-download, install, and reboot via Windows Update. All three finished the update with zero drama. No errors, no failed installs, no post-reboot surprises. That is the experience Windows Update is supposed to deliver. I wish every update went so smoothly.

Manual Restarts on P16 and TSP3Ultra2: Two machines required manual restarts: my Lenovo ThinkPad P16, which I call the P16, and the TSP3Ultra2. Both showed KB5129195 as pending restart in Windows Update. I manually triggered the restart on each machine and waited. Both came back up fine after the reboot.

Then I noticed something off. On the TSP3Ultra2, the LAN network profile had flipped from Private to Public. This is a known side effect that occasionally follows cumulative updates. It matters more than you might think. I fixed it by going to Settings, then Network and Internet, then Ethernet properties, and switching the profile back from Public to Private.

Why the LAN Profile Flip Matters

Windows treats Public and Private network profiles differently. The Public profile blocks most incoming connections and disables network discovery. That can silently break file sharing, remote access, and other local network features. The Private profile enables discovery and sharing, which is what you want on a trusted home or office network. After any significant Windows update, I now make a habit of checking the network profile. Go to Settings, then Network and Internet, then click on Properties. Confirm the profile reads Private. If it says Public, flip it. It takes about thirty seconds.

KB5129195 is a necessary update, and I am glad Microsoft moved quickly to ship it. Most machines handled the install without any fuss. The LAN profile flip on the TSP3Ultra2 was an annoyance, but nothing a quick settings change couldn’t handle. If you apply OOB KB5129195, do yourself a favor: check your network profile afterward. A few seconds of verification can save head-scratching later. That’s a good thing, here in Windows-World where reasons for such behavior pop up all the time!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

Strange DirectX Pin on Flo6

Leave a comment

I was doing a routine check of my WinGet pin list on Flo6 just now (ICYMI, Flo6 is my production desktop). After running winget pin list I spotted three pinned packages. Two of them I recognized immediately. Adobe Acrobat Reader (64-bit) and GNU Backgammon  I pinned myself, on purpose. But the third one stopped me cold. It showed Microsoft.DirectX at version 9.29.1974.0. I had never pinned that. Why did I see this strange DirectX pin?

How I Got a Strange DirectX Pin on Flo6…

First, let me share some background. Modern DirectX, meaning DirectX 11 and DirectX 12, is baked directly into Windows. Windows Update manages it entirely. Winget does not install, update, or remove it. How, then, did it make its appearance?

The Microsoft.DirectX package from the WinGet community catalog is something else entirely. It refers to the DirectX End-User Runtime redistributable, specifically its June 2010 release. That’s the last one MS ever shipped.

Indeed, Version 9.29.1974.0 is the final, frozen-forever build. It’s unchanged since 2010. Back in the day, games and apps from that era bundled this runtime to pull in legacy components. Think D3DX9, XAudio2, and XInput. On most modern Windows systems, this redistributable is obsolete and irrelevant.

The Source of This Strange Pin May Be…

Here’s where things get weird. The Microsoft.DirectX manifest in the WinGet community catalog had a long-running typo. For a while, it listed the package version as 9.29.1974.1 instead of the correct 9.29.1974.0. A community contributor eventually caught the error and submitted a pull request to fix it.

Once that fix merged into the catalog, WinGet suddenly saw a mismatch on affected machines. The catalog now declared 9.29.1974.0 as current. The installed runtime also reported 9.29.1974.0. So far so good. But the metadata around the install technology did not reconcile cleanly. Windows owns and controls the DirectX runtime. WinGet does not.

Winget could neither upgrade the package nor cleanly resolve the discrepancy. So it did the next best thing. It quietly added a Pinning-type pin to suppress its spurious upgrade prompt. That kept its noise out of winget upgrade --all output. In short, winget added the pin to stop nagging itself about a package it cannot actually manage. I have to laugh about that, give me a moment…

Removing the DirectX Winget Pin Is Safe

The good news here is straightforward. This pin is purely administrative. WinGet created it as a workaround for its own catalog inconsistency. It was never protecting anything vital.

Removing the pin leaves the DirectX runtime alone. The actual runtime stays right where it is. Windows Update continues to manage it, same as always. Better yet, the phantom upgrade version, 9.29.1974.1, is already gone from the WinGet catalog. Removing the pin won’t spur any bogus upgrade attempts. Nothing bad is waiting to happen.

The command to remove it is simple:

winget pin remove --id Microsoft.DirectX --source winget

As you can see in the screenshot above, the operation returns “Pin removed successfully” in under two seconds. A quick follow-up winget pin list confirms the DirectX entry is gone. No drama, no side effects.

Separating Signal from Noise

This episode is a good illustration that WinGet isn’t infallible. Sometimes its catalog or tooling leaves artifacts behind that look alarming but turn out to be harmless. The DirectX pin on Flo6 was exactly that: a breadcrumb left by WinGet’s own error-handling logic, not by anything I did. A single one-liner clears it up in seconds. Now, winget pin list shows only packages I actually chose to pin. That is exactly how it should be, and I am glad to have one less mystery on my machine. That counts as a win, here in Windows-World. Cheers!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

In-app Update Beats Remove/Replace

Leave a comment

Running WinGet just now on my Flo6 desktop, I got reminded that installer changes sometimes stymie its update facilities. If you look at the lead-in graphic, you’ll see that one upgrade gets blocked because of “different install technology.” Winget goes onto recommend “Uninstall each package, then install the newer version.” Not so fast: IMO, an in-app update beats remove/replace when that’s an option. I’ll explain, and use the Edge browser as an illustration.

You can jump to Edge, click the ellipsis, and get to Help and feedback in 3 clicks. Uninstall/reinstall takes 20+ keystrokes, and might fail.

Why Say: In-app Update Beats Remove/Replace?

My explanation boils down to: less time and effort, fewer keystrokes involved. Jumping to Edge, clicking the ellipsis for Settings, then visiting Help and Feedback to prompt the update process takes 3 mouse clicks (add one more click to restart, and the update is done). Uninstalling, then re-installing edge takes at least 20 keystrokes (“winget uninstall edge”). Worse, it then falls victim to exit code 93. TLDR version: Edge is considered a Windows built-in feature, so it blocks its own uninstall by default.

Sure, you can work around this. And it works for other browsers as directed for Chrome, Firefox, and so forth. But my preferred approach for browsers in particular is: try the built-in update mechanism first, if WinGet steers around an update. It usually does so for a good reason, as is the case here with Edge.

Here in Windows-World, it pays to recognize such cul-de-sacs when they pop up. It saves you the time involved in driving to the end, turning around, and doing something else. Not an unfamiliar experience for Windows warriors, but one best avoided when possible!

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

Post Patch Tuesday Secure Boot Cleanup

Leave a comment

September’s Patch Tuesday landed on 9/8. And it brought more than the usual security fixes. KB5124008 and KB5124012 quietly expanded device targeting for Microsoft’s ongoing Secure Boot trust chain. If you haven’t verified your machines yet, now is the time. Secure Boot cleanup is not optional — it is essential maintenance for every managed Windows environment. Indeed, I’d argue that a routine post Patch Tuesday Secure Boot checkup is part of a “new normal” for Windows, with a cleanup to follow if needed.

Why Do a Post Patch Tuesday Secure Boot Check?

Here is the backstory. The old Microsoft UEFI CA certificates that were issued back in 2011, expired in June 2026. Microsoft has been rolling out replacement 2023 certificates through Windows Update for months. September’s updates expanded that rollout further.

KB5124008 and KB5124012 added more “high confidence” device targeting data. That means more PCs are now eligible to receive the new certs automatically. However, some devices still fall through the cracks.

Don’t panic. Devices that haven’t received the new certificates will still boot. Standard Windows updates will still install. But the clock is ticking. A second major deadline arrives in October 2026. You don’t want to be scrambling then.

Why It Matters

Devices that miss the Secure Boot cleanup lose future boot-level security protections. Over time, they become progressively more exposed to boot-level threats. These are the kind that load before Windows even starts. Also, BitLocker and device encryption may break on out-of-synch systems. That means recovery key prompts, startup hangs, and frustrated users calling the help desk.

Running the Garlin Remediation

Garlin is a long-time, high-status (and value) member of the online community for ElevenForum.com. He’s been stewarding a long-running thread (now at 188 pages) entitled “garlin’s PowerShell scripts for updating Secure Boot CA 2023” since January 2025. He’s got scripts to handle certificate synch-ups, with all the related DB and DBX fixes to boot (pun intended). Just remember to visit his GitHub site regularly to download the latest ZIP file with scripts to match (his latest update on 9/8 handles the newest Patch Tuesday updates).

As you can see in the lead-in screenshot, after the update Windows incremented SkuSiPolicy.p7b from version 3.0.0.17 to 3.0.0.18. It also updates the Secure Version Variable (SVN) stored in NVM in firmware as part of Secure Boot’s DBX values. After the OS update, certain operations are need to catch the UEFI up with the OS.

Actual Remediation : SkuSiPolicy.p7b

The SkuSiPolicy.p7b value governs which Windows editions (aka “SKUs” such as Home, Pro, Education, etc.) that Secure Boot regards as trusted and bootable. If the policy in the OS and the policy in a boot structure (whether in EFI, on disk, or on bootable media) don’t match, you get “Secure Boot Violation” when you try to boot and nothing more. Not good!

No worries. Garlin’s got a fix for that. If you run his latest Update UEFI script with the right argument it will fix it for you (reboot required). Here’s the syntax:

Update_UEFI-CA2023.ps1 -SkuSiPolicy

If you’re running this in an admin PowerShell session, prepend “.\” (period-backslash) to get it to run. Tip: if you unblock the ZIP file after downloading it from GitHub, the archive’s content will also be unblocked. Otherwise, you’ll end up unblocking them piecemeal. I speak from direct experience on this…

Actual Remediation: SVN

The Secure Version Number (acronym: SVN) is a monotonically increasing integer value also stored in the UEFI DBX value. It provides anti-rollback enforcement. When a bootloader or boot manager tries to loan, UEFI checks its built-in SVN against the minimum SVN stored in firmware. If the boot agent SVN is lower than what’s in UEFI, UEFI won’t load it. Here again, it’s necessary for what’s in the OS and what in the bootloader to agree. After an update (like Patch Tuesday) remediation may be needed.

Here’s what that looks like in PowerShell (admin):

manage-bde -Protectors -Disable C: -RebootCount 1


reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x200 /f


powershell Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

The first line turns off BitLocker for the next boot to avoid key lookup and entry. It’s only needed for PCs whose C: drive is BitLocker protected. The next line adds a registry key to define and schedule a Secure Boot update task to update the SVN. The third line calls powershell to run that scheduled task immediately. All this stuff shows up in the output of the Garlin check script if you run it properly, so you can copy it from there, right inside PowerShell.

Here’s that syntax:
check_uEFI-CA2023.ps1 -verbose -audit

Don’t forget to prepend the “.\” (period backslash) to run it in PS.

Also: Boot Media Needs Catchup, Too

Here is a step that many admins overlook. Your Windows installation USB drives and WinPE recovery media also need attention. For sure, any media created before January 2025 won’t include the new 2023 Secure Boot certificates. I’ve gotten in the habit of rebuilding boot media each time that SkuSiPolicy.p7b or the SVN increments myself.

What happens if you don’t build new boot media? They may fail to launch on a fully updated machine. Rebuild everything from the latest Windows ADK, MCT (Media Creation Tool), or a current Windows ISO. Then test the rebuilt media on at least one device before you rely on it to get something done.

Run through this quick checklist before you close this task out:

  • ☑ Rebuild WinPE USB from the latest ADK
  • ☑ Rebuild Windows installation USB from a current ISO
  • ☑ Update MDT and WDS boot images if applicable
  • ☑ Test rebuilt media on a pilot device before wide deployment
  • ☑ Document any devices that cannot update (unsupported hardware) as formal exceptions

This is a new and interesting wrinkle on dealing with Windows Updates, especially around the Patch Tuesday milestone. Here in Windows-World such wrinkles accumulate. Don’t let them put your PCs and boot media in peril. Do the necessary, please!

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

Fixing False Vantage Update

Leave a comment

If you’ve ever dealt with a Lenovo Vantage false update, you know how maddening it gets. That goes double, when every install attempt fails silently and the same ghost package reappears on every subsequent scan. Sigh.

But that’s precisely what happened to me on a Lenovo ThinkStation P3 Ultra Gen 2 (Arrow Lake-S desktop). There, Lenovo Vantage’s System Update panel stubbornly flagged Intel Dynamic Tuning Technology (DTT) Driver version 9.1.10001.173 as a required update, even after reporting a successful install on the previous try. Sigh again.

Why I’m Fixing False Vantage Update

Here’s the wrinkle: DTT is a laptop-exclusive power-management feature. It’s tightly coupled to Intel’s thermal sensor bus. Specifically, it applies to SWC\VID8086_DTT_* ACPI devices. Alas desktop platforms don’t sport them. My ThinkStation doesn’t have one. It never will. Yet Vantage keeps insisting otherwise.

Furthermore, every install attempt failed without so much as an error dialog. Vantage just re-offered the driver on the very next scan, politely pretending nothing had gone wrong. Time to dig in, and get this thing outtah heah!

Ruling Out the Obvious

First, I tried some obvious remedies. Logging into Vantage directly as Administrator changed nothing. There’s no ellipsis menu, no right-click context option. That means no “suppress this update” checkbox anywhere in the System Update panel. Lenovo simply hasn’t built that in.

Next, I turned to the standalone Lenovo System Update app. After installing the optional Lenovo SoftwareComponent Driver 26.9.0.20 from Windows Update, System Update scanned the machine and correctly reported “No packages applicable.” Clean bill of health. Meanwhile, Vantage still flagged the DTT driver for update. Sigh one more time.

However, that discrepancy was actually useful. It proved the issue lived entirely inside Vantage itself. It’s an artifact of its System Update addin, not  Lenovo’s underlying package catalog. The two tools evaluate the same catalog through completely different pipelines. Importantly, only one of them is wrong.

Tracing That False Positive…

With the obvious paths ruled out, I dug into Vantage’s session data folder:
C:\ProgramData\Lenovo\Vantage\AddinData\
LenovoSystemUpdateAddin\session\.

Inside, I found two SQLite databases: update_history.db (Vantage’s live working store, rewritten on every scan) and editable_update_history.db (which appears designed to accept external edits). I tried setting the DTT entry status to NotApplicable in the editable_update_history.db. Alas, nothing changed on screen. Vantage reads update_history.db for all rendering decisions and overwrites it with Applicable again after each rescan. The “editable” database, it turns out, is a red herring.

I also found available_updates.json.It’s a 5 KB file that’s rewritten upon each update scan. It gave me a fully parsed package definition, including a Dependencies block that pointed me toward the real culprit.

A (Bogus) WildCard in the XML

Vantage caches each package’s raw XML in its own repository subfolder. For this machine, the DTT package XML lives at:

session\Repository\m1dpf015d_p3ultrag2_25h2\m1dpf015d_p3ultrag2_25h2_2_.xml

Inside that XML, the Dependencies/_Bios/Level section contained two machine-type entries: “*” and “S0NKT*”. The S0NKT* pattern correctly targets specific Lenovo laptop lines that carry DTT-capable thermal silicon. That entry belongs there. The “*” wildcard, however, matches every machine type on the planet — including the ThinkStation’s 30J5 machine type. That entry almost certainly doesn’t belong there, and it looks like a straightforward Lenovo catalog error.

Consequently, without the wildcard, Vantage evaluates the ThinkStation’s machine type against S0NKT*, finds no match, and writes NotApplicable to update_history.db automatically on every future scan. No database patching, no registry hacks — just the correct answer from a corrected applicability list.

PowerShell to the Rescue!

I wrapped the repair into a short PowerShell script called fix_dt.ps1. The logic is straightforward: clear the file’s read-only attribute, load the XML into an XmlDocument object, locate the offending node using an XPath query, remove it, save the file, restore read-only protection, then restart the LenovoVantageService so Vantage picks up the change cleanly.

The lines that do the heavy lifting are (edit to remove line breaks):

$node = $v.SelectSingleNode("//_Bios/Level[. = '*']")
if ($node)
{ $node.ParentNode.RemoveChild($node) | Out-Null }

Setting the file back to read-only afterward is an important step. It prevents Vantage from silently re-downloading a fresh copy of the XML on its next catalog sync and re-introducing the wildcard. Sadly, that would undo the fix entirely.

To run the script, open an elevated PowerShell prompt and execute:

powershell -ExecutionPolicy Bypass -File
"C:\Temp\fix_dt.ps1"

Note: Run this from an elevated (Run as Administrator) PowerShell session. The script must stop and restart the LenovoVantageService, which requires administrator rights. Edit so it runs on one line.

Lessons Learned

This exercise surfaced a few things worth minfing for anyone who’s doing deep Vantage troubleshooting:

  • Vantage and the standalone System Update utility maintain completely separate state databases and catalog evaluation pipelines. Agreement between them is not guaranteed. Disagreement is a useful diagnostic clue, not a dead end.
  • The “editable” SQLite database is a red herring for display suppression. Vantage ignores it when rendering the System Update panel. Don’t waste time on this.
  • A single bogus wildcard in a machine-type applicability list causes a laptop-only driver to haunt a desktop indefinitely. The fix is in the XML, not in the database.
  • When the official UI offers no suppress or hide option for a persistently wrong update, the XML repository is the right lever to pull. Appearances aside, it’s not the SQLite layer above it at fault.

Ultimately, this is a reminder that catalog quality control matters. One stray “*” in a dependency block can send thousands of ThinkStation owners chasing a ghost driver that will never install. If you’ve hit the same Lenovo Vantage false update on a different ThinkStation model, or if you’ve spotted a similar wildcard problem in another Vantage package XML, please drop a comment here. I’d love to know how broadly this catalog bug extends beyond the P3 Ultra Gen 2.

Here in Windows-World, updates sometimes get weird. This time, for once in a blue moon, it’s not WU that’s the culprit. It’s Lenovo. That makes me oddly glad. Go figure!

Facebooklinkedin
Facebooklinkedin
Cool Tools, PowerShell, Recent Activity, WED Blog, Windows 11

WinGet.Config Drives Developer Config

Leave a comment

As I was reading a Windows Latest article about a “…special Windows 11 for power users…” this morning, I found myself wondering. “Could this be a big, fancy WinGet config file at work?” Indeed, reading further into the story absolutely confirmed my hunch. The file in question, in fact, is named winget.config, in keeping with current naming conventions around desired configuration states. Thus, it’s simple truth that Winget.Config drives “Developer Config” as described in the story (and at MS Learn as well).

WinGet.Config Drives Developer Config from End to End

The MS Learn article‘s intro paragraph is worth quoting in full to put this capability into clear context:

Windows Developer Configurations are a curated, open-source collection of configuration files that take a fresh Windows machine to a ready-to-code state with a single command. Each config is a declarative file that is safe to re-run. It describes the packages, OS settings, and post-install steps for a specific scenario (a full developer workstation, a comfortable WSL shell, or a single language toolchain), so you can rebuild your environment on any machine without clicking through installers or maintaining custom scripts.

Windows Developer Config is built from the ground up on winget configure and a single .winget desired state configuration (DSC) file named dev-config.winget. It is not a new Windows SKU, a custom ISO, nor a registry script. The whole thing is one winget configure call pointing at that file.

The commands necessary to instill this configuration are (mostly) shown in the lead-in graphic. I repeat them here for completeness’ sake (and for easy cut’n’paste, by copying non-comment lines completely):


# Enable WinGet Configuration first
winget configure --enable

# Clone the repo
git clone https://github.com/microsoft/WindowsDeveloperConfig.git
cd WindowsDeveloperConfig

# Apply the config
winget configure -f .\windows-dev-config\dev-config.winget –accept-configuration-agreements –disable-interactivity

More About WinGet.Config

That .winget file is a YAML-based DSC manifest that handles everything in one shot: installing PowerShell 7, Git, GitHub CLI, VS Code, .NET SDK, Python, Node.js, PowerToys, setting up WSL with Ubuntu, tweaking Windows Terminal defaults, enabling Developer Mode and long-path support, and applying a long list of Explorer/Start/Search/Widgets settings to declutter the UI.

Indeed, Project Zenith hardware ships with those same changes baked-in by the OEM. But the underlying mechanism Microsoft used to define and apply that configuration is exactly the same winget configure + .winget file approach. In fact, the .winget config file format is doing real work here. That is, it’s not just installing apps; it’s functioning as full-blown Windows DSC, a notable expansion beyond what most people think winget does.

Here in Windows-World, it’s great to see real innovation put to useful work. Demitrius Nelon, the head of the WinGet team, has told me several times over the past few months that .winget configuration files represent a way to customize Windows seriously in one go. Now, I think I understand what he was getting at. Great work, guys!

Facebooklinkedin
Facebooklinkedin