Category Archives: WED Blog

Insider stuff, Recent Activity, Thoughts & concerns, WED Blog, Windows 11

Secure Boot Oddities Accumulate

January 30, 2026 Ed Tittel Leave a comment

Although I’m resigned to living without secure boot on the B550-based desktops here at Chez Tittel, that doesn’t stop me from trying other fixes from time to time. Indeed, I discovered a great thread about secure boot keys at ElevenForum, and learned more about what’s going on under the hood. Along the way, I gave myself a terrific scare as I saw more secure boot oddities accumulate. Here’s what happened…

Registry Key Change Helps Secure Boot Oddities Accumulate

One must provide Windows with a a couple of instrux to ask the OS to update secure boot key certificates, to wit:

Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot” -Name “AvailableUpdates” -Value 0x40

Start-ScheduledTask -TaskName “\Microsoft\Windows\PI\Secure-Boot-Update”

One is then instructed to reboot Windows twice to get those instructions to work as they’re intended to. What it doesn’t say is that strange things might happen before the first reboot occurs.

Black Screen, No UEFI — No Nothin!

I about had heart failure when I rebooted my PC this morning and the Flo6 came up black with no normal boot sequence. No Asrock logo, no instructions to hit Del or F1 to load EFI, no F11 for boot menu. There’s not much one can do to fix a Windows PC that won’t do anything, short of taking it into a shop.

So I turned off the power supply, then hit the power button for 10 seconds to make sure all the capacitors got discharged. Then I took a break and walked away from the machine for 10 minutes. Then I powered on again. Phew! This time, the Asrock logo appeared, and it booted into Windows 11. To my great relief, the second reboot was no big deal, and I was glad.

Here in Windows-World, you can make big changes without incurring at least some risk. This morning, I wondered if I’d bitten off more than I could chew. I even wondered if I’d bricked the Flo6. Thank goodness, I had not. I’ll take that as a win, even though you can see in the lead-in graphic that 2023 keys remain absent on this PC. Go figure!

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

Returning Spurious Reclaimables Removed

January 29, 2026 Ed Tittel Leave a comment

For the past couple of years, I’ve watched various Windows updates and upgrades introduce and re-introduce what I call “spurious reclaimables.” These are windows packages that show up in the component store that (a) don’t need to be there and (b) refuse removal using dism /online …. /StartComponentCleanup. Just yesterday, Copilot helped me figure out how to yet again make them go away. That’s because I saw a familiar set of returning spurious reclaimables removed on the ARM-based ThinkPad T14s Gen 6.

Getting Returning Spurious Reclaimables Removed

There are two such packages in this mix, each with characteristic, fairly unique substrings — namely “RollupFix” and “FodMetadata.” So that’s what I used to find that stuff in the package store:

dism /online /get-packages /format:table | findstr /i “RollupFix”
dism /online /get-packages /format:table | findstr /i “FodMetadata”

Those commands let me find the precise package names that I would go on to use to remove the spurious ones from the package store. Indeed, Windows 11 24/25H2 continues to surprise even seasoned Windows hands with its servicing behavior—especially on ARM64 systems. Here’s a short but hopefully illuminating dive into how ARM64 handles staged vs. installed packages, and why some packages appear removable even when they aren’t.

Working Through the Process: RollupFix

Here’s my starting point — namely, two RollupFix Packages. One is staged and the other installed. On the T14s laptopn DISM /get-packages listed two versions of the RollupFix package:
– A staged version: 26100.1743.1.3
– An installed version: 26100.7674.1.3
Both appeared to be reclaimable. So I started with the older, staged version, and provided a DISM command to remove it:

dism /online /remove-package /packagename:Package_for_
RollupFix~31bf3856ad364e35~arm64~~26100.1743.1.3

(Note I stuck a CRLF into that line to make it lay out better. To cut’n’paste that item, stick into Notepad and turn it into a one-liner.)

DISM happily complied with that command and responded with: “Processing 1 of 1 – Removing package … The operation completed successfully.” So far, so good. But the next step revealed something interesting, as I attempted to remove the newer, installed RollupFix package (same syntax as above, new package name).

This time, DISM responded with an error message, to wit: “Error: 0x800f0825 — the package is permanent or not applicable.” That means once the staged version got removed, the installed version became the baseline and couldn’t be removed. This mirrors AMD64 behavior, though ARM64 expresses things more forcefully. Removing the superseded version effectively locks in the newer one, making it “permanent” and non-removable.

Further into the Process: FodMetadata

The T14s also offered up two versions of the FOD metadata servicing package, one staged, the other installed:
– Staged: 10.0.26100.1743
– Installed: 10.0.26100.7674
Again I started with the staged version. This time DISM responded with Error 0x800F0805 “the staged package is already gone.” ARM64 appears to auto-clean the staged FOD metadata package when the staged RollupFix package is removed.

That’s a subtle but important difference from AMD64, where the FOD metadata package is removed automatically only when the installed RollupFix is removed. Thus, removing the installed version worked as it should, and that operation completed successfully.

Final Check: Clean Component Store

When I ran a followup /analyzecomponent store check in DISM after those various attempted and successful removals, I got clean store billing, as reported in these output lines for that command:

Number of Reclaimable Packages: 0
Component Store Cleanup Recommended: No

That means the component store is clean, and there are no more reclaimable packages, spurious or otherwise, to get rid of. That’s what I like to see! You can see further confirmation in the lead-in graphic which shows only “Installed” versions for the two packages that previouly included older, obsolete staged versions prior to the cleanup moves I described above.

Insider stuff, Recent Activity, Thoughts & concerns, WED Blog

Understanding El-Cheapo Windows Licenses

January 28, 2026 Ed Tittel Leave a comment

Every so often, a new round of bargain‑basement Windows license deals makes the rounds. You’ve seen them: Windows 11 Pro for ten bucks, Windows 10 Pro for even less. They pop up on StackSocial, StackCommerce, and a handful of deal‑driven tech sites. And like clockwork, the obvious question arises: Is this for real, or too good to be true? Neither and both: indeed, understanding el-cheapo Windows licenses hits both sides of this common wisdom.

More On Understanding El-Cheapo Windows Licenses

As someone who’s been around the Microsoft ecosystem for a long time — and who has more legit keys than I’ll ever need thanks to MVP status — I find the whole phenom fascinating. Not because I need another license, but because these offers sit right at the intersection of Microsoft’s licensing rules, its activation infrastructure, and the gray‑market economy surrounding both.

Here’s the key (pun intended): activation and licensing are not the same. Activation is a technical handshake with Microsoft’s servers. Licensing is a legal framework that governs how a key is properly obtained and used. Those two systems overlap, but they don’t enforce each other as tightly as many expect and assume.

Most $10 keys fall into one of three buckets. The first is unused OEM keys pulled from bulk hardware purchases. Perfectly valid keys, never activated on their original devices, but not transferable under Microsoft’s rules. The second bucket is decommissioned or oversold MAKs (multiple activation keys) — volume license keys with high activation counts that get resold repeately. They activate until the pool runs dry. The third bucket is region‑restricted retail keys, bought cheaply in low‑cost markets and resold elsewhere. They activate just fine, and Microsoft rarely retroactively enforces region boundaries.

None of these keys is counterfeit. They’re simply not authorized for retail distribution and sales. And that’s the crux of the matter. A key can be technically valid and still not legitimate under Microsoft’s licensing terms. That’s why you see disclaimers like “Microsoft may deactivate this license” — something never attached to a true retail key.

Why Not Stop This Madness?

So why doesn’t Microsoft shut this down? Because enforcement is aimed at organizations, not individuals. Say a corporate MAK pool gets audited and is found to be leaking keys. Then, the consequences fall on the organization that holds the license — not the end user who bought a $10 key online. Microsoft’s activation infrastructure is built for compatibility and ease of deployment, not aggressive policing. As long as the upstream license pool stays quiet, the key will likely keep working.

That’s why you see technically savvy users reporting years of trouble‑free activation. They’re not wrong. They’re simply describing the operational reality, not the licensing reality.

In the end, these cheap keys occupy a curious middle ground: not fake, not fully legitimate, but functional and low‑risk for individual buyers. They’re a reminder that Windows licensing is strict on paper, pragmatic in practice, and full of gray areas that only get more interesting the deeper you dig.

Here in Windows-World one perforce gets comfortable with gray areas. This one seems a bit more gray and shadowy than most, but there you have it!

AI, Insider stuff, Recent Activity, WED Blog, Windows 10, Windows 11

Copilot: Driver’s Education

January 27, 2026 Ed Tittel Leave a comment

If you read yesterday’s blog, you already know that I spent most of the weekend with my Flo6 desktop in UEFI, booting, or at the command line in WinRE/WinPE. On the other PC next to my desk chair, I keep a Lenovo P16 Gen1 Thinkpad. I was running Copilot on that PC, looking for insight into making Secure Boot work on the Flo6. Simply put, you can’t ask for help in Windows when that OS isn’t running. During that process I ended up in class for Copilot: driver’s education became quite a concern as I had difficulty scrolling down to read longish replies to my prompts and queries.

What Copilot Driver’s Education Is About

Turns out my scrolling attempts were misguided. I didn’t really understand how the touchpad on the P16 works. As you can see in the prompt window I’m using in this post for a lead-in graphic, the P16 touchpad is more oriented to gestures than to driving screen controls.

While I was working over the weekend, I simply popped in a wired mouse — complete with scroll wheel — and used that to speed scrolling while interrogating Copilot on the P16. After I had time to dig in a bit deeper, I learned that a two-finger gesture works for scrolling that touchpad quite nicely (two-finger sweep up to scroll down, down to scroll up — shades of Doc in the movie Cars).

Hah! I’ve been using Copilot since it first showed up over two years ago (June 2023) and didn’t know that this till this weekend. Probably because I still mostly drive with a mouse and not a touchpad. Now I know. Here in Windows-World, it’s the little things that sometimes make a big difference…

AI, Insider stuff, PowerShell, Recent Activity, Thoughts & concerns, WED Blog, Windows 11

Secure Boot Pursuit Undone

January 26, 2026 Ed Tittel Leave a comment

We’ve been (and still are, I kid you not) snowed in here in Central Texas. With Winter Storm Fern bearing down on us, we started hunkering down here last Friday (1/23). On Saturday we had rain, sleet and snow, and woke up to snowy sights Sunday. Figuring I had time on my hands, I decided to see if I could get Secure Boot working on my Asrock B550 Ryzen 7 5800X Flo6 production desktop. Alas, after much wrestling with hardware and software, I saw my Secure Boot pursuit undone early, early this morning. Let me explain…

Why Is My Secure Boot Pursuit Undone?

Through all kinds of contortions (see list below) I couldn’t get the PC to boot with Secure Boot enabled. Let me enumerate some of them so you can appreciate what I tried and failed to get done this weekend:

2 repair installs of my current running OS
1 “dirty install” (do not format partitions, but run installer which moves old OS into Windows.old and creates a new one: IDKYDT)
At least 2 each dism /restorehealth, sfc /scannow & chkdsk
Remove boot/sys drive from its M.2 slot to wipe NVMe config data from UEFI (have to remove GPU to access slot, sigh)
Swapped out old, soon-to-be obsolete 1070 Ti for 3070 Ti GPU.
spent over 30 hours fiddling with UEFI and Windows configs

After the “dirty install” I realized I’d hosed the primary MSA login on my main work machine. Not acceptable!! This morning, I built a new Macrium Reflect X Rescue disk, extracted the drivers from the Flo6, and restored my most recent backup (Friday afternoon, after I’d reorganized the boot/sys drive partitions).

Back in Business, Back to Work!

I learned a bunch about boot configuration data and related commands. I’m definitely completely up on booting the Flo6 into WinRE, Windows installer media, and the Macrium Rescue Disk. I’m much better acquainted with the Asrock UEFI than I’ve ever been before.

I also learned that my old MS Comfort Curve 4000 keyboard can’t (or won’t) send Fn key data to UEFI. Working on the ThinkPad P16 Gen 1 I soon figured out scrolling Copilot output was MUCH easier with an external mouse with scroll wheel than using the touchpad. Who knew?

And finally, I learned that Copilot will lead you all over the place trying to solve problems, heedless of time involved and consequence entailed. Sure, AI will tell you pretty much anything about Windows you want to know, but I wasn’t happy with the circuitous routes it took me on, and the circles it spun me through. Then it occurred to me: the words mendacious, malicious, utopia, and paradise all include AI, as do the phrases folie a deux and waste of time. Here in snowed-in Windows-World this weekend, I saw all those things play out. It was oddly engaging, but I’m glad it’s over.

AI, Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11

Catching Up Can Be Hard to Do

January 23, 2026 Ed Tittel Leave a comment

I’ll admit it. I’m lazy. When I hooked up the Lenovo ThinkCentre Neo 50q Tiny PC a couple of weeks ago, I cheated. How? By hooking up the power, networking, video, keyboard, mouse and camera that had previously been driving the ThinkStation P3 Ultra Gen 2 mini-PC. Yesterday, I had some free time so I unhooked the former and reconnected to the latter. Given the hiatus a storm of updates followed (as expected). When I checked Reliability Monitor (ReliMon) this morning, I found a couple of unexpected errors for the Lenovo TSSIOMonitor (aka Super IO Monitor). When I asked Copilot for help reading those tea leaves, its response: “Catching up can be hard, especially after a prolonged idle period.”

Why Catching Up Can Be Hard

As I look at ReliMon for yesterday afternoon, I see a steady stream of updates and installs that start at 3:38PM and run through 4:09PM (60 in all). According to Copilot, TSSIOMonitor.exe is a Lenovo executable that’s constantly monitoring hardware. Its job is to throw errors when things don’t look or work correctly.

One potential cause of the error is when sensor data is invalid. Another is when driver data doesn’t match what the monitor expects. That’s precisely what happens when chipset drivers update, ACPI tables get rebuilt, embedded controllers reinitialize, and Super I/O registers may be unstable. Basically, the monitor was using stale data to analyze a fresh situation, and erroring because of inevitable mismatches. Good to know.

Copilot Offers Insight, But I Must Assess Same

I’m getting used to asking Copilot to opine on system stuff when I need help understanding what’s going on. It certainly has more access to deep Windows arcana that I do, but I do notice occasional hiccups and hallucinations as it recites specific details. Indeed it sometimes goes off on tangents that don’t relate to my specific situation, but do play into the general circumstances and experiences around it.

This time, Copilot’s explanation makes good sense. And it helps me understand why such errors might occur when they did. It’s even comforting for it to tell me what I already knew: that a one-off or two-off error while a bunch of updates are underway isn’t terribly concerning. But we both agree that if it kept on happening (TSSIOmonitor.exe has been quiet ever since updates finished) there would be cause for concern, and possible action.

What Ronald Reagan said about nuclear arms monitoring apparently also provides to ingesting information from Copilot: “Trust, but verify.” Words to live by, here in a brave new AI-informed Windows-World.

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

Fixing WinKey+X Menu Change

January 22, 2026 Ed Tittel Leave a comment

The Win+X menu — that little power‑user gem tucked behind the Start button — is a Windows feature you don’t think about much until it breaks. When it does, the symptoms can be maddening: missing entries, wrong icons, dead shortcuts, or menu items that don’t launch. I recently went through a repair of the Win+X system on my production desktop. That process revealed just how many layers contribute to this simple menu. Here’s a recap of how the issue was resolved in fixing WinKey+X menu change.

Getting Started: Fixing WinKey+X Menu Change

The first clue was that the Win+X menu wasn’t launching Windows Terminal correctly. Instead of opening a PowerShell or Terminal instance, it either did nothing or threw an error. That pointed to a problem in the Win+X shortcut groups. These reside beneath the user profile at:
%LOCALAPPDATA%\Microsoft\Windows\WinX

Windows organizes these shortcuts into GroupN folders (N = 1-3). Group3 is where Terminal and PowerShell entries live. When I opened that folder, those shortcuts were either missing or pointing to stale AppX registrations. This can happen after uninstalling or repairing Windows Terminal, or some profile migration wherein AppX package identities change.

Making Shortcuts Happen…

The next step meant rebuilding shortcuts manually. Windows Terminal doesn’t include .lnk files. Hence, I created fresh ones by right‑clicking the desktop and choosing New → Shortcut, and pointing them at the program. It lives under WindowsApps and includes current version info in its actual filename.

Because Windows Terminal’s AppX path changes with every update, hard‑coding its location isn’t smart. Thus, I used the stable execution alias: wt.exe

Once the shortcut was created, I renamed it to match canonical Win+X naming conventions:
Windows Terminal.lnk Windows Terminal (Admin).lnk

Then I moved them into the Group3 folder. At this point, the shortcuts existed, but they were MIA on the menu. That’s because Win+X system caches entries and doesn’t refresh automatically. I forcibly rebuilt that cache by signing out and back in. After the next login, the menu finally displayed the new Terminal entries — but the icons were wrong.

What About Them Icons?

This led to the next discovery: Windows Terminal’s icon is stored inside its AppX manifest, not in a traditional .ico file. To fix them, I edited each shortcut’s properties and pointed the icon field to the stable Windows Terminal executable under Program Files. That exposed the correct embedded icon. Once updated, Win+X displayed the proper visuals.

The final step was cleaning up legacy entries. A repaired Microsoft Account caused Windows to resurrect old Win+X shortcuts from a now-defunct installation. Removing stale .lnk files from Group3 eliminated duplicates and restored the menu to a clean state.

By the end of the trail, Win+X worked again: correct icons, correct commands, and a clean set of shortcuts that launch reliably. The repair reinforced something I’ve seen before in Windows troubleshooting . A system often holds onto old paths, old identities, and old assumptions long after underlying components change or go away. Fixing things means understanding where Windows stores its info, and updating each layer one by one.

If your Win+X menu ever starts acting strangely, a careful rebuild of Group3 shortcuts may be exactly what brings it back to life. Here in Windows-World you can always try. It might work. And if it doesn’t, there’s always something else to try instead.

Cool Tools, Insider stuff, PowerShell, Recent Activity, Troubleshooting, WED Blog

WinGet Weirdness Finally Whacked

January 21, 2026 Ed Tittel Leave a comment

Every once in a while, Windows throws you a problem so strange, so deep in the plumbing, that you can’t help but treat it like a spelunking adventure. Over the past week, I’ve worked through one of those rare cases. Copilot ultimately helped diagnose it as a completely broken WinGet (aka Microsoft.AppInstaller) stack. Apparently, it came from corruption inside the WindowsApps directory. That’s the protected, TrustedInstaller‑owned home for all MSIX/AppX packages. I worked through a recovery process that touched ACLs, reparse points, Safe Mode, user‑level activation, and the PATH environment itself. Ultimately and fortunately, it ended with WinGet weirdness finally whacked.

Getting to WinGet Weirdness Finally Whacked

The symptoms were deceptively simple: WinGet wasn’t recognized, App Installer wouldn’t register, and the user‑level WindowsApps folder lacked key shims. Alas, the root cause was far deeper. The system‑level C:\Program Files\WindowsApps directory had partially corrupted ACLs, preventing enumeration that blocked TrustedInstaller from working. Even elevated tools couldn’t see its innards.

The breakthrough came in Safe Mode, where Windows releases some of its usual locks. Using takeown and icacls, I forcibly reclaimed ownership and permissions long enough to inspect the directory. Hundreds of previously invisible entries suddenly appeared — confirmation that the ACL choke point had finally broken open.

From there, I rebuilt the directory’s security model: restoring SYSTEM and TrustedInstaller with full control, removing inheritance, and returning ownership to TrustedInstaller. With the system-level store healthy, I exited Safe Mode (after discovering that msconfig, not BCD, was trapping the machine there) and rebooted into normal Windows.

Repairing WinGet/Microsoft.AppInstaller

Next came the App Installer repair. The system package was still resident, but user-level registration was MIA. I downloaded the official MSIX bundle, reinstalled it, and then manually re‑registered the package using its AppxManifest. That restored the user‑level WindowsApps directory and recreated the shims — including winget.exe.

But one last puzzle remained: even with the shim present, Windows still didn’t recognize the command. The culprit turned out to be the PATH. During the earlier corruption, Windows had silently dropped this critical entry:
%LOCALAPPDATA%\Microsoft\WindowsApps

Without that, no packaged app alias can resolve. Adding it back with setx, signing out, and signing back in finally brought the entire chain back to life. winget -v lit up instantly.

In the end, the repair touched nearly every layer of the Windows package‑servicing stack: NTFS ACLs, TrustedInstaller ownership, AppX registration, user‑level activation, and environment variables. It was a rare, deep, and oddly satisfying recovery — the kind of fix you document not just for others, but for the story it tells.
And now WinGet is fully operational again.

I’m celebrating the occasional “happy ending” that’s so rare in Windows-World. If you’re lucky you’ll never have cause to do likewise. But if this ever happens to you, here’s a trail of breadcrumbs to lead you out of that forest…

Insider stuff, Recent Activity, Thoughts & concerns, WED Blog, Windows 11, Windows OS Musings

NVIDIA Enters Windows on ARM Field

January 20, 2026 Ed Tittel Leave a comment

Here’s an interesting bit of news: AI heavyweight NVIDIA enters Windows on ARM field, as discussion of its N1 and N1X SoC offerings proliferate. These stories are popping today (Jan 20) but rumors have apparently been flying since last year. I got my info from WinBuzzer, but other key stories from TechRadar, DigiTimes, Tom’s Hardware, and more, are also worth a peek. Qualcomm’s exclusivity looks ready to expire, and x86/AMD64 CPUs likely to get even more competition soon.

As NVIDIA Enters Windows on ARM Field, Here’s What’s Known

The initial offering involves two “system-on-a-chip” (SoC) architectures known as N1 and N1X. According to WinBuzzer (confirmed at other sources) “the N1 designation likely targets desktops while N1X focuses on notebooks…” Deeper technical details are still emerging but here are some broad possibilities:

20-core ARM CPU designed with MediaTek
10 Cortex-X925 performance cores
10 Cortex-A725 efficiency cores
NVIDIA Blackwell GPU
Built on TSMC 3mm process
NPU delivers up to 1000 TOPS for AI
Includes 128GB RAM shared between CPU & GPU

That certain raises the bar from where things stand with either generation of Snapdragon X processors (shipping X1 variant since last year, X2 planned for Q126 delivery).

Things Could Get Interesting…

The big news here, of course, is that NVIDIA is building in GPU capabilities that match their current discrete and laptop 5070 class devices. Qualcomm’s offerings have delivered sufficient computing power and astounding battery life. But their Adreno GPUs are underpowered for serious gaming, 3D modeling, simulations, and other display-intensive workloads.

Looks like NVIDIA is throwing down a gauntlet in the Windows marketplace. This should make life interesting for everybody, including prospective buyers, but also intel, AMD, Qualcomm. The biggest PC OEMs are already on board. Look out Windows-World, here comes another 800lb gorilla!

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

CrapFixer Gives ASUS A14 Low Bloat Rating

January 19, 2026 Ed Tittel Leave a comment

One of the “interesting parts” of new machine intake is the process of removing things the system maker installs that you don’t want. This is often called “debloating” or “degunking.” I’m adding this to my intake process going forward, and reporting on it today, because I’m mostly convinced that the GitHub CrapFixer project does a good job of taking stock and reporting on unwanted apps (among many other things). I just ran it on my newest Copilot+ PC, and I’m pleased to report that CrapFixer Gives ASUS A14 low bloat rating. I’ll explain…

How CrapFixer Gives ASUS A14 Low Bloat Rating

I’m basing my “low bloat rating” on the information that appears in the lead-in graphic. It’s the CrapFixer “Analyze” output that shows up under the “APPS ANALYSIS” heading. Indeed, there are 17 entries there. BUT inspection reveals that none of these items come from third parties: they are items included by default in a normal Windows 11 installation.

That ties into the definition or bloatware or crapware that I think makes most sense. That definition: software apps from third parties that at least some user neither want nor need on their PCs. Frequent examples include:

Trial AntiVirus Suites: McAfee, Norton, Trend Micro, etc.
Cloud Storage trials: Dropbox, Box, etc.
Media/entertainment trials: Netflix, Spotify, etc.
Game trials or freemium games: Candy Crush, Hidden City, etc.

The ASUS A14 Zenbook includes none of these, except stuff that Microsoft bundles with the OS. That’s about as low as bloat gets. For the record, my recently-added Lenovo ThinkCentre Neo 50q gets the same rating, for the same reason.

Here in Windows-World bloatware is not uncommon on new PCs and laptops. It’s nice when little or none presents. And both ASUS and Lenovo make third-party offers available for owners thru their update apps (MyASUS and Lenovo Vantage, respectively). But they don’t preinstall them on their PCs. Good -oh!